I spend a lot of my life figuring out how to do things on computers. The internet community has been a huge help to me and I decided it was time to give something back. Too often the tutorials out there are dated, wrong, poorly explained and in general a pain in the ass to work with. That’s not to say there aren’t some fantastic tutorials out there, but they’re the exception to the rule. More often than not I spend my time compiling an answer from twenty different, partially right or mostly wrong answers.
There is a lot of trial and error. But luckily I take really good notes. So if I ever have to do something twice, I can basically cut and paste from my notes to do it again. Simple.
I figure it’s time to start sharing my sys admin cheat sheets with the world. Today I’m starting with a cheat sheet that has served me well over the years: How to make SSH keys and connect servers together with them.
Why do you want ssh keys? Basically, you create keys so you can connect unix machines with scripts. You have two choices, you can make keys with a password or without.
Typically you make the keys without a password, so that a script on one machine can do things on a second machine, without being prompted for a password. The most secure way to do this make a unique, low privilege user for your task. For example, I like to create a user “backupguy” for backup jobs. Some people will tell you it’s a security risk to have password-less keys, but there are times you can’t get by without them. They can be a slight risk, but the trade off between necessary functionality and security sometimes has to be made. Basically you need password-less keys any time you are running an unattended script, like a nightly backup, or for monitoring software, such as Nagios, to connect to machines every few minutes and test that all it’s services are running. So as a competent Linux admin, you need to know how to do this.
The second way to make keys is to assign a password to them. In general root user keys should have a password. You don’t want to give someone a blank root password root key, in case your private key falls into the wrong hands. There are reasons to make a root ssh key, though some in the community will disagree. There uses for a root ssh key are supercomputing tasks, distributed computer, system rollout, rpm installation, pushing yum updates, etc. Even if you password protect the keys, you can use ssh-agent to feed the password to them. Check it out how to do that here: http://www.securityfocus.com/infocus/1812
Now on to the actual SSH key creation.
To start, let’s say you only have two machines, a local machine named OOGA to a remote machine named BOOGA.
We start on OOGA, which is your master server, from which you will run scripts, push code, etc.) You can have as many BOOGA servers as you like, but only one OOGA. I could have 20 BOOGA servers, BOOGA1, BOOGA2, etc and connect to them all with the same public key.
1) log on as the user you wish to create the keypair for, for example: user1
su user12) Now create the public key pair for that user:
ssh-keygen -d -b 1024 -C user@hostname.comThis creates a 1024 bit dsa key and -C adds a comment about the username and host
3) The command will prompt you for a place to put the files. I like to name it something other than the default which is id_dsa,
/home_of_user/.ssh/name_of_file
For example I created a pass for the user user1 with the following directory and name:
/home/user1/.ssh/user1_hostname_id_dsa
user1 is the user and hostname is the name of my server.
4) In this case we use an empty pass phrase, by hitting enter, enter when we are prompted for a passphrase.
5) Now we need to get the public version of the key to our second server BOOGA. scp the .pub version of the keypair to the machine
you want to control BOOGA, put it in the home directory
scp /home/user1/.ssh/user1_hostname_id_dsa.pub user1@BOOGA:/home/user16) Now move to BOOGA where you will do everything else
7) Create and authorized key file and put the key in it
7a) change to home directory of the user
cd /home/user17b)
mkdir .ssh7c)
touch .ssh/authorized_keys7d)
cat ./user1_hostname_id_dsa.pub >> .ssh/authorized_keys8 ) edit the /etc/ssh/sshd_config configuration file
vi /etc/ssh/sshd_configAdd or uncomment the following line:
AuthorizedKeysFile %h/.ssh/authorized_keysThe %h is replaced with the users home directory
9) Restart ssh:
/etc/init.d/sshd restart10) Set the proper permissions or this just won’t work right:
chown -R user1:user1 /home/user1/.sshchmod 700 /home/user1/.sshchmod 600 /home/user1/.ssh/authorized_keysYou are now good to go. Test it by connecting from OOGA to BOOGA.
On OOGA:
ssh -l user1 -i /home/user1/.ssh/user1_hostname_id_dsaIf you are prompted for a password, you did it wrong. Go back and recheck your steps. Most importantly, check your permissions,
because if they are wrong the keys default back to prompting you for user’s password, ensuring security.
