This article is in draft. The tone of the article does not fall in line with the rest of the site. The examples are not yet made clear.
This also needs a followup article about how to use keys across multiple systems and moving keys across systems.
If your system is available through ssh on the Internet key based authentication must be used.
Even with preventative software such as fail2ban we have observed honeypot system being compromised within 3 days of being set up.
For the choice of keys to use, RSA is often selected over DSA because it has a stronger key length of 2048 and 4096. DSA can only be 1024.
It is unlikely you will run into issues if the versions of OpenSSH are different from client and server. However, just in case, you might want to determine the version of Open SSH installed,
As long as the major number (the first digit) is close you should have no issues.
This installs the SSH server and client,
At this point we have installed ssh, and it is time to create the keys for the users who require SSH access.
Note if you find that connecting via SSH is slow you might want to disable DNS lookup.
Generate Public and Private Keys on Client Machine
In principle, the generation of the Public and Private keys are done by user themselves on their own machine. This is because even the Unix Administrator should not have the user's private key.
Scratching your head on why keys should be generated by users? Think passwords. Any enterprise grade environment will ask you to define your own password. Your password is then hashed and never revealed to the Administrator. In the case where an Administrator sets your initial password, the password will be "one time" where the system will prompt you to set a new password upon successful authentication.
There are many variations of keys you can generate but currently industry standard is below,
Encryption Key Type = RSA
Key Length = 2048
With a Unix based system, this can be accomplished with the command line (below). Windows does not have a native way of doing this, but most Windows ssh client programs will provide a means of key generation.
If you are on a Windows machine, make sure to store your private key on a protected location. Usually this would be your Windows desktop or home directory.
Putty is one of the most popular Windows SSH Clients and your keys can be setup using puttyGen. However, Putty also has not been updated in years and I've found the generated keys to be problematic (for example will not work on my Mac). Instead, I recommend BitVise SSH Client Tunnelier for the key generation.
For console work, I still use Putty (actually Kitty) for normal console work, but still keep BitVise for its superior interface for file uploads and port tunnelling.
On Ubuntu it's super easy and your generated private key also work with Windows SSH clients.
ssh-keygen without parameters generates 2048 RSA public and private keys,
- Private key kept on the client machine = id_rsa
- Public key put on the target server machine = id_rsa.pub which will then be added into ~/.ssh/authorized_keys
On a Unix system file permissions should automatically be set to protect your key files from other accounts.
Storing Your Private Key
You private key is to never be shared. It's the equivalent of giving away your password.
If you are on a Windows machine, make sure to store your private key on a protected location. Be default, usually the safest place is your Windows desktop or home directory.
If you used the commands provides, your keys will be generated in your protected home folder with further restrictions placed on your directory and files.
Place Public Key on Server
If you happen to using a Linux client and your Linux server still allows username password authentication, there is a shortcut to getting everything up and running on the server,
It accomplishes in one command,
(Roderick you should fill this in)
Manually Copy Over Public Key to the Target Server
Transfer Over Public Key
Since I happen to be using Mac OS X I do this manually,
Setup .ssh Directory
Log into the server using your existing authentication method.
First check in your home folder that you have a .ssh directory and an authorized_keys file. The folder and file are generated if you had ever run the ssh client command,
If the directory did not exist, no problem, we can create ourselves,
Add the Public key added to the authorized_keys file,
Here is how everything should look in terms of permissions,
If you have been using SSH before, you might also see a file called known_hosts (will link and explain to this later).
TroubleShoot and Test Key Based Authentication
In the very first attempt, I like to trouble-shoot with a Unix or Linux command line client using the -v verbose option. Here's what a proper connection looks like coming form my Mac to the bonsaiframework,
The key values to notice are the loading of the proper key files, that RSA is being used and the "offering" of the key completes successfully. You should not need to type in your account password if your keys are working.
Disable Password Authentication
Just Enabling Key Based Authentication is not enough to secure your system. If you do not have a key, you will still be prompted for a password which will still work. The final step is to disable password authentication altogether.
Modify the sshd_config file to disable password authentication,
We can modify sshd_config quickly using sed,
Changes the following,
Uncomment and change yes to no. It should look like this,
Finally restart ssh for the change to take effect,
In older versions of Ubuntu (to determine) where Upstart is not available use,
Now go to another machine other than the server and try to authenticate using ssh,
The Permission denied indicates that password authentication is now disabled.
Reusing Public Keys Across Machines
You can actually reuse public keys across machines. With this approach, you only need to keep track of one private key per user. Of course, this also means if your private key is compromised all your systems are accessible with the one key.
- ... revoking keys
- ... strategies for centralizing key management and then also pitfalls
- ... is it possible to force password protected private keys
http://www.ibm.com/developerworks/library/l-keyc.html - pretty good article, I think I can improve it, shorter, clearly show when running on client or server.
http://serverfault.com/questions/40071/ssh-keypair-generation-rsa-or-dsa - talks about key length.
https://help.ubuntu.com/10.10/serverguide/C/openssh-server.html - Ubuntu version of docs.
http://www.howtoforge.com/ssh_key_based_logins_putty - instructions on using Putty, found the Auto-login tip useful.
http://stackoverflow.com/questions/2419566/best-way-to-use-multiple-ssh-private-keys-on-one-client - how to use multiple ssh keys using the config file.
http://www.freetutorialssubmit.com/convert-ssh-private-key-with-putty-keygen/1400 - sometimes you need to use different formats of keys.