Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I use SSH keys without passphrase with private/public keys.

I read O'reilly's SSH book that you can have encrypted SSH keys without passphrase by

  1. SSH agent,
  2. Host based authentication, or
  3. Kerberos authentication

I am not completely sure what they mean with these.

How would you have an encrypted SSH for active usage?

share|improve this question
    
Thank you for your answers! –  Masi May 26 '09 at 20:19

4 Answers 4

up vote 2 down vote accepted

Run an SSH agent (a process that holds your keys, unlocked, for you temporarily):

eval $(ssh-agent)

Then add the passphrase-protected key to the agent (so it can present the key when asked):

ssh-add ~/.ssh/my_protected_key

(enter your passphrase when prompted)

Then when you attempt to login to a system that wants to use the passphrase-protected key, the agent will give it out instead of you needing to enter your passphrase manually.

When you're done, you can stop the agent again:

ssh-agent -k

This will protect against someone getting access to your account (and the running agent) and using the key.

share|improve this answer

Nugget's general treatise on public-key authentication

why do I want to use public key authentication?

Passwords aren't the most secure things in the world. Even if a user picks a 'secure' password that's stronger than their dog's name, the password is still susceptible to a brute-force attack. Brute force attacks via ssh against user passwords are quite common on the Internet and several prevalent worms and zombies perform automated attacks incessantly against any internet-connected host. Even a secure password is at risk to these attacks, done by hand or by worm. Allowing password access to a system with many users is an invitation for a security breach.

Additionally, if you've got accounts on a large number of hosts it's tempting to reuse the same password on more than one host to reduce the number of passwords that your fingers have to memorize. Each shared password on a remote system puts you more at risk of a brute force attack on that host's password file, and means that if one host is compromised that all your other hosts sharing that same password are significantly less safe. Heck, you could accidently "erp" your password into an IRC channel by mistake some day and then spend the rest of the afternoon finding all the systems where you've re-used that password so that you can change it before anyone figures it out. It's not fun (or so I've heard!)

Thankfully, there's a solution! OpenSSH has a robust and well-tested public key authentication system built right in. When set up properly, it's not only more secure than using passwords but it's also a lot easier to use. How often does that happen?

what does public key mean, exactly?

Public-key authentication (or PKI -- a public key infrastructure) is an authentication method that relies on a generated public/private keypair. With PKI a special "key" is generated which has a very useful property: Anyone who can read the public half of the key is able encrypt data which can then only be read by a person who has access to the private half of the key. In this way, having access to the public half of a key allows you to send secret information to anyone with the private half, and to also verify that a person does in fact have access to the private half. It's easy to see how this technique could be used to authenticate.

As a user, you can generate a keypair and then place the public half of the key on a remote system. That remote system is then able to authenticate you, or prove that you are really you, and allow you to login just by having you demonstrate that you have access to the private half of the keypair. This is done at the protocol level inside SSH and happens automatically.

It does, however, mean that you need to protect the privacy of the private key. On a shared system where you do not have root this can be accomplished by encrypting the private key with a passphrase, which functions similarly to a password. Before SSH can read your private key in order to perform the public key authentication you'll be asked to supply the passphrase so that the private key can be decrypted. On more secure systems (like a machine where you are the only user, or a machine at your home where no strangers will have physical access) you can simplify this process either by creating an unencrypted public key (with no passphrase) or by entering your passphrase once and then caching the key in memory for the duration of your time at the computer. OpenSSH contains a tool called ssh-agent which simplifies this process.

how do I set this up?

The first thing you need to do is generate a keypair using the ssh-keygen tool which is part of OpenSSH. Windows users who use PuTTY can use the related putty-keygen.exe program in the same manner. SecureCRT has a keypair generator built in as well. Here's a log of creating a keypair:

luser@localhost:~$ ssh-keygen -t dsa
Generating public/private dsa key pair.
Enter file in which to save the key (/home/luser/.ssh/id_dsa): 
Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in /home/luser/.ssh/id_dsa.
Your public key has been saved in /home/luser/.ssh/id_dsa.pub.
The key fingerprint is:
f3:77:56:58:a8:bb:08:59:67:15:2c:0e:1d:d0:40:a3 luser@example.com
luser@localhost:~$

Now you have the two halves that comprise a keypair. The file id_dsa is the private half and the file id_dsa.pub is the public half. You'll want to make sure that only you can read the private files. This is critical, because OpenSSH will refuse to work with key files which are world or group readable. Verify thusly:

luser@localhost:~$ chmod 700 $HOME/.ssh
luser@localhost:~$ chmod 600 $HOME/.ssh/id_dsa*
luser@localhost:~$ ls -la .ssh
total 10
drwx------   2 luser  luser   512 Nov 15 16:12 .
drwx-----x  12 luser  luser  1024 Jun 24  2004 ..
-rw-------   1 luser  luser  1264 Nov 15 16:12 id_dsa
-rw-------   1 luser  luser  1123 Nov 15 16:12 id_dsa.pub
luser@localhost:~$

So now we're half-way there. You've got your keypair but we need to place the public half of the key on a remote machine. If you look at the id_dsa.pub file in your favorite editor you'll see that it's just a big block of numbers and letters. This means that it's easy enough to cut and paste, which can be simpler than trying to send it to a remote machine using a file transfer protocol like sftp or scp. Usually it's easiest to just open up another terminal window and paste it to the other host. In either case, you'll want to take the contents of id_dsa.pub and stuff them into a file named $HOME/.ssh/authorized_keys on a remote host. As before, make sure that the .ssh directory is only readable by you (chmod 700) and that the authorized_keys file is as well (chmod 600). You should end up with something like this:

luser@remotehost:~$ls -la .ssh
total 16
drwx------  2 luser  luser   512 Jul 11 19:01 .
drwx--x--x  7 luser  luser  1024 Nov 14 18:01 ..
-rw-------  1 luser  luser  1123 Nov 15 16:21 authorized_keys

So now you're all set to log in using public key authentication. Instead of being asked for your password on remotehost, you'll instead be challenged for the passphrase you've used to encrypt your local, private key. Give it a shot:

luser@localhost:~$ssh remotehost.example.com
Enter passphrase for key '/home/luser/.ssh/id_dsa': 
Last login: Tue Nov 15 16:20:50 2005 from localhost.example.com

luser@remotehost:~$ That's all there is to it! In reality, the user account on the remotehost side doesn't even need to have a password. With no password (which is not the same as a NULL password) it's not even possible to log in to a remote system without the private key. This makes the account totally immune to a brute-force password attack. There are other benefits as well, though. You can actually have more than one public key placed into the authorized_keys file on a remote host. This means that you can generate more than one private key if you routinely ssh from multiple locations. For example, you might create separate keypairs for your computer at home and the computer at your office. Remote hosts might have just one or both of those keys in the authorized_keys file. You might create a third keypair for your work laptop.

Why would you want multiple keys? Well imagine if your laptop gets lost or stolen. You can simply log in to remote hosts and remove that specific public key from your authorized_keys files and the laptop will be rendered incapable of logging in to the remote hosts, even if someone manages to crack or guess the passphrase which protects the private key. In this way, it's simple to "revoke" a keypair.

You'll also find that you're no longer tempted to share a single password with multiple remote hosts, which yields a dramatic increase in your overall security because if an account is compromised on one remote host it cannot be linked to any of your other accounts on other hosts.

advanced usage: ssh agent

You can actually take public key authentication one step further and make your life even easier by caching your private key locally. OpenSSH contains a tool called "ssh-agent" which can be used to accomplish this. This provides a compromise between the easy use of a passphrase-less private key and the security of having your private key encrypted in case someone gains unauthorized access to the actual file. You run ssh-agent on the local machine where you're sitting, and use it to cache the private key for repeated use.

