« Openssh » : différence entre les versions
(Aération du code + ajout relai SSH) |
(Ajout de deux précision concernant les clés publiques + emplacement des balises "syntaxhighlight inline" par "code" pour optimisation + remplacement d'un lien mort + corrections typographiques + correction d'une balise de coloration syntaxique) |
||
(9 versions intermédiaires par le même utilisateur non affichées) | |||
Ligne 1 : | Ligne 1 : | ||
[[Category:service_ssh]] | |||
[[Category:shell]] | [[Category:shell]] | ||
=Authentification par clef SSH= | =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. | 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== | ==Générer ses clefs== | ||
Pour générer un couple de clefs, tapez sur le client : | |||
ssh-keygen -t ed25519 | |||
ou avec plus de paramètres : | |||
ssh-keygen -a 100 -t ed25519 -f ~/.ssh/id_ed25519 | |||
Paramètres : | |||
* '''-a''' : nombre d'itérations de la [https://fr.wikipedia.org/wiki/Fonction_de_d%C3%A9rivation_de_cl%C3%A9 fonction de dérivation de clé]. Permet de rendre la clé plus résistante aux attaques par force brut. La valeur par défaut est définie à 16 | |||
* '''-t''' : type de clé. La taille d'une clé ''ed25519'' est fixée dans le code d{{'}}''OpenSSH''. Le paramètre <code>-b</code> permet de la spécifier pour les autres formats | |||
* '''-f''' : fichier de destination | |||
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 UTILISATEUR@SERVEUR:/home/user/.ssh/authorized_keys | |||
ou | |||
ssh-copy-id -i ~/.ssh/id_ed25519.pub UTILISATEUR@SERVEUR | |||
''Note: le même paramètre <code>-i</code> peut être utilisé avec la commande <code>ssh</code> afin de spécifier la clé à utiliser si plusieurs sont présentes.'' | |||
{{astuce|Pour [https://www.phcomp.co.uk/Tutorials/Unix-And-Linux/ssh-check-server-fingerprint.html vérifier l'empreinte] d'une clef, il faut utiliser la [https://linux.die.net/man/1/ssh-keygen commande] <code>ssh-keygen -lf /chemin/de/la/clef</code>. Le hachis résultant est à comparer avec celui de la clef qui est présenté lors de la première connexion à un serveur (les deux doivent bien sûr être identiques). L'algorithme par défaut est le ''SHA256''. Pour modifier ce paramètre, il est possible d'utiliser le paramètre <code>-E <algo_hash></code>. Exemple : <code>ssh-keygen -lE md5 -f ~/.ssh/id_ed25519</code>.}} | |||
En cas de suppression accidentelle de la clé publique, il est possible de la régénérer (à l'identique) à partir de la clé privée | |||
ssh-keygen -yf ~/.ssh/id_ed25519 | |||
==Restreindre l'usage d'une clef== | |||
Il est possible de limiter le périmètre d'usage d'une clef ''SSH'' via quelques paramètres dans le fichier ''authorized_keys'' du client. Il est ainsi possible de permettre la connexion d'un client avec une clef spécifique seulement depuis une liste d'''IP'' tout en forçant une commande précise. Par exemple: | |||
vim ~/.ssh/authorized_keys | |||
<syntaxhighlight lang="bash"> | |||
from="192.168.1.4,192.168.1.10",command="ls -al --color /" ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIKWbjAEe0X+NFr0WjEgdJ2vKAIYwYSW6WkJvP2Zg/M4q root@toto | |||
</syntaxhighlight> | |||
Le client n'effectuera alors automatiquement la commande définie par le paramètre ''command'' avant que la connexion ne se ferme d'elle même. De plus, la clef ne sera utilisable que depuis les adresses ''IP'' listés. | |||
===Sources de la section=== | |||
* https://stackoverflow.com/questions/402615/how-to-restrict-ssh-users-to-a-predefined-set-of-commands-after-login | |||
* https://www.linuxjournal.com/article/8257 | |||
* http://man.openbsd.org/OpenBSD-current/man5/sshd_config.5#ForceCommand | |||
==Déactiver l'authentification par mot de passe== | ==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''': | Si nous voulons déactiver l'accès par mot de passe, il faut ajouter la ligne suivante au fichier '''/etc/ssh/sshd_config''' : | ||
<span style="color:#808080">[...]</span> | <span style="color:#808080">[...]</span> | ||
PasswordAuthentication no | PasswordAuthentication no | ||
Vous pouvez vous référer à la section traitant du fichier de configuration d{{'}}''OpenSSH'' [[#Fichier sshd_config|plus bas]]. | |||
=Déactiver known hosts de SSH= | =Déactiver known hosts de SSH= | ||
==Problème== | ==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 : | |||
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. | The authenticity of host '192.168.1.2 (192.168.1.2)' can't be established. | ||
Ligne 27 : | Ligne 63 : | ||
Are you sure you want to continue connecting (yes/no)? | Are you sure you want to continue connecting (yes/no)? | ||
Lorsque vous avez change l'ordinateur en gardant la même IP: | Lorsque vous avez change l'ordinateur en gardant la même ''IP'' : | ||
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ | @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ | ||
Ligne 44 : | Ligne 80 : | ||
Le problème avec cette intervention est que le script n'avance pas sans vous. | 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 | 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 se termine pas... c'est pas cool. | ||
==Résolution== | ==Résolution== | ||
Voici une solution que j'ai trouvé : il faut passer des paramètres à 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 [https://fr.wikipedia.org/wiki/Attaque_de_l'homme_du_milieu de l'homme du milieu].}} | |||
=Séquences d'échappement= | =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 < | 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 <code>kill</code>. 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. | 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 ?). | 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== | ==Liste== | ||
Voici la liste exhaustive de ces merveilles (à précéder par la touche < | Voici la liste exhaustive de ces merveilles (à précéder par la touche <code><Entrer></code>) : | ||
* '''~.''' : Termine la connexion (et toute les sessions multiplexées) | * '''~.''' : Termine la connexion (et toute les sessions multiplexées) | ||
* '''~B''' : Envoi un ''BREAK'' au système distant | * '''~B''' : Envoi un ''BREAK'' au système distant | ||
* '''~C''' : Ouvre un prompt ''ssh'' (la commande < | * '''~C''' : Ouvre un prompt ''ssh'' (la commande <code>?</code> permet de lister ce que l'on peut y faire) | ||
* '''~R''' : Renégocie la clé de session (SSH version 2 uniquement) | * '''~R''' : Renégocie la clé de session (SSH version 2 uniquement) | ||
* '''~V/v''' : Augmente/diminue le degré de verbosity (LogLevel) | * '''~V/v''' : Augmente/diminue le degré de verbosity (LogLevel) | ||
* '''~^Z''' : Met SSH en pause | * '''~^Z''' : Met ''SSH'' en pause | ||
* '''~#''' : Liste toute les connexions redirigées | * '''~#''' : 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 ?!) | * '''~&''' : 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 | * '''~?''' : É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. | * '''~~''' : 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. | ||
{{info|Ceci ne fonctionne que lorsque le | {{info|Ceci ne fonctionne que lorsque le ''shell'' ne nous donne pas la main. Vous pouvez tester sur une page de <code>man</code> pour tester par exemple.}} | ||
==Sources de la section== | ==Sources de la section== | ||
Ligne 80 : | Ligne 116 : | ||
=Absence de broken pipe après un redémarrage= | =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 | 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 | apt install libpam-systemd | ||
reboot | reboot | ||
=Tunnel SSH= | =Tunnel SSH= | ||
Faire un tunnel SSH : | Faire un tunnel ''SSH'' : | ||
ssh -L 5232:localhost:5232 root@192.168.180.32 | 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>'' | Paramètres : | ||
Ceci mérite une explication pour être clair. Parfois, on installe un programme ([http://radicale.org 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. | * '''-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 ([http://radicale.org 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. | |||
=Relai SSH= | =Relai SSH= | ||
Dans le cas d'une machine accessible seulement depuis une autre (cas d'un PC derrière un routeur NAT par exemple) embarquant un serveur SSH, il est possible de l'utiliser comme ''Proxy SSH'' afin de joindre celle-ci. Ceci m'est utile pour administrer des machines virtuelles opérants dans un VLAN NATté par l'hyperviseur avec ma [[#Authentification_par_clef_SSH|clé SSH]]. Pour ce faire, depuis le client: | Dans le cas d'une machine accessible seulement depuis une autre (cas d'un PC derrière un routeur ''NAT'' par exemple) embarquant un serveur ''SSH'', il est possible de l'utiliser comme ''Proxy SSH'' afin de joindre celle-ci. Ceci m'est utile pour administrer des machines virtuelles opérants dans un ''VLAN NATté'' par l'hyperviseur avec ma [[#Authentification_par_clef_SSH|clé SSH]]. Pour ce faire, depuis le client: | ||
ssh -J titi@relai toto@destination | ssh -J titi@relai toto@destination | ||
==Source de la section== | ==Source de la section== | ||
* https://tuxicoman.jesuislibre.net/2017/02/connexion-ssh-a-travers-un-ordinateur-relai-avec-proxyjump.html | * https://tuxicoman.jesuislibre.net/2017/02/connexion-ssh-a-travers-un-ordinateur-relai-avec-proxyjump.html | ||
=SSH inversé= | |||
Il est possible de se connecter au client ayant initié une session ''SSH'' via la création d'un socket spécifique. Cette technique se nomme le ''reverse SSH''. Cela peut-être utile dans le cas d'un dépannage ou pour transférer des fichiers à une machine ne disposant pas d'un accès publique à Internet (cas d'un ''NAT'' par exemple). Cette méthode permet alors la prise en main d'un client sans redirection de port au niveau de son accès ''WAN''. | |||
Depuis le client vers le dépanneur : | |||
ssh -NR 12345:localhost:22 utilisateur-dépanneur@ip-dépanneur | |||
Paramètres : | |||
* '''-N''' : n'exécute ni aucune commande ni aucun shell. Cela permet de n'utiliser la session ''SSH'' que pour ouvrir un socket distant et non pour administrer la destination. Dans notre cas, la session sert juste à créer le socket sur lequel nous allons nous connecter | |||
* '''-R''' : redirige le socket local vers le socket distant. C'est ce paramètre qui permettra au dépanneur de se connecter au client via un socket local créé pour l'occasion | |||
* '''12345:localhost:22''' : socket-sur-dépanneur:adresse-d'écoute-du-socket:socket-à-rediriger-vers-12345 | |||
Depuis le dépanneur vers le client en passant par le socket redirigé : | |||
ssh -p 12345 utilisateur-client@localhost | |||
Il est aussi possible d'y transférer des fichiers : | |||
scp -P 12345 /chemin/fichier/dépanneur utilisateur-client@localhost:/destination/fichier/pour/le/client | |||
==Source de la section== | |||
* https://doc.ubuntu-fr.org/tutoriel/reverse_ssh#connexion_directe | |||
=Agent SSH= | |||
Le serveur ''OpenSSH'' embarque un agent capable d'enregistrer le mot de passe de vos clés ''SSH''. Vous pouvez donc initier des connexion sans avoir à renseigner cette information à chaque fois. | |||
Initialiser l'agent pour le [[Shell bash|shell]] courant | |||
eval "$(ssh-agent -s)" | |||
Enregistrer le mot de passe de votre clé | |||
ssh-add /root/.ssh/id_ed25519 | |||
{{Info|Utilisée sans argument, la commande <code>ssh-add</code> va chercher les clés dans le répertoire personnel de votre utilisateur local courant.}} | |||
==Sources de la section== | |||
* https://rabexc.org/posts/using-ssh-agent | |||
* https://mytrashcode.com/open-connection-authentication-agent | |||
=Fichier sshd_config= | |||
Voici quelques paramètres qu'il peut être utile d'appliquer sur un serveur ''SSH'' (<code>/etc/ssh/sshd_config</code>) : | |||
==Généralités== | |||
PermitRootLogin no | |||
PasswordAuthentication no | |||
AllowUsers toto sauvegardes | |||
ClientAliveInterval 1800 | |||
UseDNS no | |||
Description des paramètres : | |||
* '''PermitRootLogin''' ''{no|yes|prohibit-password}'' : définit si l'utilisateur ''root'' peut se connecter. La directive '''prohibit-password''' permet de n'autoriser que l'utilisation de [[#Authentification par clef SSH|clés SSH]] avec ce dernier | |||
* '''PasswordAuthentication''' ''{no|yes}'' : définit si la connexion par mot de passe est autorisé pour tous les utilisateurs (''root'' à part) ou si seulement les clés SSH sont permises | |||
* '''AllowUsers''' : liste blanche des utilisateurs autorisés à ce connecter | |||
* '''ClientAliveInterval''' : si le paramètre est définit, ''OpenSSH'' compte le temps (en secondes) depuis le dernier paquet reçu du client et envoi une demande de réponse à celui-ci. Couplé au paramètre '''ClientAliveCountMax''' (valeur par défaut à ''3''), le serveur fermera automatiquement la session en cas de non réponse prolongée de ce dernier (nombre de fois compté depuis la dernière réponse). Ceci n'est utile que si la connexion entre les deux paires est interrompu (plus de réseau) | |||
* '''UseDNS''' ''{no|yes}'' : définit si ''OpenSSH'' doit résoudre les noms de domaine. Ce paramètre, non content d'être inutile, ralenti CONSIDÉRABLEMENT l'établissement de la connexion dans le cas ou le serveur ''DNS'' est injoignable (fréquent dans des ''LAB'' de tests) | |||
==Chiffrement== | |||
N'utiliser que des [https://cipherlist.eu/ chiffrements sérieux] : | |||
KexAlgorithms curve25519-sha256@libssh.org,diffie-hellman-group-exchange-sha256 | |||
Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com,aes256-ctr | |||
MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-512,hmac-sha2-256,umac-128@openssh.com | |||
Je vous conseil également d'utiliser que des clés ''RSA'' et ''ed25519'' en commentant les lignes <code>HostKey /etc/ssh/ssh_host_dsa_key</code> et <code>HostKey /etc/ssh/ssh_host_ecdsa_key</code>. | |||
Vérifiez également que la version de ''SSH'' utilisée est la 2 via le paramètre <code>Protocol 2</code>. | |||
N'oubliez pas de recharger le service : | |||
systemctl reload ssh | |||
=Fichier ssh_config= | |||
Le client ''SSH'' peut aussi être configuré par utilisateur du système. Il sera alors possible de définir des paramètres personnalisés en fonction de celui se connectant à une machine. Le fichier est à créer dans le répertoire personnel de chaque utilisateur le nécessitant (<code>~/.ssh/config</code>). | |||
Pour utiliser une clé spécifique pour la connexion à une machine : | |||
<syntaxhighlight lang="bash"> | |||
Host nomMachine | |||
Hostname fc00:0:0:1::2 | |||
User root | |||
Port 22 | |||
IdentityFile ~/.ssh/id_ed25519-sauv | |||
IdentitiesOnly yes | |||
IgnoreUnknown UseKeychain,AddKeysToAgent | |||
AddKeysToAgent yes | |||
</syntaxhighlight> | |||
Description des paramètres : | |||
* '''Host nomMachine''' : Ouvre une section concernant un hôte en particulier. La valeur ''nomMachine'' vient créer un nom d'hôte utilisable par ''OpenSSH'' au même titre que si l'on avait rentré une ligne dans le fichier ''hosts'' | |||
* '''Hostname''' : adresse de la machine distante | |||
* '''User''' : utilisateur de la machine distante | |||
* '''Port''' : port ''SSH'' de la machine distante | |||
* '''IdentityFile''' : clé ''SSH'' à utiliser (par défaut, seul les noms de clés par défaut sont recherchés) | |||
* '''IdentitiesOnly''' : n'utilise que la clé spécifiée dans le paramètre précédent. Si omis, le client ''SSH'' va tester une connexion distante avec toute les clés qu'il trouvera (occasionnant autant d'échec de connexion sur la machine distante) | |||
* '''IgnoreUnknown''' : permet d'ignorer les paramètres inexistants. Les deux valeurs sont des paramètres faisant la même chose mais sur deux systèmes différents. La première est pour MacOSX et la deuxième pour Linux. Cela permet de faire des copier/coller de configuration sans réfléchir | |||
* '''AddKeysToAgent''' : si la clé ''SSH'' utilisée contient une phrase de passe, elle ne sera demandée que la première fois et stockée dans l'agent ''SSH'' | |||
==Sources de la section== | |||
* https://www.man7.org/linux/man-pages/man5/ssh_config.5.html | |||
* https://computingforgeeks.com/managing-ssh-connections-on-linux-unix-using-ssh-config-file/ |
Dernière version du 26 août 2024 à 18:01
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
ou avec plus de paramètres :
ssh-keygen -a 100 -t ed25519 -f ~/.ssh/id_ed25519
Paramètres :
- -a : nombre d'itérations de la fonction de dérivation de clé. Permet de rendre la clé plus résistante aux attaques par force brut. La valeur par défaut est définie à 16
- -t : type de clé. La taille d'une clé ed25519 est fixée dans le code d'OpenSSH. Le paramètre
-b
permet de la spécifier pour les autres formats - -f : fichier de destination
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 UTILISATEUR@SERVEUR:/home/user/.ssh/authorized_keys
ou
ssh-copy-id -i ~/.ssh/id_ed25519.pub UTILISATEUR@SERVEUR
Note: le même paramètre -i
peut être utilisé avec la commande ssh
afin de spécifier la clé à utiliser si plusieurs sont présentes.
ASTUCE
Pour vérifier l'empreinte d'une clef, il faut utiliser la commandessh-keygen -lf /chemin/de/la/clef
. Le hachis résultant est à comparer avec celui de la clef qui est présenté lors de la première connexion à un serveur (les deux doivent bien sûr être identiques). L'algorithme par défaut est le SHA256. Pour modifier ce paramètre, il est possible d'utiliser le paramètre -E <algo_hash>
. Exemple : ssh-keygen -lE md5 -f ~/.ssh/id_ed25519
.En cas de suppression accidentelle de la clé publique, il est possible de la régénérer (à l'identique) à partir de la clé privée
ssh-keygen -yf ~/.ssh/id_ed25519
Restreindre l'usage d'une clef
Il est possible de limiter le périmètre d'usage d'une clef SSH via quelques paramètres dans le fichier authorized_keys du client. Il est ainsi possible de permettre la connexion d'un client avec une clef spécifique seulement depuis une liste d'IP tout en forçant une commande précise. Par exemple:
vim ~/.ssh/authorized_keys
from="192.168.1.4,192.168.1.10",command="ls -al --color /" ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIKWbjAEe0X+NFr0WjEgdJ2vKAIYwYSW6WkJvP2Zg/M4q root@toto
Le client n'effectuera alors automatiquement la commande définie par le paramètre command avant que la connexion ne se ferme d'elle même. De plus, la clef ne sera utilisable que depuis les adresses IP listés.
Sources de la section
- https://stackoverflow.com/questions/402615/how-to-restrict-ssh-users-to-a-predefined-set-of-commands-after-login
- https://www.linuxjournal.com/article/8257
- http://man.openbsd.org/OpenBSD-current/man5/sshd_config.5#ForceCommand
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
Vous pouvez vous référer à la section traitant du fichier de configuration d'OpenSSH plus bas.
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 se termine pas... c'est pas cool.
Résolution
Voici une solution que j'ai trouvé : il faut passer des paramètres à 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 de l'homme du milieu.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 deman
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
Paramètres :
- -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.
Relai SSH
Dans le cas d'une machine accessible seulement depuis une autre (cas d'un PC derrière un routeur NAT par exemple) embarquant un serveur SSH, il est possible de l'utiliser comme Proxy SSH afin de joindre celle-ci. Ceci m'est utile pour administrer des machines virtuelles opérants dans un VLAN NATté par l'hyperviseur avec ma clé SSH. Pour ce faire, depuis le client:
ssh -J titi@relai toto@destination
Source de la section
SSH inversé
Il est possible de se connecter au client ayant initié une session SSH via la création d'un socket spécifique. Cette technique se nomme le reverse SSH. Cela peut-être utile dans le cas d'un dépannage ou pour transférer des fichiers à une machine ne disposant pas d'un accès publique à Internet (cas d'un NAT par exemple). Cette méthode permet alors la prise en main d'un client sans redirection de port au niveau de son accès WAN.
Depuis le client vers le dépanneur :
ssh -NR 12345:localhost:22 utilisateur-dépanneur@ip-dépanneur
Paramètres :
- -N : n'exécute ni aucune commande ni aucun shell. Cela permet de n'utiliser la session SSH que pour ouvrir un socket distant et non pour administrer la destination. Dans notre cas, la session sert juste à créer le socket sur lequel nous allons nous connecter
- -R : redirige le socket local vers le socket distant. C'est ce paramètre qui permettra au dépanneur de se connecter au client via un socket local créé pour l'occasion
- 12345:localhost:22 : socket-sur-dépanneur:adresse-d'écoute-du-socket:socket-à-rediriger-vers-12345
Depuis le dépanneur vers le client en passant par le socket redirigé :
ssh -p 12345 utilisateur-client@localhost
Il est aussi possible d'y transférer des fichiers :
scp -P 12345 /chemin/fichier/dépanneur utilisateur-client@localhost:/destination/fichier/pour/le/client
Source de la section
Agent SSH
Le serveur OpenSSH embarque un agent capable d'enregistrer le mot de passe de vos clés SSH. Vous pouvez donc initier des connexion sans avoir à renseigner cette information à chaque fois.
Initialiser l'agent pour le shell courant
eval "$(ssh-agent -s)"
Enregistrer le mot de passe de votre clé
ssh-add /root/.ssh/id_ed25519
INFORMATION
Utilisée sans argument, la commandessh-add
va chercher les clés dans le répertoire personnel de votre utilisateur local courant.Sources de la section
- https://rabexc.org/posts/using-ssh-agent
- https://mytrashcode.com/open-connection-authentication-agent
Fichier sshd_config
Voici quelques paramètres qu'il peut être utile d'appliquer sur un serveur SSH (/etc/ssh/sshd_config
) :
Généralités
PermitRootLogin no PasswordAuthentication no AllowUsers toto sauvegardes ClientAliveInterval 1800 UseDNS no
Description des paramètres :
- PermitRootLogin {no|yes|prohibit-password} : définit si l'utilisateur root peut se connecter. La directive prohibit-password permet de n'autoriser que l'utilisation de clés SSH avec ce dernier
- PasswordAuthentication {no|yes} : définit si la connexion par mot de passe est autorisé pour tous les utilisateurs (root à part) ou si seulement les clés SSH sont permises
- AllowUsers : liste blanche des utilisateurs autorisés à ce connecter
- ClientAliveInterval : si le paramètre est définit, OpenSSH compte le temps (en secondes) depuis le dernier paquet reçu du client et envoi une demande de réponse à celui-ci. Couplé au paramètre ClientAliveCountMax (valeur par défaut à 3), le serveur fermera automatiquement la session en cas de non réponse prolongée de ce dernier (nombre de fois compté depuis la dernière réponse). Ceci n'est utile que si la connexion entre les deux paires est interrompu (plus de réseau)
- UseDNS {no|yes} : définit si OpenSSH doit résoudre les noms de domaine. Ce paramètre, non content d'être inutile, ralenti CONSIDÉRABLEMENT l'établissement de la connexion dans le cas ou le serveur DNS est injoignable (fréquent dans des LAB de tests)
Chiffrement
N'utiliser que des chiffrements sérieux :
KexAlgorithms curve25519-sha256@libssh.org,diffie-hellman-group-exchange-sha256 Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com,aes256-ctr MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-512,hmac-sha2-256,umac-128@openssh.com
Je vous conseil également d'utiliser que des clés RSA et ed25519 en commentant les lignes HostKey /etc/ssh/ssh_host_dsa_key
et HostKey /etc/ssh/ssh_host_ecdsa_key
.
Vérifiez également que la version de SSH utilisée est la 2 via le paramètre Protocol 2
.
N'oubliez pas de recharger le service :
systemctl reload ssh
Fichier ssh_config
Le client SSH peut aussi être configuré par utilisateur du système. Il sera alors possible de définir des paramètres personnalisés en fonction de celui se connectant à une machine. Le fichier est à créer dans le répertoire personnel de chaque utilisateur le nécessitant (~/.ssh/config
).
Pour utiliser une clé spécifique pour la connexion à une machine :
Host nomMachine
Hostname fc00:0:0:1::2
User root
Port 22
IdentityFile ~/.ssh/id_ed25519-sauv
IdentitiesOnly yes
IgnoreUnknown UseKeychain,AddKeysToAgent
AddKeysToAgent yes
Description des paramètres :
- Host nomMachine : Ouvre une section concernant un hôte en particulier. La valeur nomMachine vient créer un nom d'hôte utilisable par OpenSSH au même titre que si l'on avait rentré une ligne dans le fichier hosts
- Hostname : adresse de la machine distante
- User : utilisateur de la machine distante
- Port : port SSH de la machine distante
- IdentityFile : clé SSH à utiliser (par défaut, seul les noms de clés par défaut sont recherchés)
- IdentitiesOnly : n'utilise que la clé spécifiée dans le paramètre précédent. Si omis, le client SSH va tester une connexion distante avec toute les clés qu'il trouvera (occasionnant autant d'échec de connexion sur la machine distante)
- IgnoreUnknown : permet d'ignorer les paramètres inexistants. Les deux valeurs sont des paramètres faisant la même chose mais sur deux systèmes différents. La première est pour MacOSX et la deuxième pour Linux. Cela permet de faire des copier/coller de configuration sans réfléchir
- AddKeysToAgent : si la clé SSH utilisée contient une phrase de passe, elle ne sera demandée que la première fois et stockée dans l'agent SSH