L'authentification par mot de passe (transmis chiffré) est le mode d'identification par défaut.

Suite à l'installation du paquet openssh-server, il peut parfois être nécessaire de modifier le fichier de configuration /etc/ssh/sshd_config notamment quand on rencontre le problème suivant :

moi@maison:~$ ssh user@domain.com
  Permission denied (publickey)

Dans ce cas, il faut très simplement modifier avec les droits d'administration le fichier /etc/ssh/sshd_config sur le serveur SSH de la manière suivante :

# Change to yes to enable tunnelled clear text passwords
PasswordAuthentication yes

Puis en cas de modifications, relancer le service.

Si on ouvre son serveur SSH sur Internet, par exemple pour y accéder depuis l'ordinateur d'un ami(e) ou lui permettre d'accéder à certains des fichiers, ne JAMAIS oublier qu'Internet est parcouru par des robots qui scannent et testent en permanence tous les serveurs disponibles (SSH et autres) et qu'ils vont faire des tentatives pour trouver les mots de passe de compte (on parle d'attaque par force brute). L'usage des clés est donc très fortement recommandé. Si on ne peut vraiment pas faire autrement, utiliser des mots de passe longs et complexes ainsi qu'un système de protection tel que fail2ban qui permet de bannir des adresses IP au bout d'un certain nombre de tentatives erronées. Voir aussi denyhosts notamment en cas de:

sssh_exchange_identification: read: Connection reset by peer



Autrefois tout le monde employait l'authentification typique par le principe identifiant - mot de passe. Cependant si quelqu'un connaît le mot de passe ou le découvre au moyen d'une attaque la sécurité est compromise. De plus, utiliser un mot de passe différent pour chaque serveur et l'entrer à chaque connexion peut s'avérer contraignant.

Pour être débarrassé des ces problèmes, SSH propose un système d'authentification par clé publique/privée au lieu des mots de passe « simples ».

Ceci peut permettre par exemple :

• à un administrateur de se connecter à des centaines de machines sans devoir connaître des centaines de mots de passe différents ;
• de ne pas avoir un mot de passe à saisir toutes les 2 minutes (en utilisant ssh-agent).

Ces clés restent des chaînes de caractère (en français courant : du texte), mais sont beaucoup plus longues et aléatoires que de simples mots de passe.

La clé privée est en principe unique : chaque utilisateur possède une clé privée qu'il peut copier sur les terminaux auxquels il accède physiquement et depuis lesquels il a besoin d'un accès SSH (via le client SSH). Cette clé se trouve généralement dans le fichier ~/.ssh/id_rsa. C'est un document sensible très personnel, il faut y appliquer des droits très restrictifs : r-x — — (500) pour le répertoire .ssh et r– — — (400) pour le fichier id_rsa. Pour un maximum de sécurité il est possible de protéger cette clé privée au moyen d'un mot de passe (qu'il faudra dans ce cas entrer lors de chaque connexion).

De son côté, la clé publique est envoyée à tous les serveurs auxquels on veut accéder à distance afin qu'ils nous identifient avec certitude (ils seront au moins sûrs qu'on possède bien la clé privée associée). Côté serveur cette clé publique sera stockée dans le fichier ~/.ssh/authorized_keys (avec éventuellement les clés publique d'autres utilisateurs, une clé publique par ligne). Localement on peut stocker une clé publique par ex. dans un fichier id_rsa.pub qui peut aussi se trouver dans le répertoire ~/.ssh, ou ailleurs (ce n'est pas un document sensible).

On peut générer une nouvelle clé publique depuis une clé privée mais pas l'inverse.

À moins que l'on ait déjà un couple de clés, on doit d'abord en créer. Exemple pour une clé utilisant le protocole de chiffrement RSA, saisir dans le terminal du client :

ssh-keygen -t rsa  -b 4096 -C "email@example.com"

les options -b 4096 et -C… sont facultatives mais permettent respectivement d'augmenter la force de la clé et d'ajouter un commentaire, ici l'email, pratique si on veut se créer plusieurs clés, par exemple perso/pro. Il sera alors demandé où sauver la clé privée (acceptez r juste l'endroit par défaut : ~/.ssh, et ne pas changer le nom du fichier généré) puis de choisir une passphrase (phrase de reconnaissance).

Bien que non obligatoire, l'utilisation d'une passphrase est recommandée pour protéger sa clé privée. En effet toute personne qui obtiendrait l'accès à la clé privée (non protégée) aurait alors les permissions sur d'autres ordinateurs. Prendre un instant et choisir une très bonne passphrase c'est à dire longue et complexe. La clef publique a été créée avec la nouvelle clef privée. Elles sont habituellement localisées dans le dossier caché ~/.ssh:

~/.ssh/id_rsa.pub pour la clé publique et ~/.ssh/id_rsa pour la clé privée.

Pour que le ssh-agent reconnaisse cette paire de clef, il faut utiliser la commande ssh-add :

ssh-add
#ou plus directement 
ssh-add /chemin-complet/vers-la-cle/nom-cle

