OpenSSH – Public Key Authentication ● Jonathan Schipp ● Dubois County Linux User Group ● Nov 7 th 2010 ● jonschipp (at) gmail.com

Why use Pub-Keys ● More “secure” than using password authentication. ● Passwords aren't sent over the wire ● Passwords attacks are ineffective(dictionary, bruteforce) ● Keys are much harder to guess than passwords ● Helps circumvent MITM attacks (assuming the attacker ● doesn't have your public key.

Other benefits? ● Automatic login is possible via the ssh-agent. ● Also, its possible to have automatic logins for multiple machines and through multiple machines by agent forwarding

● A user creates a pair of public and private keys, and installs the public key in his $HOME/.ssh/authorized_keys file on the target server. This is nonsensitive information which need not be guarded, but the other half — the private key — is protected on the local machine by a (hopefully) strong passphrase. ● A public key is a long string of bits encoded in ASCII, and it's stored on one long line (though represented here on three continued lines for readability). It includes a type (ssh-rsa, or others), the key itself, and a comment: ● ssh-rsa AzAAB3NzaC1yc2EaaaabiWaaaieaX9AyNR7xWnW0eI3x2NGXrJ 4gkQpK/EqpkveGCvvbMoH84zqu3Us8jSaQD392JZAEAhGSoe0d WMBFm9Y41VGZYmncwkfTQPFH1P07vDw49aTAa2RJNFyVQA NZCbSocDeuT0Q7usuUj/v8h27+PqsUUl9XVQSDIhXBkWV+bJa wc1c= Steve's key

How it works ● 1.The user makes an initial connection and sends a username along with a request to use a key. ● 2. The ssh daemon on the server looks in the user's authorized_keys file, constructs a challenge based on the public key found there, and sends this challenge back to the user's ssh client. ● 3. The ssh client receives the key challenge. It finds the user's private key on the local system, but it's protected by an encrypting passphrase. ● 4. The user is prompted for the passphrase to unlock the private key. ● 5. ssh uses the private key to construct a key response, and sends it to the waiting sshd on the other end of the connection. It does not send the private key itself! ● 6. sshd validates the key response, and if valid, grants access to the system.

ssh-keygen ● We must generate our ssh keys, one private and one public. ● Generate RSA keys: ssh-keygen -t rsa ● Generate DSA keys: ssh-keygen -t dsa ● You will now have a pair of keys located your home ● directory: ~/.ssh/id_rsa and ~/.ssh/id_rsa.pub ● or ~/.ssh/id_dsa and ~/.ssh/id_dsa.pub ●

ssh-keygen ● You can set the key bit length with -b ● ssh-keygen -b t dsa ● And of course, the.pub is the public key and the other is the private. ● Technically, the private key also has the public key in the same file. ● Keep your private key safe, you will be authenticating to it! When you create your key, you will be asked to create a password. This password will be used to unlock the private key.

Next step ● You must copy your public key to the remote ssh server. Log into the remote machine and copy your public key to your home directory on the remote server. ● In your home directory create a file called authorized_keys2 or authorized_keys (depending on openssh version) and move it to ~/.ssh/authorized_keys2 ● Now, check your server's sshd_config file and make sure that the PubKeyAuthentication directive is set to Yes.

That's it! ● It's not too hard. ● Now, when you use the ssh client and it asks for your password you will be giving the password to unlock the private key. ● If you have multiple private keys for multiple servers append them to your authorized_keys(2) file.

ssh-agent ● This tool runs in the background with the purpose of keeping your private key in memory, so that you can avoid unlocking your key each time you would like to connect to your ssh server. ● You can launch ssh-agent by calling it from a shell, but unfortunately, it is only good for that shell session. ● The idea is that ssh-agent is started in the beginning of an X-session or a login session, and all other windows or programs are started as clients to the ssh-agent program. ● To avoid having to launch each all the time (defeating its purpose) you can use a script or run it from your.xsession script or do what I do and create an alias for X. Add this line to your.bash_profile or.profile etc ● alias startx=”ssh-agent startx”

ssh-add ● Next we must add the key to the agent. ● When run without arguments, it adds the files ● ~/.ssh/id_rsa, ~/.ssh/id_dsa and ~/.ssh/identity. ● The identity file is a version 1 RSA key file. The others are version 2(DSA and RSA) ● The server also authenticates itself to you with its ● identity file. ● Of course, you must authenticate once.

ssh-add cont. ● If you have more keys for other servers, you can use ● ssh-add to add them individually into the agent. ● You can list the keys public keys held by the agent: -L ● List key fingerprints of keys held by the agent: -l ● Remove all keys from the agent: -D ● To remove a specific key: -d ● To add individual keys use: ssh-add

Agent forwarding ● Now, say we want to log into a machine and then from that machine into another and so on and so forth. ● We can still avoid having to use passwords by using what is called agent forwarding. You just need one agent in memory with all the necessary keys, and the necessary public keys on the server. ● On each server make sure AgentForwarding is set to Yes in the sshd_config file. ● Also, make sure the client file is set to use forwarding as well, /etc/ssh/ssh_config (global) or one in your ~/.ssh/config (local user)

resources ● ● forwarding.html ●