Server Administration

  Home arrow Server Administration arrow SSH Case Studies

SSH Case Studies
By: O'Reilly Media
  • Search For More Articles!
  • Disclaimer
  • Author Terms
  • Rating:  stars stars stars stars stars / 0

    Table of Contents:
  • SSH Case Studies
  • 11.1.2 Public-Key Authentication



    SSH Case Studies

    (Page 1 of 2 )

    Ready to take your knowledge of SSH to the next level? This nineteen-part article series will cover some advanced topics pertaining to the secure shell. It's excerpted from chapter 11 of the book SSH, The Secure Shell: The Definitive Guide, Second Edition, written by Daniel J. Barrett, Richard E. Silverman and Robert G. Byrnes (O'Reilly; ISBN-10: 0596008953).

    In this chapter we’ll delve deeply into some advanced topics: complex port forwarding, integration of SSH with other applications, and more. Some interesting features of SSH don’t come to the surface unless examined closely, so we hope you get a lot out of these case studies. Roll up your sleeves, dive in, and have fun.

    11.1 Unattended SSH: Batch or cron Jobs

    SSH isn’t only a great interactive tool, but also a resource for automation. Batch scripts, cron jobs, and other automated tasks can benefit from the security provided by SSH, but only if implemented properly. The major challenge is authentication: how can a client prove its identity when no human is available to type a password or passphrase? (We’ll just write “password” from now on to mean both.) You must carefully select an authentication method, and then equally carefully make it work. Once this infrastructure is established, you must invoke ssh properly to avoid prompting the user. In this case study, we discuss the pros and cons of different authentication methods for operating an SSH client unattended.

    Note that any kind of unattended authentication presents a security problem and requires compromise, and SSH is no exception. Without a human present when needed to provide credentials (type a password, provide a thumbprint, etc.), those credentials must be stored persistently somewhere on the host system. Therefore, an attacker who compromises the system badly enough can use those credentials to impersonate the program and gain whatever access it has. Selecting a technique is a matter of understanding the pros and cons of the available methods, and picking your preferred poison.

    11.1.1 Password Authentication

    Rule number 1: forget password authentication if you care about the security of your batch jobs. As we mentioned, authentication for any unattended process will require some kind of persistent secret lying around, so it might seem that a password in a protected file will do as well as anything else, and password authentication is simple. In a strict sense that’s correct, but it’s a bad idea both practically and securitywise. Embedding a password in a command line is unwise: it may be exposed to other users by simple commands such as ps, end up in shell history files (e.g. ~/.bash_ history) or system logs, etc. In fact, most SSH clients deliberately require terminal input (a “tty”) for a password, precisely to discourage this. You can use a tool like Expect to get around this limitation, but that will be awkward. Another practical limitation is that more methods tend to be available on the server side to restrict log-ins with public-key authentication, e.g., the “command” parameters in ~/.ssh/authorized_keys (OpenSSH) and ~/.ssh2/authorization (Tectia). This is just an implementation detail, but it’s very relevant since you definitely want to restrict unattended logins to do just what they’re intended to do.

    More generally, compared to other available methods, SSH password authentication is just inherently weak: passwords tend to be short and often guessable, and the client must reveal the password to the server as part of the authentication process; so if the server has been compromised, it will get your password. Public-key authentication, however, does not reveal the private key in the process.

    In the real world, though, you might be stuck using password authentication anyway. Perhaps you have to automate a transaction with a server not under your control; it only supports passwords, and you can’t get that changed. If you must, we suggest co-opting the “askpass” facility if it’s available. [6.3.3] The ssh-askpass program normally displays a window prompting for the password, but it can use instead a program that provides the password from wherever you’re storing it. It does so via a pipe, which is much better than letting it appear on a command line.

    More Server Administration Articles
    More By O'Reilly Media

    blog comments powered by Disqus


    - SSH Case Studies: Gateway Hosts
    - SSH Case Studies: More on Pine and SSH
    - SSH Case Studies: Pine and IMAP
    - SSH Case Studies: More on the Passive Mode
    - SSH Case Studies: Network Address Translation
    - SSH Case Studies: The Passive Mode
    - SSH Case Studies: The FTP Protocol
    - SSH Case Studies: Batch Jobs, FTP and SSH
    - SSH Case Studies: Agents and Authentication
    - SSH Case Studies
    - Server Responses to Client Communication
    - Authentication in Client/Server Communication
    - Client/Server Communication
    - Understanding Awk in the UNIX Shell
    - Stream Editor in the UNIX Shell

    Developer Shed Affiliates


    © 2003-2019 by Developer Shed. All rights reserved. DS Cluster - Follow our Sitemap