Server Administration

  Home arrow Server Administration arrow SSH Case Studies: Agents and Authentic...

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

    Table of Contents:
  • SSH Case Studies: Agents and Authentication
  • 11.1.3 Hostbased Authentication



    SSH Case Studies: Agents and Authentication

    (Page 1 of 2 )

    In this second part of a nineteen-part series on SSH, you'll learn how to use an agent, and begin studying hostbased authentication. This article is 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). Using an agent

    ssh-agent provides another, somewhat less vulnerable method of key storage for batch jobs. A human invokes an agent and loads the needed keys from passphraseprotected key files, just once. Thereafter, unattended jobs use this long-running agent for authentication.

    In this case, the keys are still in plaintext but within the memory space of the running agent rather than in a file on disk. As a matter of practical cracking, it is more difficult to extract a data structure from the address space of a running process than to gain illicit access to a file. Also, this solution avoids the problem of an intruder walking off with a backup tape containing the plaintext key.

    Security can still be compromised by other methods, though. The agent provides access to its services via a Unix-domain socket, which appears as a node in the filesystem. Anyone who can read and write that socket might be able to instruct the agent to sign authentication requests and thus gain use of the keys. Some agent implementations attempt further checks, such as ensuring the communicating process runs under the same uid, but not all flavors of Unix support this. [] In any event, this compromise isnít quite so devastating since the attacker canít obtain the actual keys through the agent socket. She merely gains use of the keys for as long as the agent is running and as long as she can maintain her compromise of the host.

    The agent method does have a down side: the system canít continue unattended after a reboot. When the host comes up again automatically, the batch jobs wonít have their keys until someone shows up to restart the agent and provide the passphrases to load the keys. This is just a cost of the improved security, and you have a pager, right?

    Another bit of complication with the agent method is that you must arrange for the batch jobs to find the agent. SSH clients locate an agent via an environment variable pointing to the agent socket, such as SSH_AUTH_SOCK for the OpenSSH agent. [] When you start the agent for batch jobs, you need to record its output where the jobs can find it. For instance, if the job is a shell script, you can store the environment values in a file:

    $ ssh-agent | head -2 > ~/agent-info
    $ cat ~/agent-info
    setenv SSH_AUTH_SOCK /tmp/ssh-res/ssh-12327-agent;
    setenv SSH_AGENT_PID 12328;

    You can add keys to the agent (assuming C-shell syntax here):

    $ source ~/agent-info
    $ ssh-add batch-key
    Need passphrase for batch-key (batch job SSH key).
    Enter passphrase: **************

    then instrument any scripts to set the same values for the environment variables:

    # Source the agent-info file to get access to our ssh-agent.
    set agent = ~/agent-info
    if (-r $agent) then
    source $agent
    echo "Can't find or read agent file; exiting."
    exit 1
    # Now use SSH for something...
    ssh -q -o 'BatchMode yes' user@remote-server my-job-command

    You also need to ensure that the batch jobs (and nobody else!) can read and write the socket. If thereís only one uid using the agent, the simplest thing to do is start the agent under that uid (e.g., as root, do su <batch_account> ssh-agent ...). If multiple uids are using the agent, you must adjust the permissions on the socket and its containing directory so that these uids can all access it, perhaps using group permissions.

    Some operating systems behave oddly with respect to permissions on Unix-domain sockets. Some versions of Solaris, for example, completely ignore the modes on a socket, allowing any process at all full access to it. To protect a socket in such situations, set the containing directory to forbid access. For example, if the containing directory is mode 700, only the directory owner may access the socket. (This assumes thereís no other shortcut to the socket located elsewhere, such as a hard link.)

    Using an agent for automation is more complicated and restrictive than using a plaintext key; however, it is more resistant to attack and doesnít leave the key on disk and tape where it can be stolen. Considering that the agent is still vulnerable to being misused via the filesystem, and that it is intended to run indefinitely, the advantages of this method are debatable. Still, we recommend the agent method as the most secure and flexible strategy for automated SSH usage in a security-conscious environment.

    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