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
- 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. - 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_keysfile on the remote server to accept only 1 command, usingcommand="". - 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).
