SSH Access Using Public / Private DSA Or RSA Keys
This howto will help you understand how to setup “passwordless” ssh access via public / private DSA or RSA encryption keys.
Applicable to Centos Versions:
- Centos 5.x
- Centos 6.x
Explanation of requirements.
- Access to at least 2 separate machines running Centos, RHEL or Fedora Linux
- Root access privileges to install the needed software
Doing the Work
Basic description of what will be done and what is expected.
- Make sure ssh is fully installed on both machines:
- Permissions and ssh-keygen:
- Copy your ~/.ssh/id_rsa.pub on the local system to ~/.ssh/authorized_keys on the remote system and attempt to login:
- Setting up ssh for automatic passwordless login with keys using ssh-agent and ssh-add:
These should already be installed, but just in case: yum install openssh-server openssh-client openssh
Using ssh-keygen to generate your keys: (you will have a public key that you copy to the computers you'll be accessing, and a private key that does not leave your system ever) Do not give out, store remotely or otherwise expose your private key to the outside world or you defeat the purpose entirely of using encrypted keys. Doing so is the equivalent to locking the door to your house and leaving the keys in the handle for anyone to use/take. We'll be using RSA in this example however, you're perfectly welcome and able to use DSA if you so choose. The difference is RSA, by default, uses a 2048 bit key and can be up to 4096 bits, while DSA keys must be exactly 1024 bits as specified by FIPS 186-2. It is unlikely you'll need a 4096 bit key as some things do not support them (Some Cisco VPN concentrators, PDA or cellphone technology, etc) and are viewed by many as "unbreakable" even with the most expensive government computer systems. With that said we'll give the following command to create our public/private keypair: cd ~/.ssh [user@localhost .ssh]$ ssh-keygen -t rsa Generating public/private rsa key pair. Enter file in which to save the key (/home/user/.ssh/id_rsa): (If you only plan on using one system, press enter. If you plan on using several give this file a unique name, see below) Enter passphrase (empty for no passphrase): (always use a passphrase) Enter same passphrase again: Your identification has been saved in /home/user/.ssh/id_rsa. Your public key has been saved in /home/user/.ssh/id_rsa.pub. The key fingerprint is: e5:06:05:64:ec:e9:9c:9b:f6:bd:d2:48:8a:de:bf:ba user@localhost IMPORTANT: The .ssh directory must have a permission of 700 and the authorized_keys file within that directory must have a permission of 600 to work for passwordless entry (there will be a password for the key itself). To accomplish this give the following commands as the user you will be using to ssh with: chmod 700 ~/.ssh; chmod 600 ~/.ssh/authorized_keys Note: If you're using a laptop which has the possibility of being lost or stolen or you're using several systems, you may consider using separate public/private keypairs and simply update/add to the authorized_keys file on the target systems. Remember that the private key should never leave the machine it was created on. If the laptop is then lost or stolen you can simply remove the reference to the key on the target machines authorized_keys file. You'll need to use a naming system that allows you to quickly identify which key belongs to which host(s) as well. Here are some simple examples: Enter file in which to save the key (/home/user/.ssh/id_rsa): id_rsa.dev Enter file in which to save the key (/home/user/.ssh/id_rsa): id_rsa.laptop1 Enter file in which to save the key (/home/user/.ssh/id_rsa): id_rsa.desktop
[user@localhost .ssh]$ ssh-copy-id -i id_rsa.pub 192.168.0.2 firstname.lastname@example.org's password: Now try logging into the machine, with "ssh '192.168.0.2'", and check in: ~/.ssh/authorized_keys to make sure we haven't added extra keys that you weren't expecting. [user@localhost .ssh]$ ssh 192.168.0.2 Enter passphrase for key '/home/user/.ssh/id_rsa': Last login: Tue Mar 23 16:04:23 2010 from foo.comcast.net [user@remotehost]$
[root@localhost]$ su - user [user@localhost ~]$ vi ~/.bash_profile add these lines at the bottom and logout/login or give the command: source ~/.bash_profile SSHAGENT=/usr/bin/ssh-agent SSHAGENTARGS="-s" if [ -z "$SSH_AUTH_SOCK" -a -x "$SSHAGENT" ]; then eval `$SSHAGENT $SSHAGENTARGS` trap "kill $SSH_AGENT_PID" 0 fi [root@localhost]$ su - user (skip this step if you used the source command above) Password: Agent pid 24646 [user@localhost ~]$ ssh-add Enter passphrase for /home/user/.ssh/id_rsa: Identity added: /home/user/.ssh/id_rsa (/home/user/.ssh/id_rsa) [user@localhost ~]$ ssh 192.168.0.2 Last login: Tue Mar 23 15:57:10 2010 from foo.comcast.net [user@remotehost ~]$ You should now be able to use the above sequence to login passwordless to any system you've copied your id_rsa.pub / authorized_keys file to. Login, use the ssh-add command, give your passphrase once and you should be able to login passwordless. You will be added to the ssh-agent for the remainder of your session until you logout, you'll need to re-verify your passphrase with each new login session. This verification is needed to prove you are the owner of the key.
Troubleshooting / How To Test
Explanation troubleshooting basics and expectations.
- Make sure sshd is set to start at boot and is currently running on both systems:
- Make sure your firewall is open for TCP connections on port 22:
Make sure sshd is set to start on boot and that it's been started: chkconfig --list | grep -i sshd; service sshd start sshd 0:off 1:off 2:off 3:on 4:on 5:on 6:off Starting sshd: [ OK ] If you see sshd "off" on 3,4 or 5 give this command: chkconfig --level 345 sshd on
service iptables status | grep -i 22 9 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:22 If not, give the following command and restart iptables: iptables -A INPUT -p tcp --dport 22 -j ACCEPT service iptables save; service iptables restart
Common problems and fixes
Describe common problems here, include links to known common problems if on another site
Any additional information or notes.
We test this stuff on our own machines, really we do. But you may run into problems, if you do, come to #centoshelp on irc.freenode.net