Secure SHell
Cet article présente des trucs et astuces afin de configurer ses connections SSH.
Ma configuration SSH
Ci-joint ma config SSH côté serveur :
En gros ce qu’il faut retenir :
– On interdit l’accès au root,
– On limite le nombre de re-essais,
– On n’autorise que les accès par clef privé,
– Et enfin on autorise le forwarding X11.
Garder un tunnel SSH actif
Par défaut, la configuration SSH ferme la connection au bout d’un certain temps s’il n’y a plus d’activité.
Pour remédier à ce problème, notamment à travers Screen RC, plusieurs solutions :
– Si on a l’accès à la conf /etc/ssh/sshd_config
:
KeepAlive yes
ClientAliveInterval 60
– Depuis OpenSSH 3.8, il existe une option ServerAliveInterval qui peut être activée, sans accès root, et côté client, via le fichier $HOME/.ssh/config
:
ServerAliveInterval 60
ServerAliveCountMax 100
– Ou encore sur la ligne de commande : ssh -o TCPKeepAlive user@localhost
Une autre astuce est de générer de l’activité sur la machine distante :
– Par exemple via un scripte sh :
sh -c 'while echo "Tunnel..." ; do sleep 20 ; done'&
– Ou encore en Perl, on affiche sur la sortie d’erreur un caractère null :
perl -e 'sleep 59 && print STDERR "\x00" while 1' &
– Ou alors on affiche la date watch date
ou l’uptime watch uptime
Déploiement des clefs
– Pour rappel, on génère une clef SSH avec la commande : $ ssh-keygen -t dsa
;
– Cela créera une clef privée id_dsa
et une clef publique id_dsa.pub
dans le répertoire ~/.ssh
du user ;
– Puis, la clef publique est déposée sur l’environnement cible dans le fichier ~/.ssh/authorized_keys
du compte ciblé.
Agent SSH
Pour éviter d’entrer le mot de passe et/ou la passphrase :
– On démarre l’agent SSH qui se chargera d’enregistrer la clef :
$ ssh-agent
SSH_AUTH_SOCK=/tmp/ssh-kKx2097216/agent.2097216; export SSH_AUTH_SOCK;
SSH_AGENT_PID=573578; export SSH_AGENT_PID;
echo Agent pid 573578;
– Et exécuter dans le shell courant les commandes shell présentées,
– Rajouter la clef privée : $ ssh-add ~/.ssh/id_dsa
– Entrez la passphrase correspondante,
– Puis, tester une commande ssh (aucun mot de passe ne devrait être demandé :)
Rebonds SSH
Le besoin est d’accéder à un serveur à partir de son poste client via un proxy (rebond) en une seule commande !
La « commande magique » est d’utiliser le ProxyJump à partir du client (pour les versions récentes d’OpenSSH 7.3+) :
ssh -J user1@proxy1.fr user@server.fr
Rq. penser à déployer sa clé publique dans les comptes user1@proxy1.fr et user@server.fr et à charger sa clé privée dans son agent SSH pour plus de confort.
On peut simplifier la commande via le fichier de conf $HOME/.ssh/config
sur le client :
Host proxy
HostName proxy1.fr
Port 22
User user1
Host server
HostName server.fr
User user
ProxyJump proxy
Du coup la commande devient : ssh user@server
P.I. on peut enchaîner les « Jump » via une syntaxe du type :
ssh -J user1@proxy1.fr:22,user2@proxy2.fr:22,... user@server.fr
;)
Si ProxyJump n’est pas dispo. utiliser ProxyCommand :
ssh -o "ProxyCommand=ssh -W %h:%p user1@proxy1.fr" user@server.fr
Et si dans $HOME/.ssh/config
(tjrs sur le client) :
Host proxy
Hostname proxy1.fr
Port 22
User user1
Host server
HostName server.fr
User user
ProxyCommand ssh -W %h:%p proxy
La commande devient comme précédemment : ssh user@server
P.I. ce moyen de connexion est appelé « using stdio forwarding » mais si ça ne fonctionne y-a « l’ancienne méthode » via Netcat :
ssh -o "ProxyCommand=ssh user1@proxy1.fr nc server.fr 22" user@server.fr
Et dans le $HOME/.ssh/config
:
Host proxy
HostName proxy1.fr
Port 22
User user1
Host server
HostName server.fr
User user
ProxyCommand ssh proxy nc %h %p
La commande devenant : ssh prosys@server