On peut également vérifier la liste des paires de clefs existantes avec l'option -l (-list) : ssh-add -l Si cette commande ressort, lancer:

The agent has no identities.

alors aucune clef n'est actuellement prise en compte. Il faut recommencer les étapes ci-dessus.

- Forcer l'utilisation uniquement de clefs dans la commande ssh :

ssh -o PubkeyAuthentication=yes -o PreferredAuthentications=publickey

- Utiliser les options -v ou -vv ou -vvv dans le commande ssh Il faut maintenant envoyer au serveur la clé publique pour qu'il puisse chiffrer des messages.

En résumé (car les paragraphes ci-dessous utilisant des scripts peuvent sembler confus à certains)

- Côté client : Il faut que le client ait mis sa clé privée en $HOME/.ssh/ (côté client)

- Côté client : la clé doit être “enregistrée/déclarée” à l'agent ssh (ssh-add)

- Côté client : Le répertoire $HOME/.ssh doit appartenir (chown) au propriétaire de $HOME et être en protection 700 (interdit aux autres)

- Côté serveur : La clé publique du client doit se trouver dans le fichier $HOME/.ssh/authorized_keys du serveur

- Côté serveur : il vaut mieux refuser l'accès par mot de passe (“PasswordAuthentication no” dans /etc/ssh/sshd_config du serveur)

L'utilisateur distant doit avoir cette clé (c'est une ligne de caractères en code ASCII) dans son fichier de clés d'autorisation situé à ~/.ssh/authorized_keys sur le système distant. Employer la commande ssh-copy-id.

ssh-copy-id est un script qui utilise ssh pour se connecter à une machine à distance en utilisant le mot de passe de l'utilisateur.

L'authentification par mot de passe doit donc être autorisée dans le fichier de configuration du serveur ssh (par défaut sur Ubuntu). Il change également les permissions des répertoires ~/.ssh et ~/.ssh/authorized_keys de l'hôte distant pour enlever l'accès en écriture du groupe (qui empêcherait de se connecter si le serveur distant ssh a “StrictModes yes” dans son fichier de configuration, ce qui est le cas par défaut sur Ubuntu).

ssh-copy-id -i ~/.ssh/id_rsa.pub <username>@<ipaddress>

ou si le port est différent du port standard 22 (noter les guillemets):

ssh-copy-id -i ~/.ssh/id_rsa.pub -p <num_port> "<username>@<ipaddress>"

On doit alors donner le mot de passe utilisateur de cet ordinateur. Après l'ajout de la clé publique, on devient un hôte de confiance.

Si l'authentification par mot de passe est désactivée , alors on aura besoin de copier-coller la clé suivant un autre moyen. Voici une ligne à copier pour ajouter sa clé publique sur le serveur distant :

ssh login@serveur "echo $(cat ~/.ssh/id_rsa.pub) >> .ssh/authorized_keys"

Lancer :

ssh <username>@<ipaddress> -p <num_port>

Dorénavant, ne plus utiliser plus ce mot de passe mais la passphrase pour se connecter. Celle-ci sert à déchiffrer la clé privée de votre système local.

Si ça ne marche pas, c'est-à-dire que le mot de passe est quand même demandé, essayer sur le serveur la commande :

tail -f /var/log/auth.log

en essayant de se connecter. Si on parle de “vulnkey”, c'est que par malchance ssh-keygen a généré une clé vulnérable. Recommencer alors la procédure depuis le début2)

Pour résumer, deux choses sont nécessaires pour obtenir un accès réellement sécurisant (et sécurisé) par authentification à clé publique par rapport à l'authentification par mot de passe classique :

- La clé privée, chiffrée ; - La passphrase, utilisée pour déchiffrer sa clé privée. Quand on choisit de ne pas avoir de mot de passe, on aura une sécurité moindre, ainsi que si on utilise une authentification uniquement par mot de passe, comparé à celle que l'on peut avoir en combinant les deux.

Avec SSH, on peut avoir les deux modes d'authentifications actifs en même temps, par mot de passe et par clés.

On peut vouloir neutraliser l'authentification par mot de passe pour des raisons de sécurité, pour cela il faut modifier le fichier de configuration /etc/ssh/sshd_config de la manière suivante :

- A la ligne PasswordAuthentication, mettre no

- A la ligne UsePAM, mettre “no”

Avec ChallengeResponseAuthentication et PasswordAuthentication à no, on peut continuer à utiliser PAM en bloquant l'usage des mots de passe pour ssh. Ne pas oublier de relancer le service ssh sur le serveur après avoir changé la configuration.

Au mois de mai 2008 a été découvert une faiblesse dans la génération des clés par OpenSSL des packages Debian et dérivés tels qu'Ubuntu. Pour résumer, si on a généré ses clés entre 2006 et mai 2008, il faut en créer de nouvelles après avoir mis à jour le système. Penser alors à bien rediffuser ces clés.

Si, après avoir suivi ce tutoriel, un mot de passe est toujours demandé, il se peut que ce soit dû à un problème de droits sur votre Dossier Personnel. Sur la machine distante, regarder le fichier /var/log/auth.log pour y trouver des indications et notamment si la ligne suivante apparaît :

