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 paire de clés générée avec PGP ou GPG dans la plupart des versions courantes (la version 2.0.13 apporte ce support). Mais il existe aussi une méthode bien établie utilisant le programme Unix ssh-keygen. Cela est très similaire à la génération d'une paire 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, et c'est bon.

* Kerberos – Il fonctionne avec GSSAPI (General Security Services API). Ce dernier est une interface de programmation qui ne se limite pas qu'à Kerberos, il est sensé inclure plusieurs possibilités et, comme toute API qui se respecte, il ne s'attarde pas sur les détails. Mais la bibliothèque GSSAPI fournie ne supporte que Kerberos, donc il n'est pas encore aussi étendu qu'il pourrait le devenir.

* Keyboard-Interactive – Le serveur envoie une ou plusieurs invite(s) de commande au client pour qu'il entre certaines informations. Il n'est cependant pas compatible avec tous les logiciels clients. Mais il fonctionne avec le terminal.

Je ne m'étendrai pas sur les deux derniers outils, étant donné que je les trouve très particuliers. Si vous avez besoin d'en savoir plus sur l'un des deux, une recherche Google vous indiquera probablement ce dont vous avez besoin. Les méthodes les plus habituelles sont l'entrée d'un mot de passe et l'utilisation d'une clé publique. Et, comme beaucoup de choses concernant la sécurité, il y a un compromis entre sécurité et facilité d'utilisation. Le mot de passe est la façon la plus facile pour s'authentifier et tout le monde sait comment l'utiliser. Mais il est vrai que les mots de passe peuvent contenir des failles. Vous pourriez par exemple n'utiliser qu'un seul mot de passe pour tout, ou en utiliser un qui soit facilement devinable. Vous pourriez l'écrire sur un post-it « caché » sous le clavier. Vous pourriez le donner à quelqu'un d'autre, particulièrement dans un environnement professionnel où beaucoup de gens sont amenés à accéder aux mêmes ressources. Étant donné que l'idée de base de l'utilisation de SSH est d'augmenter le niveau de sécurité, je n'aime pas me fier aux mots de passe s'il existe une alternative. Et la clé publique se présente de plus en plus comme cette alternative.

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.

Authentification par clé publique

La première étape passe par la génération d'une paire de clés. Comme nous l'avons vus précédemment dans le tutoriel sur le duel entre cryptographie symétrique et asymétrique, il existe plusieurs algorithmes qui peuvent être utilisés, RSA étant toujours le plus répandu d'entre eux. Le principe de cette méthode consiste à générer deux clés, de façon à ce que la clé 1 décrypte ce que la clé 2 a chiffré, et inversement. Par convention, l'une d'elles est dite publique tandis que l'autre est dite privée. Pour l'algorithme, vous choisissez généralement entre RSA, DSA ou ECDSA. RSA utilise de grands nombres premiers pour générer ses clés, DSA (Digital Signature Algorithm) utilise des logarithmes discrets et ECDSA (Elliptic Curve DSA) utilise des courbes elliptiques. Chacun sont des exemples d'un algorithme à sens unique, ce qui signifie qu'ils utilisent un calcul facile à effectuer, mais extrêmement compliqué dans le sens inverse. Actuellement, RSA semble être l'algorithme le plus largement utilisé, mais DSA est légèrement plus résistant et ECDSA est assez nouveau, mais arrive vite car hautement efficace. Vu que RSA est le plus répandu, il paraît logique de l'utiliser à moins que vous n'ayez une bonne raison de ne pas le faire.

Le prochain choix que vous aurez à effectuer concerne la longueur de la clé et ici la valeur par défaut devrait être 2 048 bits. 1 024 bits, c'est plus que le record actuel de piratage par force brute, mais pas tant que ça. Si vous avez un ordinateur puissant, choisissez 3 072 bits. Si vous voulez en savoir plus sur la commande ssh-keygen, allez voir dans man-page. Cela devrait vous donner deux fichiers placés dans le même répertoire ~/.ssh/. Le fichier id_rsa (si vous utilisez RSA) est votre clé privée. L'autre fichier, id_rsa.pub, est votre clé publique.

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.

Si vous utilisez Windows, vous pouvez télécharger puttygen.exe, qui fonctionne avec PuTTY. Vous trouverez les instructions à l'adresse https://kb.siteground.com/how_to_generate_an_ssh_key_on_windows_using_putty/. Vos deux fichiers se trouveront aux emplacements C:\Users\Your ID Name\.ssh\id_rsa (votre clé privée) et C:\Users\Your ID Name\.ssh\id_rsa.pub (votre clé publique).

