Le fait que le premier S de ssh signifie “Secure” ne signifie pas qu’il n’est pas possible de tenter une attaque par force brute (ça veut simplement dire que le mot de passe ne transite pas “en clair” sur le réseau). Avec un outil tel que fail2ban ça devient à peu près impossible mais on peut faire encore un peu mieux pour être encore plus tranquille.

PermitRootLogin

Pour ceux qui ont encore un mot de passe pour l’utilisateur root, c’est une bonne idée de désactiver la connexion directe en root via ssh car si l’attaquant parvient à se connecter, il a accès à tout.

Dans /etc/ssh/sshd_config trouver la ligne qui commence par PermitRootLogin et mettre no au lieu de yes.

Authentification par clé publique

Il y a plusieurs méthodes pour s’authentifier via ssh, la plus courante est la saisie d’un mot de passe. Un attaquant peut les essayer un par un jusqu’à trouver le bon. Ça peut prendre du temps mais ça reste faisable.

Une autre solution très simple à mettre en œuvre consiste à s’authentifier avec sa clé publique. Le principe est le suivant : vous générez un couple clé publique/clé privée et vous installez, sur les machines où vous voudrez vous connecter, votre clé publique. Une fois celle-ci déverrouillée localement (sur votre poste local) vous vous connectez directement à vos machines.

Si vous avez lu le dernier paragraphe rapidement, vous avez peut-être manqué un élément important : vous déverrouillez une fois votre clé et ensuite vous vous connectez à toutes vos machines, aussi souvent que vous voulez, depuis autant de consoles/terminaux que vous voulez sans ressaisir de mot/phrase de passe. Vous pouvez donc également enchaîner les scp sans retaper de phrase de passe… C’est très confortable.

Et quand vous vous sentirez à l’aise (niveau 42), je vous conseille de jeter un œil à keychain/ssh-agent qui ajoute de la chantilly, des cerises (un glaçage pour les anglo-saxons) et des petits bâtons qui font des étincelles sur le gâteau.

Les clés publiques/privées

Je fais une petite digression sur les clés et la sécurité associée. Si vous connaissez le principe, vous pouvez sauter ce paragraphe.

Quand on génère un couple de clés, on fabrique 2 fichiers : une clé publique et une clé privée. La clé publique peut être diffusée où vous voulez, c’est le principe, elle est publique (c’est celle qui finit par .pub). Si quelqu’un chiffre un fichier (ou un message) avec, vous seul pourrez le déchiffrer (si vous avez la clé privée correspondante, bien sûr).

À l’opposé, la clé privée est… privée. Donc seulement pour vous. Cette clé privée peut être verrouillée par une phrase de passe (c’est exactement comme un mot de passe mais plus long/plus compliqué). Donc pour utiliser la clé privée (pour déchiffrer un message préalablement chiffré avec votre clé publique par exemple), votre machine vous demandera avant tout de déverrouiller votre clé privée en saisissant votre phrase de passe. Ce déverrouillage est local. La phrase ne transite pas sur le réseau.

Vous devez absolument éviter que votre clé privée soit copiée ou vue par un tiers. Pourquoi me direz-vous puisqu’elle est (généralement) protégée par une phrase de passe compliquée ?
Parce-que si j’ai une copie de votre clé privée, je peux chercher la phrase de passe correspondante par force brute (en essayant toutes les combinaisons possibles) tranquillement, chez moi, en utilisant toute la puissance de calcul à ma disposition sans que vous puissiez faire quoi que ce soit pour m’en empêcher ou me ralentir.
En général, les systèmes exigent que votre clé privée soit a minima en lecture exclusivement pour vous (chmod 600).

Vous avez noté que j’ai plusieurs fois sous-entendu qu’une clé privée puisse ne pas être verrouillée par une phrase de passe. Cela correspond à un usage particulier des clés : un usage automatique, sans intervention utilisateur. Par exemple, si je veux qu’une tâche cron copie un fichier via ssh, je peux utiliser une clé privée non verrouillée : ça veut dire que si quelqu’un met la main sur la clé privée, il peut se connecter avec ce compte. Il suffit de vous débrouiller pour que la connexion via ce compte soit sans danger : interdiction de connexion “shell” sur ce compte (donc seulement des scp) et que l’utilisateur auquel on accède n’ait pas de droit (d’écriture au moins) sur le système.

Comment on fait ?

1. Génèrer un couple de clés.

Faites ça sur votre machine principale. C’est là que résidera votre clé privée.

gosane@bast:~$ ssh-keygen
Generating public/private rsa key pair.
Enter file in which to save the key (/home/gosane/.ssh/id_rsa): 

Laissez le choix par défaut (en appuyant sur <Entrée>).

Created directory '/home/gosane/.ssh'.
Enter passphrase (empty for no passphrase): 

Là, je ne vous fais pas de dessin, si ça s’appelle passphrase c’est parce-qu’il faut faire long. Donc allez-y pour un truc facile à taper, genre “Les sanglots longs des violons de l’Automne”. Vous avez droit aux caractères spéciaux et aux chiffres si ça vous amuse (personnellement, je suis généralement contre pour cette raison mais c’est vous qui voyez).