Authentication refused: bad ownership or modes for directory /home/votre_login

Alors, faire :

chmod 755 $HOME

Et tout devrait rentrer dans l'ordre.

Si ce n'est toujours pas le cas, c'est que le serveur doit être configuré en mode de sécurité strict (c'est le cas par défaut sur Ubuntu). Effectuez les opérations suivantes :

- Sur le serveur : dans le fichier /etc/ssh/sshd_config, la ligne StrictModes yes indique que le serveur va être très pointilleux sur les droits du compte sur lequel on se connecte en ssh. saisir ensuite les commandes suivantes

chmod go-w ~/
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

- Sur le client, dans /etc/ssh/ssh_config, rajouter la ligne PreferredAuthentications publickey.

Parfois les clés des correspondants peuvent changer (réinstallation de machine par exemple), on a alors droit à ce charmant message :

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that the RSA host key has just been changed.
The fingerprint for the RSA key sent by the remote host is
xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx.
Please contact your system administrator.
Add correct host key in /home/<vous>/.ssh/known_hosts to get rid of this message.
Offending key in /home/<vous>/.ssh/known_hosts:4
RSA host key for <ip> has changed and you have requested strict checking.
Host key verification failed.

Soit l'information est exacte et une machine a été corrompue, ou bien il s'agit juste d'un changement de clé (réinstallation par exemple) et dans ce cas, il faut effacer les entrées dans le fichier .ssh/known_hosts du compte. Avant la chose était relativement simple, la clé était directement associée au nom ou à l'IP de la machine cible. Ce n'est plus le cas à présent où elle est associée par UUID rendant quasiment impossible l'identification visuelle de la ligne concernée. Mais ssh étant sympathique, il indique quelle est la ligne du fichier concernée. Pour reprendre l'exemple précédent on peut lire la ligne Offending key in /home/<login>/.ssh/known_hosts:4 → la clé en erreur est donc située ligne 4 du fichier .ssh/known_hosts

Il existe cependant une méthode plus subtile en employant la commande suivante :

ssh-keygen -R <ip>

On peut ainsi effacer seulement l'adresse IP concernée et relancer un ssh.

Si on souhaite se connecter par SSH avec une clef publique sur un compte dont le home est chiffré, il est important de faire attention à ce que sur le serveur le fichier/dossier .ssh/authorized_keys soit à la fois dans le home chiffré et déchiffré. En effet si le fichier authorized_keys est dans le home sous forme chiffrée (.private), open_ssh ne pourra pas lire la clef publique attendue. Il faut donc créer un dossier .ssh et y mettre le fichier authorized_keys quand le home est démonté donc chiffré. Cependant, si on ne le laisse pas aussi dans le home déchiffré et donc monté, la connexion SSH se fera avec la clef publique mais le home ne sera pas déchiffré automatiquement.

La meilleure solution est de créer des liens virtuels vers un dossier qui n'est pas soumis au chiffrement/déchiffrement comme expliqué ici

Authentification SSH avec plusieurs clés privées En principe chaque utilisateur possède une clé privée unique qui lui est propre, et envoie sa clé publique à autant de serveurs qu'il le souhaite. Cependant il est techniquement faisable de posséder plusieurs clés privées (mais c'est moins pratique et ça n'est pas plus sécurisé).

Lorsqu'on se connecte à plusieurs serveurs avec des clés privées différentes, il faut pouvoir indiquer à SSH quelle clé on veut utiliser pour la connexion, sinon, on rencontre par exemple l'erreur:

git@gitlab.com: Permission denied (publickey)

Pour indiquer au client SSH la clé qu'il doit utiliser pour chacun des serveurs, on peut créer un fichier ~/.ssh/config (ou /etc/ssh/ssh_config pour tous les utilisateurs de la machine) dans lequel il faut spécifier pour chacun des serveurs la clé qui doit être utilisée :

Host adresse-serveur-sans-passphrase.com
User votreutilisateur
IdentityFile ~/.ssh/key-sans-passphrase
  
Host adresse-serveur-avec-passphrase.com
User votreutilisateur
IdentityFile ~/.ssh/key-avec-passphrase

Pour plus d'options, comme l'utilisateur ou le port à utiliser par défaut, voir le manuel de ssh_config, cf. aussi l'aide de gitlab (en)

L'astuce pour différencier les clefs avec passphrase de celles sans passphrase, serait de créer une clef de type ECDSA pour les identifications sans passphrase et DSA pour les identifications avec passphrase. Ce qui donnerait pour le premier:

IdentityFile ~/.ssh/id_ecrsa.pub

et pour le second

IdentityFile ~/.ssh/id_rsa.pub

Retrouver l'empreinte de sa clef SSH, pour la communiquer à une personne qui veut se connecter et va utiliser notre clef publique :

sh-keygen -l

Ensuite la commande demande le fichier de la clef publique. Sur un serveur, on spécifiera /etc/ssh/ssh_host_rsa_key.pub.