Openssh

Authentification par clef SSH

Au lieu de s'authentifier par mot de passe, les utilisateurs peuvent s'authentifier grâce à la cryptographie asymétrique et son couple de clefs privée/publique, comme le fait le serveur SSH auprès du client SSH.

Générer ses clefs

Pour générer un couple de clefs, tapez sur le client:

ssh-keygen -t ed25519

Ensuite, il faut envoyer le fichier ~/.ssh/id_ed25519.pub du client sur le serveur, tapez sur le client:

scp /home/user/.ssh/id_ed25519.pub USER@SERVEUR:/home/user/.ssh/authorized_keys

Déactiver l'authentification par mot de passe

Si nous voulons déactiver l'accès par mot de passe, il faut ajouter la ligne suivante au fichier /etc/ssh/sshd_config:

[...]
PasswordAuthentication no

Déactiver known hosts de SSH

Problème

Lors d'une exécution d'un script contenant du SSH, et lorsque vous avez changé une de vos machines sur la quelle vous vous connectez, ssh demande une intervention humaine:

The authenticity of host '192.168.1.2 (192.168.1.2)' can't be established.
ECDSA key fingerprint is XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX.
Are you sure you want to continue connecting (yes/no)?

Lorsque vous avez change l'ordinateur en gardant la même IP:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@       WARNING: POSSIBLE DNS SPOOFING DETECTED!          @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
The RSA host key for foo-bar.net has changed,
and the key for the corresponding IP address 127.0.0.1
is unchanged. This could either mean that
DNS SPOOFING is happening or the IP address for the host
and its host key have changed at the same time.
Offending key for IP in /home/user/.ssh/known_hosts:6
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!

Le problème avec cette intervention est que le script n'avance pas sans vous. Pour ma part, j'ai un script qui se lance lors d'une coupure électrique, sans mon intervention mon script qui permet l'extinction de mes machines virtuelles ne ce termine pas... c'est pas cool.

Résolution

Voici une solution que j'ai trouvé: il faut passer des paramètres a notre commande SSH:

ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no root@192.168.1.2

ATTENTION

Ceci désactive la vérification de la somme de contrôle des clés SSH. Ne faîtes ceci que si vous savez ce que vous faîtes car cela rend votre connexion plus sensible à des attaques man in the middle.

Séquences d'échappement

Parfois lors de la perte d'une session SSH (problème de connexion ou bug coté serveur) le SHELL ne renvoi pas de broken pipe, ce qui fait que l'on se retrouve avec un terminal bloqué (hyper casse couille) et la seule façon de s'en sortir est d'user de la commande kill. La seule ? Pas tout à fait.

Il existe un truc qui déchire et qu'on ne trouve nul par (c'est toujours les meilleurs choses les mieux gardées) : les séquences d'échappement.

Ces séquences permettent d'interagir avec le SHELL se trouvant en dessous de la session SSH via le client OpenSSH lui même. Ainsi, on peu demander à ce cher client de tuer lui même la session au lieu de devoir le faire à sa place quand rien ne va plus (sympa non ?).

Liste

Voici la liste exhaustive de ces merveilles (à précéder par la touche <Entrer>):

• ~. : Termine la connexion (et toute les sessions multiplexées)
• ~B : Envoi un BREAK au système distant
• ~C : Ouvre un prompt ssh (la commande ? permet de lister ce que l'on peut y faire)
• ~R : Renégocie la clé de session (SSH version 2 uniquement)
• ~V/v : Augmente/diminue le degré de verbosity (LogLevel)
• ~^Z : Met SSH en pause
• ~# : Liste toute les connexions redirigées
• ~& : Quitte la session SSH sans la fermer. On ne peut pas revenir dessus, ça ne sert donc complètement à rien (je ne vois pas pourquoi quelqu'un à développer ça ?!)
• ~? : Écrit cette liste en anglais avec le vrai texte
• ~~ : Dans le cas ou le tild (~) entre en conflit avec quelque chose, il est possible de le taper 2 fois avant une séquence d'échappement pour l'envoyer.

INFORMATION

Ceci ne fonctionne que lorsque le SHELL ne nous donne pas la main. Vous pouvez tester sur une page de man pour tester par exemple.

Sources de la section

• https://askubuntu.com/questions/29942/how-can-i-break-out-of-ssh-when-it-locks
• https://lonesysadmin.net/2011/11/08/ssh-escape-sequences-aka-kill-dead-ssh-sessions/amp/

Absence de broken pipe après un redémarrage

Sur une Debian 8 (Jessie), le fait de redémarrer une machine alors que l'on est connecté en SSH sur celle-ci ne renvoi pas de broken pipe (la session n'est pas clôturée à l'extinction). Ceci est très énervant car on se retrouve avec un terminal bloqué sur un prompt inactif et l'arrivé du fameux broken pipe se fait, dans le meilleur des cas, attendre une bonne minute, dans le pire, pour toujours... Pour régler cette merde il suffit d'installer la librairie systemd qui gère se comportement et de redémarrer la machine.

apt install libpam-systemd
reboot

Tunnel SSH

Faire un tunnel SSH :

ssh -L 5232:localhost:5232 root@192.168.180.32

• -L : Rediriger un flux TCP ou un socket UNIX sur le client local
• Format : <port local que l'on utilisera sur notre machine>:<adresse de l'hôte distant>:<port du service distant>

Ceci mérite une explication pour être clair. Parfois, on installe un programme (Radicale pour mon exemple) qui écoute exclusivement sur son localhost (127.0.0.1) via le port 5232. Quand le serveur n'a pas d'interface graphique (ce qui est normalement le cas si on est pas Windobien), on a pas de navigateur internet. Il peut être utile d'accéder quand même à l'interface d'admin du service (en fait on en a absolument besoin). Il faut donc rediriger le trafic du localhost de l'hôte distant sur notre machine pour l'administration. On prend donc le trafic localhost:5232 du serveur et on le balance sur le localhost:5232 de notre PC local d'admin.