Une configuration SSH plus moderne đź”—
Introduction¶
En ces temps de confinement généralisé, SSH est votre ami. Du moins, SSH est mon ami. Car sans lui, je serai bien en peine de respecter le télétravail recommandé par le confinement (ainsi qu'avec Wireguard, mon autre ami).
Oui, car c'est avec SSH que j'accède aux machines à distances via plusieurs moyens (en direct via Wireguard ou en utilisant le mode tunnel pour quelques applications).
ssh-audit¶
Par hasard, j'ai trouvé un programme d'audit SSH nommé ssh-audit. Il est disponible sous Debian. L'objectif de ssh-audit est de tester un serveur SSH et indiquer les éléments de configuration qui posent problème en suivant les différents CVE. Attention, ssh-audit date de 2016 il n'est donc plus nécessairement à jour par rapport aux différentes failles de sécurité spécifique de SSH. Mais dans la pratique, ça peut être un bon outil pour commencer à améliorer votre configuration.
D'une manière générale, ssh-audit est trivial à utiliser. Son intérêt
essentiel, c'est qu'il vous indiquera en rouge ce qui ne va pas. Chez
moi, il s'agissait principalement des modes d'échange de clef
(KexAlgorithms dans la configuration), les algorithmes de
chiffrements, les fonctions de hash. Après audit, j'ai ajouté les
lignes suivantes dans /etc/ssh/sshd_config
, afin d'utiliser
uniquement des protocoles/fonctions éprouvées d'un point de vue
sécurité:
KexAlgorithms curve25519-sha256@libssh.org
HostKeyAlgorithms ecdsa-sha2-nistp521-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,rsa-sha2-512-cert-v01@openssh.com,rsa-sha2-256-cert-v01@openssh.com,ssh-rsa,ssh-ed25519
Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr
MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,umac-128-etm@openssh.com
Vous pouvez vous référer au manuel d'OpenSSH pour avoir plus
d'informations sur ces 4 directives. Attention, modifier cette
configuration revient souvent à invalider les clefs SSH autorisées
(pour cause de changement de hash bien souvent). Il vous faudra faire
un peu de ménage dans votre fichier ~/.ssh/authorized_keys
.
AmĂ©lioration de la continuitĂ© de connexion¶
J'avais aussi un autre problème à régler: mon serveur de "bastion"
(qui est en fait un vulgaire PC de bureau) se déconnectait
relativement souvent, figeant ainsi la connexion SSH. Le problème
vient de la configuration du routeur du bureau qui coupe les
connexions sortantes de manière un peu trop rapide (on est dans un
intervalle de moins d'une minute). De fait, la connexion Wireguard, Ă
défaut de générer du trafic sortant au niveau du bastion, s'interrompt
toutes les minutes. J'aurais pu régler ça en utilisant la directive
PersistentKeepalive
de la connexion pour la mettre en phase avec la
configuration du routeur mais ça me semblait être un peu trop lourd de
générer du trafic même quand la connexion n'est pas utilisée.
Au lieu de ça, j'ai ajouté les lignes suivantes dans mon fichier de
configuration client SSH (~/.ssh/config
)
# Accès au serveur de bastion
Host vpnwork
User me
ServerAliveInterval 15
ServerAliveCountMax 1
La directive ServerAliveInterval teste la connexion distante toutes les 15 secondes. Ça génère assez de trafic pour laisser la connexion disponible et ne pas avoir d'état fantôme dans le shell distant.
Rebondir vers des machines distantes¶
Un truc que j'ai redécouvert pendant le confinement, c'est le rebond: accéder à une machine distante via une autre machine. Il y a encore quelques années c'était assez pénible à gérer dans SSH (il fallait indiquer des commandes à exécuter). De nos jours, la directive ProxyJump fait tout le travail.
# Accès à la VM1
Host vm1
User me
ProxyJump vpnwork
# Accès à la VM2
Host vm2
User other
ProxyJump vpnwork
Dans cette condition, ProxyJump va déclencher une première connexion sur le serveur de bastion (vpnwork ici) puis utiliser cette connexion pour attaquer les autres machines, comme si on était sur le réseau local. C'est très pratique car ça permet de faire des choses aussi simples que:
ssh vm2
permet d'attaquer la machine vm2 en direct, par rebond, sans avoir Ă se soucier de la configuration du rebond (en plus l'auto-completion Bash fonctionne avec les noms d'hĂ´te, c'est tout simplement magique).
On peut également l'utiliser avec un tunnel pour accéder à du RDP par exemple:
ssh -f -N -L localhost:3389:vm2:3389 vpnwork
Je vous laisse lire le manuel d'OpenSSH pour comprendre les détails de la commande (cet article n'est pas un tutoriel maintenu).
Conclusions¶
En 2020, OpenSSH reste plus que jamais d'actualité. D'une manière générale, je crois que ce dernier demeurera, pour de nombreuses années encore, un incontournable de l'administration système distante et sécurisée. Rendez-vous compte qu'OpenSSH est sorti il y a près de 20 ans et que c'est encore une solution de référence. Rares sont les programmes de 2020 qui peuvent se targuer d'avoir le même pedigree, dans un monde où la durée de vie d'un produit informatique n'excède pas quelques mois avant de devenir obsolète.