Secure SHell

, par MiKaël Navarro

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 :

sshd_config

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

P.-S.

Ne pas oublier de vérifier les droits du dossier $HOME/.ssh et des fichiers contenus :

  • chmod 700 $HOME/.ssh
  • chmod 600 $HOME/.ssh/authorized_keys
  • chmod 600 $HOME/.ssh/config

On doit aussi vérifier les droits du $HOME pour enlever les droits d’écriture pour le group et others :

  • chmod go-w $HOME