On néglige trop souvent la sécurité sur un serveur Internet, pourtant, il est vital de se protéger.
Ici, nous aborderons un aspect un peu trop passé aux oubliettes, l’authentification par systèmes de clés privés/clés publiques RSA (la méthode pour DSA est strictement la même, juste changer RSA en DSA dans les étapes suivantes).
On va même aller plus loin à la fin, désactiver complètement root (y compris via les clés) et l’authentification par mot de passe (risqué)

Configuration du serveur

Ouvrez avec votre éditeur de texte favoris le fichier de configuration du démon SSH (/etc/ssh/sshd_config pour Debian par exemple) et ajoutez ces lignes :

(La ligne AuthorizedKeysFile indique à sshd où aller chercher les clés publiques, %h représente le nom de l’utilisateur local du système)
Sauvegardez et fermez la config avant de relancer le démon SSH.
(Trick : un

ne kill pas la session SSH a partir duquel il aurait été lancé)

Création des clés

Sous Windows

Nous allons avoir besoin de l’outil PuTTYgen afin de générer les clés RSA.
Lancez le, sélectionnez RSA, et une taille de clé (1024 bits est une bonne valeur, ne descendez pas en dessous de 512 bits), et cliquez sur « Generate ».
Vous devez bouger votre souris dans le cadre prévu à cet effet, ce qui génèrera de l’entropie, afin de s’assurer que la clé sera unique.

Une fois le couple de clés crées, vous pourrez y rajouter un commentaire pour la clé (indispensable pour savoir à qui appartient la clé) et y mettre une passphrase. La passphrase va servir a encrypter la clé privée. Sans cette passphrase, impossible d’utiliser la clé.

Puis enfin, on clique sur « Save Private Key » et « Save Public Key ».
Veillez à bien ranger (voir protéger dans un répertoire Utilisateur crypté) votre clé Privée.

Les fichiers ressemblent à ça :
Clé privée

Clé publique

(Vous noterez que la clé publique est contenue au début du fichier contenant la clé privée)

Afin de rentre compatible votre clé Publique générée, nous allons modifier quelques lignes.

• Copier le commentaire entre les guillemets, a la fin de la clé
• ajouter « ssh-rsa » en début de clé
• Supprimer les deux premières lignes
• Supprimer la dernière ligne
• Supprimer les retours à la ligne

Vous devriez vous retrouver avec un fichier qui ressemble à celui-ci :

Il ne reste qu’à copier la clé publique dans le fichier « $HOME/.ssh/authorized_keys » de du compte utilisateur sur la machine distante (une clé publique par ligne du fichier) et configurer PuTTY :

Indiquez le host sur lequel se connecter, puis renseignez le chemin de la clé privée dans « Con­nec­tion » -> « SSH » -> « Auth« . Dans la rubrique « Connection » -> « Data » il est également possible de renseigner le login a utiliser automatique à la connexion. (même effet que de mettre login@host dans la case réservée au hostname)

Sous Linux

Pour générer le couple de clés RSA, on va utiliser la commande ssh-keygen :

L’option -C défini le commentaire qu’on va attribuer à la clé publique.
Le script demandera une éventuelle (fortement recommandée tout de même) PassPhrase.

Par défaut, les clés seront générées dans ‘$HOME/.ssh/id_rsa’ et ‘$HOME/.ssh/id_rsa.pub’ pour les clés privées et publiques. (On peut noter que la clé privée a un masque en 600)

Il ne reste qu’à copier la clé publique dans le fichier « $HOME/.ssh/authorized_keys » de du compte utilisateur sur la machine distante (une clé publique par ligne du fichier).
Si vous avez enregistré votre clé publique à l’endroit par défaut, plus rien a configurer, sinon « ssh -i /path/to/rsa_key.pub ».

Désormais, lors de vos connexions à vos serveur favoris, le système vous demandera la passphrase (si vous en avez configuré une) plutôt que le mot de passe du compte Unix.

Pour aller plus loin

(parce que j’aime bien pousser les choses un peu plus)

N’autoriser la clé que pour une IP en particulier

Il est tout a fait possible de demander au serveur distant de n’autoriser la connexion pour une clé a partir d’une IP, il suffit de rajouter, devant ssh-rsa un champ supplémentaire : from= « ip » . Ainsi, on se retrouve avec :

Désactivations

• On peut désactiver la connexion root par SSH (enfin il est même nécessaire de désactiver root par SSH, mais activez sudo avant…) :
view source

print?

1	aptitude install sudo

2	sudoedit /etc/sudoers

et rajoutez une ligne dans ce style (my_secured_account est bien sur le nom de votre compte shell) :

view source

print?

1	my_secured_account   ALL=(ALL) ALL

Puis connectez vous sur votre my_secured_account et tapez sudo -s (il vous demande un mot de passe la première fois, souvenez-vous en !!! et RTFM pour l’utilisation de sudo, mais c’est super simple.) pour obtenir un privilège root par exemple.
Enfin, désactivez le login de root dans sshd_config :

view source

print?

1	PermitRootLogin no

• On peut désactiver complètement la connexion par mot de passe :
view source

print?

1	PasswordAuthentication no

2

UsePAM no

ATTENTION ! Ce n’est pas ma faute si vous n’avez plus accès à votre serveur suite à ces deux dernières modifications (FACULTATIVES bien sur)

Source : Anthony Desvernois