connexion SSH & petit piège Ubuntu

Une fois mon nouveau serveur perso installé, sous Ubuntu 22.04.2 LTS, j’ai évidemment cherché à restreindre l’accès SSH en interdisant la connexion via mot de passe. Simple comme bonjour pour des administrateurs éclairés, et pourtant c’était sans compter sur un petit piège nouveauté !

Pré-requis

Savoir installer un serveur Ubuntu
Avoir installé & activé OpenSSH
Comprendre les commandes de bases UNIX
Savoir éditer les fichiers de configuration dans la console, avec nano par exemple

De quoi je parle ?

Dès lors que t’as installé ton nouveau serveur, tu as très vite envie de le ranger dans un coin, sans clavier, sans souris, sans écran et tu veux l’administrer depuis un autre ordinateur via la console. Grâce au serveur OpenSSH installé et démarré, tu pourras t’y connecté depuis un client SSH via la console de ton UNIX préféré (si tu utilises Windows tu peux déjà arrêter de lire mon blog hein ^_^). Classiquement tu y accéderas via la commande classique dont voici un exemple :

ssh hl0dwig@192.168.1.20

De base, ton serveur SSH demandera alors le mot de passe du compte, ici celui de « hl0dwig » pour t’y connecter et c’est terminé. Sauf que, si tu veux pouvoir administrer ton serveur en dehors de ton réseau local, tu auras envie de l’exposer à internet, d’ouvrir le port 22 et de rediriger toutes les requêtes de connexion SSH à ton serveur pour que tu puisses y accéder toi-même depuis internet. Ou alors ton serveur est déjà hébergé quelque part sur internet, donc tu as d’autant plus envie de sécuriser son accès !

Évidemment on a pas envie que ce soit facile pour n’importe qui d’accéder à ta console depuis internet, donc un simple mot de passe pour protéger ta connexion SSH, c’est un peu léger, on va préférer une authentification par clef RSA ! (PS: pense aussi à installer et activer Fail2Ban qui bannira les IP de gens malicieux qui tenteront de se connecter à ta console)

Pour se faire, c’est simple, tu génères une clef unique sur les postes depuis lesquel tu veux administrer ton serveur. Tu lances une commande toute simple :

ssh-keygen

Cela aura pour effet de créer ce qu’il te faut sur ton poste pour l’identifier de façon unique. Tu dois maintenant copier la clef publique générée et la mettre au bon endroit sur ton serveur de façon à ce qu’il sache que ce poste peut s’y connecter. La commande pour faire ça :

ssh-copy-id hl0dwig@192.168.1.20

Concrètement ça ajoutera ta clef au bon endroit sur ton serveur de façon ultra simplifiée (dans le fichier ~/.ssh/authorized_keys). Maintenant il faut dire au serveur d’interdire toute tentative de connexion par mot de passe !

ssh hl0dwig@192.168.1.20
nano /etc/ssh/ssh_config

On cherche les 2 lignes suivantes :

# To disable tunneled clear text passwords, change to no here!
#PasswordAuthentication yes

On édite pour décommenter la ligne et passer à « no » :

# To disable tunneled clear text passwords, change to no here!
PasswordAuthentication no

Et là on redémarre le serveur SSH :

sudo systemctl restart sshd
exit

A partir de maintenant il ne sera plus possible de se connecter à ton serveur sans avoir au préalable ajouter une clef RSA au serveur. Tu peux le vérifier en passant l’option -v en t’y connectant :

ssh hl0dwig@192.168.1.20 -v

Tu y verras une ligne :

debug1: Authentications that can continue: publickey

Mais il y a un piège

Si comme moi tu as installé la toute dernière version d’Ubuntu Server, tu auras une surprise ! Malgré la modification dans le fichier principal de configuration du serveur SSH tu auras :

debug1: Authentications that can continue: publickey,password

La surprise vient d’un sous fichier de configuration bien rangé dans un sous dossier qui est lu par ton serveur SSH, et j’imagine qu’il a été ajouté pour prévenir les pertes d’accès intempestives aux serveurs distants sur VPS :p Jette un oeil à :

sudo nano /etc/ssh/sshd_config.d/50-cloud-init.conf

Tu vas trouver une ligne connue à modifier, tu redémarres une nouvelle fois le serveur SSH, et maintenant tout roule ma poule !