+------------------------------------------------------------------+ | Linux Security: Tips, Tricks, and Hackery | | Published by Onsight, Inc. | | | | 26-December-2002 | | http://www.hackinglinuxexposed.com/articles/20021226.html | +------------------------------------------------------------------+ This issue sponsored by ... you. Intrested in sponsoring the Linux Security: Tips, Tricks, and Hackery newsletter? Just drop us a line. Special low low rates ($0) are available for worthy Open Source projects and companies that stand up to the DMCA and fight for our online freedoms. And if you haven't gone out and snagged a copy of Hacking Linux Exposed, Second Edition, do so through our website and we'll donate any kickbacks to the Electronic Frontier Foundation. -------------------------------------------------------------------- Secure Passwordless Logins with SSH Part 2 By Brian Hatch Summary: How to create passwordless logins to allow remote administration tasks securely with SSH - setting up your SSH identities. Setting up your accounts to allow identity-based authentication gives you several new options to allow passwordless access to those accounts. The end goal is to allow passwordless access that can only run specific commands, rather than full fettered login ability, but we'll start with the more general solution as our first step. To enable identity-based authentication, you must first create an SSH identity. An SSH identity is simply a private/public key pair, which are similar in functionality to to PGP keys, or SSL keys and SSL certificates. You place a copy of the identity public key into the file $HOME/.ssh/authorized_keys on any account you wish to enable access using this key. You keep the private key on the SSH client machine - your laptop, personal workstation, etc. When you connect from your client, the ssh program will offer to use identity-based authentication for each key it has available. If the server sees the public key in $HOME/.ssh/authorized_keys, it tells the SSH client to prove that it has the private key and if the client can meet the challenge, the access is granted.[1] For the remainder of these articles, I'll assume you are using a recent version of OpenSSH, 3.4p1 or better.[2] So, let's make a test key: $ cd $HOME $ mkdir identity-test $ cd identity-test $ ssh-keygen -f id_rsa -t rsa Generating public/private rsa key pair. Enter passphrase (empty for no passphrase): <enter> Enter same passphrase again: <enter> Your identification has been saved in id_rsa. Your public key has been saved in id_rsa.pub. The key fingerprint is: c3:af:e9:6c:2f:19:4d:b5:1a:a9:40:06:54:e6:60:08 jdoe@localhost $ ls id_rsa id_rsa.pub There are two major versions of the SSH protocol, SSH1 and SSH2. An SSH identity is tied to a specific SSH protocol version, so you need to decide on which protocol to use and pick an appropriate identity format from that. Most clients default to using the SSH2 protocol, however you can explicitly pick which protocol to use by adding a -1 or -2 option to your ssh command line, which will select SSH1 or SSH2 respectively. An SSH identity comes in three formats: +------------------------------------------------+ | Type | Command line args | Protocol | |------+-------------------+---------------------| | RSA1 | -t rsa1 | SSH 1 protocol only | |------+-------------------+---------------------| | RSA | -t rsa | SSH 2 protocol only | |------+-------------------+---------------------| | DSA | -t dsa | SSH 2 protocol only | +------------------------------------------------+ With the ssh-keygen listing above, we created an RSA key by using the -t rsa option, thus this is an SSH2 protocol identity (so we might want to add -2 to our command line just to be explicit). The identity is stored in two parts. The private key is in id_rsa and the public part is in id_rsa.pub. For sake of argument, I'll assume we're using the SSH2 protocol, and include -2 on the command lines just to be verbose. Important Note: When you create an SSH identity, you can 'encrypt' your private key. If the server allows you to authenticate with this key, your SSH client will ask you to decrypt the key so it can use it. This is a good idea for identities - otherwise anyone who can read the file (for example the root user on your system) can use it to authenticate as you. (You can protect your key file with a passphrase while making it possible to use it without typing the passphrase each time using ssh-agent, but I won't get into that here. If you're interested in this, you might want to try using Keychain as well, as it makes identities more manageable.) Now in our case, we will be putting restrictions on this key such that it cannot do anything except the commands we will allow, from the hosts we allow. Thus it's easiest to create the key with no passphrase, and let paranoid file permissions handle the security of the key. I'll show a quick way to easily handle passphrase-protected keys at the end of our journey, but for now let's stick to passwordless keys. So, now it is time to tell the remote account that we trust this test key. You need to include the public key (id_rsa.pub) in the file $HOME/.ssh/authorized_keys on the remote account. You can do this in several ways. copy/paste Believe it or not, my standard method. Log into the remote account, open up $HOME/.ssh/authorized_keys with your favourite editor[3] and paste it at the end of the file. scp If you don't have a $HOME/.ssh/authorized_keys file on the remote system, you can simply copy the id_rsa.pub to it directly: local$ ssh username@server 'mkdir .ssh' password: (type password for username@server) local$ scp ~/identity-test/id_rsa.pub username@server:.ssh/authorized_keys password: (type password for username@server again) The SSH server is paranoid, and will refuse to honour your authorized_keys settings if they have poor file permissions, so you should lock down your files and directories: username@server$ cd $HOME username@server$ chmod go-w . username@server$ cd $HOME/.ssh username@server$ chmod 700 . username@server$ chmod 600 * So, let's test logging in with this key. Since we have put the test key in a non-standard place, we will need to reference it explicitly on the command line: local$ ssh username@server -i $HOME/identity_test/id_rsa username@server$ hostname server username@server$ exit local$ ssh username@server -i $HOME/identity_test/id_rsa "echo Success!" Success! local$ In the first example we logged into the server interactively, while in the second we ran the echo command on the server, never logging in for real. Neither time did we need our Linux password, or an identity passphrase. Right now we've set up trust that would allow someone with this key to log in or run any commands on this server account from anywhere. If you're having trouble getting this to work, you should check the server logs and see if it provides any insight, as well as running ssh with the -v flag. It's possible the server does not allow identity authentication - check /etc/ssh/sshd_config on the server for entries such as the following: # Allow Identity Auth for SSH1? RSAAuthentication yes # Allow Identity Auth for SSH2? PubkeyAuthentication yes When you're done testing this, you should delete the entry from ~ /.ssh/authorized_keys on the server. Next week we'll set it up to be usable only from your designated machines, and only be able to run authorized commands. If you're interested in setting up seamless identity authentication without the limits we'll be setting up, you may want to check out two pieces of software: ssh-keyinstall William Sterns maintains a program called ssh-keyinstall, available at http://www.stearns.org/ssh-keyinstall that helps you create and install your SSH identities on your remote servers. Keychain Keychain by Daniel Robbins and available at http://www.gentoo.org /proj/en/keychain.xml helps you set up per-host ssh-agents automatically. By having a single ssh-agent with decrypted copies of your identities, you can have passwordless identity authentication while leaving your identities encrypted on disk. Robbins has a detailed description of how you use Keychain, and several extensive series of articles about SSH Identity authentication available through IBM DeveloperWorks linked from the Keychain page. NOTES: [1] The server and client go through a bit of mathematical rigamarole to prove that the client possess the secret key. The specifics aren't material to this discussion, If you want more information, check the SSH man pages, RFC, or the SSH book by O'Reilly. [2] Earlier versions of OpenSSH required you distinguish between SSH1 and SSH2 protocols (the latter needed to have keys placed in $HOME /.ssh/authorized_keys2.) SSH.com's version of the SSH server and client have the same functionality as OpenSSH, but implements things in a very different way. [3] vim, naturally. ------------- Brian Hatch is Chief Hacker at Onsight, Inc and author of Hacking Linux Exposed and Building Linux VPNs. He's been using SSH to secure his remote logins since Tatu posted the first version of the code - even if the administrators of those machines refused to install it for him. Brian can be reached at brianat_private -------------------------------------------------------------------- This newsletter is distributed by Onsight, Inc. The list is managed with MailMan (http://www.list.org). You can subscribe, unsubscribe, or change your password by visiting http://lists.onsight.com/ or by sending email to linux_security-requestat_private Archives of this and previous newsletters are available at http://www.hackinglinuxexposed.com/articles/ -------------------------------------------------------------------- Copyright 2002, Brian Hatch. - ISN is currently hosted by Attrition.org To unsubscribe email majordomoat_private with 'unsubscribe isn' in the BODY of the mail.
This archive was generated by hypermail 2b30 : Thu Dec 26 2002 - 08:04:00 PST