Mozilla Skin

SSH Logins Without Passwords

From Linux & Open Source @ NUS

If you ever tire of typing your passwords every time you login via ssh, or you need to write a script automating ssh sessions (for backups, uploads, whatsoever), you can try setting up ssh for RSA key-pair authentication.

Contents

Setting up the system

Remote Server Setup

First, the ssh server must allow this authentication method. Make sure /etc/ssh/sshd_config has the following:


 Protocol 2            # use ssh protocol 2!!
 
 # Authentication
 
 RSAAuthentication      yes
 PubkeyAuthentication   yes
 AuthorizedKeysFile      .ssh/authorized_keys
 

Restart your ssh server. You might want to start another ssh session first, in case there's something wrong and your ssh server can't restart.

Make sure you are the only user able to access ~/.ssh/authorized_keys by changing the permissions to 600.


 
 [user@remote_server] $ chmod 600 ~/.ssh/authorized_keys
 

Client side

The default location of the RSA key-pair is in ~/.ssh/id_rsa (private key) and ~/.ssh/id_rsa.pub (public key). This is set in /etc/ssh/ssh_config of your client computer, under IdentityFile.

In your own account, generate a RSA key-pair. You do not need a password passphrase. Store the keys in the location indicated in your ssh client configuration.


 [user@client] $ ssh-keygen -t rsa
 

Change the permissions such that only you can read the files.


 [user@client] $ chmod 600 ~/.ssh/id_rsa
 [user@client] $ chmod 600 ~/.ssh/id_rsa.pub
 

Append your public key to the ssh server. Of course you can cut and paste, or you can do this:


 [user@client] $ cat ~/.ssh/id_rsa.pub | ssh username@ssh.server "cat - >> ~/.ssh/authorized_keys"
 


Test your setup

If everything works, you should be able to login without typing in any passwords. Hooray!


Drawbacks

  1. If your private key is compromised (i.e. someone has access to it), the cracker can use your identity to access any computer you configured for this method of access. Think of what happens if you are using root.
  2. The ssh key stored on the remote server allows all commands to be executed. Hence any cracker on the client system can do anything using your identity on the remote server. Consider limiting the ~/.ssh/authorized_keys file on the remote server to accept only 1 command, using command="".
  3. If you are using this method in an automated script, consider creating a new user on the remote server just to for this login. This way, you can trace what this user has done on the remote server, and also limit the user to a chroot jail (or equivalent).