Une fois les clés générées, vous aurez besoin d'ajouter votre clé publique sur votre compte ssh du serveur. La procédure peut varier. Sur un système plus ou moins public, il se peut que vous deviez passer par un site Web qui ajoutera la clé sur votre compte ssh. Dans un contexte professionnel, le département informatique peut peut-être s'occuper de la génération des clés et de leur ajout sur le serveur. Vous aurez donc besoin de vérifier comment ils gèrent cela avec le serveur.

Si vous avez accès au serveur (i.e. vous êtes administrateur de ce serveur), il existe un fichier nommé $HOME/.ssh/authorized_keys contenant les clés publiques de tous les utilisateurs, une à chaque ligne (et les lignes sont longues, évidemment). Étant donné que vous n'avez pas encore envoyé votre clé sur le serveur, cette connexion-ci nécessitera d'être authentifié par l'utilisation d'un mot de passe, mais une fois que vous l'aurez ajoutée, il n'y en aura plus besoin. Copiez simplement le fichier contenant votre clé publique, puis rentrez le nom du fichier dans authorized_keys avec cat pour l'ajouter. Si vous êtes administrateur de ce serveur et avez les droits nécessaires pour effectuer ces opérations, assurez-vous d'avoir correctement défini les permissions de façon à ce que personne d'autre ne puisse lire le fichier s'il rentre dans le serveur. L'idée est de sécuriser le serveur, après tout.

AGENTS

In use, you would need to use your passphrase each 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.

Agents

En pratique, vous aurez besoin de rentrer votre phrase secrète à chaque nouvelle session ssh. Même s'il est possible de créer une clé publique sans phrase secrète, c'est une très mauvaise idée de le faire. Et choisir une phrase secrète courte et facile à retenir est presque aussi mal. La phrase secrète nécessite d'être longue pour être utile. Je vous recommande tout d'abord de stocker celle-ci dans un gestionnaire de mots de passe, comme KeePassX (voir le tutoriel sur les mots de passe, l'entropie et les bonnes pratiques pour choisir son mot de passe, pour plus d'informations à ce sujet). Mais si vous ouvrez beaucoup de sessions ssh par jour, cela va finir par vous lasser. Heureusement il existe une solution relativement sûre appelée agent SSH. Un agent SSH est un programme conservé dans la mémoire qui retient votre clé privée décryptée. Chaque fois que vous allez sur un site utilisant SSH, ce programme génère un message à partir de cette clé que le serveur décrypte en utilisant votre clé publique (qu'il possède). Quand vous éteignez votre ordinateur à la fin de la journée, votre clé est supprimée de la mémoire, et vous aurez à rentrer une nouvelle fois votre phrase secrète le lendemain quand vous redémarrerez. En revanche cela comporte quelques désavantages évidents au niveau sécurité. Si vous ne verrouillez pas votre ordinateur à chaque fois que vous vous en éloignez, votre clé privée peut être récupérée par n'importe qui.

Dans tout système basé sur Unix, le programme ssh-agent devrait être installé par défaut. Beaucoup de gestionnaires de fenêtres se relient à ssh-agent et reconnaîtront votre clé (xdm et gdm par exemple) si elle se trouve dans l'emplacement par défaut. Vous saurez cela si une fenêtre apparaît au démarrage vous demandant votre phrase secrète. Ubuntu est un peu différent, vous pouvez donc lire la page concernée dans le man-page d'Ubuntu. Pour les utilisateurs de Windows, l'agent ssh de PuTTY s'appelle Pageant. Si vous placez un raccourci vers celui-ci dans le dossier de démarrage, il sera automatiquement lancé à chaque démarrage de 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.

Dernier avertissement

Il y a certains points à garder en mémoire. Tout d'abord, tout comme avec votre clé PGP pour vos e-mails dont nous avons parlé précédemment, vous serez bien embêté si vous perdez votre clé. La sauvegarde des clés est capitale. Si vous ne sauvegardez pas vos clés, vous pourriez vous retrouver un jour à ne plus avoir accès à vos systèmes distants. Vous pourriez peut-être créer un nouvel accès en supprimant les anciennes clés et en en faisant de nouvelles, mais si vous vous connectez à beaucoup de sites, cela sera long et fastidieux. Aussi, que se passera-t-il si l'ordinateur contenant vos clés est démantelé, vendu, ou corrompu d'une façon ou d'une autre ? Jusqu'à quel point votre accès est-il sécurisé maintenant ? Une solution serait de ne pas utiliser les mêmes clés sur différentes machines pour augmenter votre protection. Créer des paires de clés sur chaque machine séparément peut vous sembler fastidieux, mais, si le but est de sécuriser l'ensemble, cela pourrait être une bonne idée.