Turris Omnia : se connecter en ssh avec une clé

ephase |

J’utilise depuis maintenant deux ans un routeur Omnia de chez Turris, J’en ai parlé déjà lors de cet article. Je veux pouvoir m’y connecter en SSH de façon sécurisée; j’entends par là avec un utilisateur autre que root et avec une clef (si possible en ed25519).

Si en règle générale OpenWRT est livré avec dropbear pour servir ssh, le Turris Omnia utilise OpenSSH en version 8.0p1 au moment de l’écriture de cet article.

Créer un utilisateur non privilégié

C’est la première étape, tout est déjà prévu ou presque : on a bien l’utilitaire useradd mais le répertoire home n’est pas présent. Il faut donc se connecter en ssh sur le routeur puis renter les commandes suivantes :

mkdir /home
useradd -m user
chmod 700 /home/ephase

Il faut maintenant définir le mot de passe pour cet utilsateur :

passwd user

Ajouter sa clé au nouvel utilisateur

Depuis ma machine, je n’ai plus au’à rajouter la partie publique de ma clé sur le compte de l’utilisateur fraîchement créé :

ssh user@192.168.1.254 "umask u=rwx,g=,o=; mkdir ~/.ssh && tee -a \ 
~/.ssh/authorized_keys" < ~/.ssh/ma_cle.ed25519.pub

192.168.1.254 est l’adresse de mon Turris Omnia et ~/.ssh/ma_cle.ed25519.pub la partie publique de ma clé.

Il ne reste plus qu’à contrôler que tout se passe bien en se connectant avec la clé:

ssh user@192.168.1.1 -i ~/.ssh/ma_cle.ed25525

Si la connexion se passait mal, le simple fait de rajouter -vvv à la fin de la commande précédente permettrait d’en apprendre un peu plus sur ce qui ne va pas.

Sécuriser son accès

Maintenant que la connexion par clé est fonctionnelle, il est possible de sécuriser son accès. Comme on est connecté avec notre utilisateur ‘normal’, il faut commencer par utiliser su pour passer en super-utilisateur.

Première chose, empêcher la connexion par mot de passe : 

uci set sshd.@openssh[0].PasswordAuthentication='no'

Puis empêcher la connexion du super-utilisateur. Il sera tout de même possible d’utiliser su une fois connecté avec notre utilisateur standard comme nous l’avons fait prédédement.

uci set sshd.@openssh[0].PermitRootLogin='no'

Il est aussi de bon ton de forcer l’utilisation de la version 2 du protocole:

uci set sshd.@openssh[0].Protocol='2'

Il ne reste plus qu’à valider les changement et redémarrer le serveur ssh :

uci commit
/etc/init.d/sshd restart

Pour aller plus loin

Si vous voulez sécurise encore plus votre installation, je vous conseille la lecture de l’article OpenSSH : Durcir la configuration du serveur SSH de Stéphane Huc.

J’ai pour ma part choisi de recréer les clefs serveur pour n’utiliser que ed25519 et rsa (4096 bits de longueur):

cd /etc/ssh/
rm -rf *_key,*_key.pub
ssh-keygen -t ed25519 -f ssh_host_ed25519_key -N ""
ssh-keygen -t rsa -b 4096 -f ssh_host_rsa_key -N "" -o -a 64

De modifier la configuration en conséquence à l’aide d’uci:

uci add_list sshd.@openssh[0].HostKey='/etc/ssh/ssh_host_ed25519_key'
uci add_list sshd.@openssh[0].HostKey='/etc/ssh/ssh_host_rsa_key'

Et de relancer le service

uci commit
/etc/init.d/sshd restart

En conclusion

J’ai maintenant une configuration SSH un peu plus robuste grâce à OpenSSH. Bien sûr dropbear est installé la plupart du temps sur OpenWRT, il est toujours possible de l’installer (avec la commande opkg install openssh-server par exemple) mais sa configuration se fera en éditant le fichier /etc/ssh/sshd_config.

Bibliographie