Enter same passphrase again: 

La même hein 🙂

Your identification has been saved in /home/gosane/.ssh/id_rsa.
Your public key has been saved in /home/gosane/.ssh/id_rsa.pub.

Donc que ce soit bien clair : le fichier id_rsa est la clé privée, id_rsa.pub est la clé publique. Si vous regardez les droits sur les fichiers, il n’y a pas d’ambiguïté :

gosane@bast:~$ ls -l .ssh
-rw------- 1 gosane gosane 1766 août  17 19:03 id_rsa
-rw-r--r-- 1 gosane gosane  393 août  17 19:03 id_rsa.pub
       ^ lisible par tout le monde = public :-)

2. Marquer votre territoire

Supposons que votre serveur s’appelle server et que votre compte là-bas soit toto. D’habitude, vous vous connecteriez en tapant : ssh toto@server.

On va installer votre clé publique sur server dans le fichier /home/toto/.ssh/authorized_keys.

• soit vous le faites à la main en copiant/collant le contenu de la clé publique :

  gosane@bast:~$ cat .ssh/id_rsa.pub 
  ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDAXMDM6hq2JYFGmLAoScvkLIzNCG5z0x2UB+wN6tDbQBaFjTRYq8WbCQK2tZASbWk+CzVKvgCnOeWd5NTzdatQIdSNV2zzId8jqNurceu+qFE6s2lltPKYIZQAjNp7YEM41dlNp7ZPdF3pA6kSG+s5UVfdJK939m6OtxibpYdrqSToVJ9++lYCqZ06R8KmLeTbQob58FMrcObcXsTwE3m10YrOyR8BhjWbsdCIDRnhSqMa+FWmfnBiUFQDoA8M8H3XMXm0aDlb2DhY2lTPtKrkGyxqleHDBu5GialKFl+FLYUyjYWMRVC0L6XtiLXu1PPHNU/FHg1yW97YERKuOkpl gosane@bast
  

C’est une seule ligne qui commence à “ssh-rsa…” et qui finit par “…gosane@bast”

Et vous collez ça dans /home/toto/.ssh/authorized_keys (sur server) sur une ligne toute seule.

• soit vous êtes un(e) bon(ne) flemmard(e) et vous utilisez la commande appropriée, le résultat est le même :

  ssh-copy-id toto@server
  

Vous indiquez le mot de passe, celui que vous auriez utilisé pour vous connecter “normalement” par ssh toto@server

Et… c’est tout.

Vérifiez que ça marche bien : ssh toto@server, la première fois vous devrez déverrouiller la clé avec la phrase de passe (Les sanglots longs…).

Ok c’est bon, Ctrl-D pour vous déconnecter et à nouveau :

ssh toto@server et… vous devriez être connecté(e) directement.

Plus rien d’autre

Quand vous êtes sûr(e) que ça fonctionne bien, vous pouvez interdire (sur server) purement et simplement les connexions par mots de passe classiques. Dans /etc/ssh/sshd_config :

PasswordAuthentication no

N’oubliez pas de redémarrer le service ssh (sudo service ssh restart par exemple). Et maintenant, bon courage les pirates.

Voyez plus loin

Et si vous devez vous connecter aussi sur une autre machine avec un autre compte, c’est pareil :

ssh-copy-id titi@meregrand

Et c’est la même clé (déverrouillée une seule fois donc).

N’oubliez pas aussi que vous pouvez créer un fichier .ssh/config où, en bon(ne) flemmard(e), vous vous serez simplifié la vie :

Host server
User toto

Host meregrand
User titi

Ce qui vous permet de juste faire ssh meregrand et d’être connecté en tant que titi sans avoir à retenir le login utilisé.

Notez bien que vous pouvez très bien (si vous autorisez les connexions en root) ajouter votre clé publique au compte root d’une machine (dans /root/.ssh/authorized_keys donc). Je ne le recommande pas mais il y a des cas où c’est sans danger voire obligatoire (il n’y a qu’un compte root sur la machine).

Dans le même esprit, si vous vous connectez en ssh avec Nautilus (le gestionnaire de fichiers de gnome) à une machine sur laquelle se trouve votre clé publique, ça marche aussi. Pour essayer, ouvrez Nautilus, tapez Ctrl-L pour accéder à la barre d’adresse et tapez ssh://meregrand. N’oubliez pas, vous êtes titi donc vous ne pouvez écrire que dans /home/titi et dans /tmp.

Et une dernière pour prendre la main à distance en mode graphique via ssh. Il faut installer x11vnc sur votre machine locale et vncviewer sur la machine distante (les deux packages sont dispos sur Debian/Ubuntu).

Ensuite, faites un petit script view_meregrand.sh sur votre machine locale contenant :

#!/bin/sh
ssh -f -L 5900:localhost:5900 titi@meregrand \
        x11vnc -ncache 10 -safer -localhost -nopw -once -display :0 \
        && sleep 2 \
        && vncviewer -encodings tight localhost:0

Et simplement :

sh view_meregrand.sh

Attention quand même

Ne laissez pas une machine sur laquelle vous auriez déverrouillé votre clé privée en libre accès… Mais bon, vous n’êtes pas débile…