SSH Authentication

You can do this in several ways: • Password – You authenticate to the server by typing in your password. This is easy because you can generally remember your password, and it means you can easily login from any computer with that knowledge. This is still the most common authentication mechanism for SSH. • Public Key – This is much more secure. It involves the creation of a key pair, of course. It is possible to use a key pair generated by PGP or GPG in the most current versions (version 2.0.1 3 introduced support for this). But there is a long established method using the Unix program ssh-keygen. This is very similar to generating a key pair as we discussed earlier. You run the program ‘ssh-keygen’, harvest some entropy, generate a passphrase to protect it, and so on. • Kerberos – This is done through the General Security Services API. This is a programming interface that is broader than just Kerberos—it is supposed to encompass several possibilities, and, of course, as an API it abstracts from the details. But the GSSAPI library included supports only Kerberos, so it is not yet as general as it might become. • Keyboard-Interactive – The server sends one or more prompts to the client to enter certain information. This is not compatible with all client software, however. But it would work in a terminal.

I won’t go into detail on the last two of these, as I consider them very specialized. If you need to know more on either of them, a Google search would probably turn up what you need. The most common methods are either entering a password, or using a public key. And, like so many things in security, there is a tradeoff between security and ease of use. Passwords are the simplest and easiest way to authenticate, and everyone knows how to use one. But it is also true that passwords can be compromised in a variety of ways. People may use a single password for everything, or they might use a password easily guessed. Or it might be written on a sticky note “hidden” under the keyboard. Or it might be given to someone else to use, particularly in a corporate environment where many people may need to access the same resources. Since the whole idea of using SSH is to increase the security, I don’t like relying on passwords if there is an alternative. And increasingly, public key is that alternative.

Authentification SSH

Vous pouvez faire cette opération de plusieurs manières :

* Mot de passe – vous vous authentifiez auprès du serveur en renseignant votre mot de passe. Cette méthode est simple car vous pouvez généralement retenir votre mot de passe, ce que signifie que vous pouvez facilement vous connecter depuis n'importe quel ordinateur. Cela reste la manière la plus commune de s'authentifier en SSH. * Clé publique – cette méthode est bien plus sécurisée. Elle implique la création d'un trousseau de clés, bien sûr. Il est possible d'utiliser une pair de clés générée avec PGP ou GPG dans la plupart des versions courantes (la version 2.0.1 3 apporte ce support). Mais il existe aussi une méthode établie utilisant le programme Unix ssh-keygen. Cela est très similaire à la génération d'une pair de clés comme nous l'avons vu plus tôt. Lancez le programme « ssh-keygen », créez un peu d'entropie, générez une phrase de chiffrement secrète pour le protéger,

PUBLIC KEY AUTHENTICATION

The starting point for this is generating the key pair. As we said previously in our tutorial on Symmetric vs. Asymmetric Encryption, there are several possible algorithms that can be used, with RSA still the most common. And the way this works is that you generate two keys, such that key1 will decrypt anything that key2 encrypted, and key2 will decrypt anything key1 encrypted. Arbitrarily, one of these is designated as the public key, and the other as the private key. For your algorithm, you generally choose either RSA, DSA, or ECDSA. RSA uses large prime numbers to get its keys, DSA (Digital Signature Algorithm) uses discrete logarithm mathematics, and ECDSA (Elliptic Curve DSA) use Elliptic Curve mathematics. All of these are examples of a one-way algorithm, which means that it uses a computation that is easy to do, but extremely difficult to do in reverse. Right now, it looks like RSA is more widely used, but DSA is slightly stronger, and ECDSA is fairly new but coming up fast because it is highly efficient. Since RSA is widely used, it makes sense to go with RSA unless you have a strong reason not to.

Your next decision is the key length, and here the default should be 2048. 1 024 is more than the current record for brute force cracking, but not that much more. If you have a powerful computer, go for 3072. If you want more information on the ssh-keygen command, try the man page. This should give you two files which will reside in the same ~/.ssh/ directory as your known-hosts file. One will be your ID name_rsa (assuming you used RSA), which will be your private key. The other will be your ID name_rsa.pub, which will be your public key.

If you are a Windows user, try downloading puttygen.exe, which works with PuTTY. Instructions can be found at https://kb.siteground.com/how_to_generate_an_ssh_key_on_windows_using_putty/. Your two files will be C:\Users\Your ID Name\.ssh\your ID name_rsa (private key), and C:\Users\Your ID name\.ssh\your ID name_rsa.pub

Once you have generated these keys, you need to add the public key to your ssh account on the server. How this happens may vary. On a more-or-less public system they may let you add this through a Website where it is added to your account information. In a corporate environment, you may find that the IT department takes care of generating the key and adding it to the server. So you need to check with the server to see how they handle this.

If you have access to the server (eg, it is a server you administer), there is a file called $HOME/.ssh/authorized_keys that holds the public keys of users, one to a line (and the lines are long, of course). Since you have not yet uploaded your key, this login to the server will need to be authenticated by using a password, but once you have added it, you should be good in the future. Simply copy the file with your public key, then cat the file to the authorized_keys file to add it. Note that if you are the admin on this server and have the rights needed to do this, make very certain that you set the permissions properly so that no one else who gets on your server can read the file. The idea is to be secure, after all.

AGENTS

In use, you would need to use your passphrase ach time you tried to open an ssh session. While it is possible to create a public key without a passphrase, it is a very bad idea to do this. And a short, memorable passphrase it almost as bad. The passphrase needs to be long to do its job. I would recommend that you first store this in a secure vault like KeePassX (see the tutorial on Passwords, Entropy, and Good Password Practices for more on this). But if you do a lot of SSH sessions in a day, this does get old. Fortunately, there is a good, reasonably secure solution, called an SSH agent. This is a program that resides in memory and holds your decrypted private key. Every time you go to a site using SSH, it uses this key to generate a message which the server decrypts using your public key (which it has). And when you shut down your computer at the end of the day, it drops your key out of memory, so the next day when you boot up you need to enter your passphrase one more time. There are obvious security concerns here. If you don’t lock your computer every time you walk away from it, your private key can be grabbed by anyone.

In any Unix-like system, the program ssh-agent should be installed. Many display managers will have hooks into the ssh-agent, and will find your key (xdm and kdm are two such) if it is in the default location. You will know this if, when you boot up, you get a pop-up window asking you for your passphrase. Ubuntu is a little different, so you can read the Ubuntu man page for this here. For windows users, the PuTTY ssh agent is called Pageant. If you place a shortcut to it in the startup folder, it will run automatically every time you boot Windows.

FINAL CAUTION

There are some things to keep in mind here. First, just as with your PGP key for e-mail, which we discussed previously, if you lose your key you are in trouble. Backing up is important. If you don’t back up your keys, you may find one day that you no longer have access to those remote systems. You might be able to get new access by deleting the old keys and getting new ones added, but if you log into a lot of sites that will be a royal pain. Also, what happens if a computer that has your keys on it is decommissioned, sold, or compromised in some way? How secure is your access now? One recommendation is that you don’t use the same keys on different machines to help guard against this. It might seem like additional work to create key pairs on each machine separately, but if the point is security it just might be a good idea.