The key to using ssh-agent is launching it as the parent process to your user session itself. Many Unixes are already doing this for you, and if you check your process list you may find that ssh-agent is already running to provide this capability. Windows users using PuTTY can use PuTTY's "pagaent.exe" tool and Mac OS X users can download a third party tool like SSHKeyChain or use the command-line ssh-agent as they would with any other Unix. [Edit: OS X 10.5 "Leopard" has ssh agent support built in. You don't need to install any additional software if you're running Leopard] If your operating system isn't running ssh-agent for you, you'll want to invoke it as part of your login process. For example, you might change your gdm or xdm login to invoke "ssh-agent gnome-session" instead of just "gnome-session" so that ssh-agent can sit on top of your session. The key is making sure that the SSH_AUTH_SOCK and SSH_AGENT_PID environment variables are global to your sessions on the host. With ssh-agent resident, you can run it manually and store your private key inside with ssh-add:

luser@localhost:~$ ssh-add ~/.ssh/id_dsa
Need passphrase for /home/luser/.ssh/id_dsa (luser@example.com).
Enter passphrase:
luser@localhost:~$

After having done that, you should now be able to ssh to any remote host without being challenged for your passphrase. OpenSSH will talk to the local ssh-agent daemon and retrieve the private key from it automatically. That authentication can even be (optionally) tunneled to the remote host which means if you ssh hop from that remote host to yet a third host the authentication can pass back through to your local ssh-agent and still not require typing a password or passphrase.

Be aware that using ssh-agent puts your private key at risk to anyone who has root access on the machine where ssh-agent is. It's not wise to use ssh-agent on a machine where you aren't or don't trust the administrator. It's also not wise to allow OpenSSH to forward the authentication on to a machine where you aren't or don't trust the administrator. You can control whether or not this agent forwarding takes place using the command line using the -A or -a switches or by setting the option in your $HOME/.ssh/config file like this:

#
# .ssh/config file for luser@localhost
#

# Forward X11 and Auth to slacker.com hosts, they can be trusted
Host *.slacker.com 
ForwardAgent              yes
ForwardX11                yes

# Forward X11 and Auth to my trusted example.com hosts
Host *.example.com
ForwardAgent              yes
ForwardX11                yes

# All hosts which haven't been matched above, paranoid settings
Host *
ForwardAgent              no 
ForwardX11                no
Compression               yes
KeepAlive                 yes

That's it!

Once you've grown accustomed to using public key authentication you'll wonder how you ever managed to live without it. It's really that remarkable. Not only is it more secure but it makes using SSH much simpler and more powerful. Enjoy!

This text is a repost of a document on my personal site, but I can't link to it because I'm a new user here on serverfault.

share|improve this answer
    
One recommended me to use the following in config -file: dpaste.com/48271 . How does your settings differ from that? –  Masi May 27 '09 at 15:51
    
The command % ssh-add ~/.ssh/id_dsa % does not ask me passphrase. Do you know what may be the problem? –  Masi May 27 '09 at 15:52

Using ssh-agent you are able to type in your password to have your private key unlocked so that you can then remotely connect to as many different remote machines as you want without being asked your password over and over.

On a system like Mac OS X where the ssh-agent ties into the Keychain you only have to type your login keychain password and ssh-agent will automatically be able to use the password from your keychain.

share|improve this answer

For your interactive uses, do not use keys without passphrases. Use ssh-agent/ssh-add instead, since this will allow you to enter the passphrase only once at the beginning of your session. It's very convenient, and much, MUCH more secure than using no passphrases.

The only time I can think to use keys without passphrases would be a special purpose server-server communication, such as a backup server talking to a backup client (or vice versa). For those cases use no passphrase, but use a separate username and limit what it can do with ssh's ForceCommand, etc.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.