OpenWRT : OpenSSH pour remplacer Dropbear

Article publié, le 20 Septembre 2020 et modifié le 2 Mai 2023
4 minutes de lecture

Cet article contient 756 mots.
Source brute de l'article :
Commit version : d52797e

Description

Par défaut, OpenWRT est livré avec Dropbear. Bien que ce serveur SSH utilise seulement la version 2 du protocole SSH, et soit léger, il comporte quelques lacunes :

Il a un support partial du protocole SFTP ; il faut lui adjoindre le paquet openssh-sftp-server pour que ce soit fonctionnel.
Il n’a aucune séparation de privilège utilisateur.
Il n’a pas officiellement de support des modules cryptographiques, approuvés par la FIPS 140-2. (bien que dans notre contexte particulier, ce ne soit pas une nécessité)
Depuis, la version 2020.79, Dropbear semble gérer l’utilisation des algorythmes à courbes Elliptiques - ce qui n’est pas le cas des versions précédentes, incluses avant 19.07.4 - tel que :
- hostkey ed25519
- le chiffrement chacha20-poly1305
- voire les signatures de clés au format rsa-sha2

Installation

# opkg update
# opkg install openssh-server openssh-moduli

Info

Le paquet openssh-moduli n’est pas strictement nécessaire. Pour rappel, le fichier /etc/ssh/moduli est un fichier contenant les nombres premiers et les générateurs à utiliser par le serveur SSH dans la méthode d’échange des clés de groupe DH . Préférez l’installer…

Configuration

Dropbear

Mieux vaut laisser Dropbear sur le port par défaut.

Néanmoins, vous pouvez le reconfigurer soit par l’interface LuCI, soit en mode console - ce qui peut se faire ainsi :

# uci set dropbear.@dropbear[0].Port=xxx
# uci commit dropbear
# /etc/init.d/dropbear restart

où xxx est le numéro de port que vous choisirez !

puis connectez-vous au serveur sur ce nouveau numéro de port.

OpenSSH

Fichier de configuration : /etc/ssh/sshd_config

Les recommandations de bases suivantes s’appliquent ABSOLUMENT :

n’utiliser QUE la Version 2 du protocole,
NE PAS permettre au compte root de se connecter,
désactiver l’authentification par mot de passe,
n’utiliser QUE l’authentification par clés.

Nous allons en profitez pour durcir la configuration par défaut :

recréons les clés d'hôtes proprement. Et tant qu’à faire, autorisons QUE les clés au format Ed25519. Lisez mon autre article , pour savoir comment créer de manière correcte des clés au format ed25519.

Info

À savoir qu’au démarrage du serveur OpenSSH, il recréera les clés ECDSA.

autorisons QUE :
- les chiffrements forts,
- les algorithmes suivants :
  - d’échange de clés ,
  - de clés d'hôtes
  - des codes d'authentification de messages ,

Attention

Les algorithmes des clés d’hôtes sk-ssh-ed25519@openssh.com,sk-ssh-ed25519-cert-v01@openssh.com ne semblent pas être reconnus ; NE les ajoutez PAS !

Pour finir, ne configurez pas le service sur le port 22 ; en cas de problème, Dropbear pourra toujours vous être utile, même s’il faut le réactiver !

Fichier moduli

Si vous avez installé le paquet openssh-moduli, il serait préférable de n’accepter que les échanges de clés de groupe DH supérieure ou égale à 3072 bits.

Avant de le modifier, sauvegardons le fichier, au cas où…

# cp /etc/ssh/moduli /etc/ssh/moduli.bckp
# chmod 0400 /etc/ssh/moduli.bckp

Ensuite, il faut le recréer

Astuce

Si vous avez configuré correctement un utilisateur ayant des droits sudo :

# sudo awk '$5 >= 3071' /etc/ssh/moduli | sudo tee /etc/ssh/moduli.safe
# mv /etc/ssh/moduli.safe /etc/ssh/moduli

TL;DR

Voici un exemple minimaliste du fichier de configuration du serveur :

HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_ed25519_key

Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com
KexAlgorithms curve25519-sha256,curve25519-sha256@libssh.org,
HostKeyAlgorithms ssh-ed25519,ssh-ed25519-cert-v01@openssh.com,rsa-sha2-256,rsa-sha2-512,rsa-sha2-256-cert-v01@openssh.com,rsa-sha2-512-cert-v01@openssh.com
MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com

PermitRootLogin no
MaxAuthTries 3

PubkeyAuthentication yes

AuthorizedKeysFile	.ssh/authorized_keys

PasswordAuthentication no
PermitEmptyPasswords no

Subsystem	sftp	/usr/lib/sftp-server

Attention

Vous avez paramétré l’option ListenAddress ? Oubliez ou vous buterez face à une situation de compétition !

Gestion des services

Service OpenSSH

Et, voilà, maintenant, il ne vous reste plus qu’à vous connecter… après avoir testé la configuration puis activé et démarré le service :

# sshd -t

Si la configuration est valide :

# /etc/init.d/sshd enable
# /etc/init.d/sshd start

Service Dropbear

Vous pouvez vous connecter au service d’OpenSSH, sans soucis ? Maintenant, vous pouvez arrêter et désactiver le service :

# /etc/init.d/dropbear stop
# /etc/init.d/dropbear disable

Sauvegarde système

Normalement, le répertoire /etc/ssh et ce qu’il contient est inclus dans la sauvegarde système par l’outil sysupgrade.

Pour le vérifier : # sysupgrade -l | grep ssh

Si ce n’est pas le cas, éditez le fichier /etc/sysupgrade.conf et ajoutez le répertoire.

Dépannage

Situation de compétition

⇒ Impossible de se connecter après un redémarrage :

Avez-vous paramétré l’option ListenAdress dans le fichier de configuration du service ?

Si oui, désactivez la ligne correspondante . Du fait d’une situation de compétition, le démarrage du service OpenSSH ne peut pas s’effectuer.

Si vous spécifiez l’option ListenAddress, OpenSSH s’exécutera lorsque vous le démarrerez. Néanmoins, au redémarrage de la machine, OpenSSH échouera à démarrer car il ne trouvera pas les interfaces réseau !

Donc, évitez de spécifier cette option et configurez le parefeu pour n’autoriser que sur l’interface de votre LAN.

source