OpenSSH (Français)
Related articles
- SSH keys
- Pam abl
- fail2ban
- sshguard
- SSHFS (Français)
- Syslog-ng
- SFTP chroot
- SCP and SFTP
- VPN over SSH OpenSSH (OpenBSD Secure Shell) est un ensemble de programmes informatiques fournissant des sessions de communication chiffrées sur un réseau informatique en utilisant le protocole Secure Shell (SSH). Il a été créé comme alternative open source à la suite logicielle propriétaire Secure Shell offerte par SSH Communications Security. OpenSSH est développé dans le cadre du projet OpenBSD, qui est dirigé par Theo de Raadt. OpenSSH est parfois confondu avec OpenSSL, qui porte un nom proche ; cependant, les projets ont des objectifs différents et sont développés par des équipes différentes, la similitude du nom est uniquement due à des objectifs similaires.
- Pour vous aider à sélectionner un autre port qui n'est pas déjà attribué à un service commun, consultez la liste des numéros de port TCP et UDP. Vous pouvez également trouver des informations sur les ports en local dans
/etc/services
. Un changement de port par rapport au port 22 par défaut réduira le nombre d'entrées de journal causées par les tentatives d'authentification automatique mais ne les éliminera pas. Consultez Port knocking pour des informations connexes. - Il est recommandé de désactiver entièrement les connexions par mot de passe. Cela augmentera considérablement la sécurité, consultez #Forcer l'authentification par clé publique pour plus d'informations. Consultez #Protection pour plus de méthodes de sécurité recommandées.
- OpenSSH peut écouter plusieurs ports simplement en ayant plusieurs
Port numéro_port
lignes dans le fichier de configuration. - Les paires de clés d'hôte nouvelles (ou manquantes) peuvent être générées en supprimant la ou les paires que vous voulez remplacer de
/etc/ssh
et en exécutantssh-keygen -A
en tant que root. - N'autorisez les connexions SSH entrantes qu'à partir d'emplacements de confiance.
- Utilisez fail2ban ou sshguard pour bloquer automatiquement les adresses IP qui échouent trop souvent à l'authentification par mot de passe.
- Utilisez pam_shield pour bloquer les adresses IP qui effectuent trop de tentatives de connexion pendant une certaine période. Contrairement à fail2ban ou sshguard, ce programme ne prend pas en compte le succès ou l'échec de la connexion.
- Pour Firefox : Dans Préférences > Général, naviguez jusqu'au bas de la page et cliquez sur Paramètres..., qui se trouve à droite du titre Paramètres réseau. Ensuite, dans la nouvelle semi-fenêtre, cochez l'option Configuration manuelle du proxy et entrez dans le champ de texte Hôte SOCKS, et le numéro de port dans le champ de texte Port ( dans l'exemple ci-dessus) à côté.
- Firefox n'effectue pas automatiquement les requêtes DNS via le tunnel SOCKS. Ce problème potentiel de confidentialité peut être atténué en faisant défiler la page plus bas et en cochant la case Proxy DNS when using SOCKS v5. Évidemment, cela ne fonctionnera que si vous choisissez SOCKS v5 plutôt que v4.
- Redémarrez Firefox pour activer ces paramètres.
- Pour Chromium : Vous pouvez définir les paramètres SOCKS comme variables d'environnement ou comme options de ligne de commande. Je recommande d'ajouter l'une des fonctions suivantes à votre :
- installez les paquets
- dans :
- définissez
X11Forwarding
à yes. - vérifiez que les options et ont pour valeur yes, et que a pour valeur 10 (ce sont les valeurs par défaut si rien n'a été changé, consultez )
- définissez
- puis redémarrez le daemon sshd.
- activer l'option
AddressFamily any
dans sur le serveur, soit - Définir l'option de sur le serveur à inet.
- Use a faster cipher : sur les CPUs modernes avec les instructions AESNI, et devraient offrir de meilleures performances que le chiffrement préféré par défaut d'openssh, habituellement
chacha20-poly1305@openssh.com
. Le chiffrement peut être sélectionné par l'option . Pour un effet permanent, mettez l'option dans votre avec les ciphers dans le nouvel ordre préféré, par exemple : - Activer ou désactiver la compression : la compression peut augmenter la vitesse sur les connexions lentes, elle est activée avec l'option ou le paramètre . Cependant, l'algorithme de compression utilisé est le relativement lent gzip(1) qui devient le goulot d'étranglement sur les réseaux rapides. Afin d'accélérer la connexion, il faut utiliser l'option sur les réseaux locaux ou rapides.
- Partage de connexion : vous pouvez faire en sorte que toutes les sessions sur le même hôte partagent une seule connexion en utilisant ces options :
- où peut être n'importe quel répertoire non accessible en écriture par d'autres utilisateurs.
ControlPersist
spécifie combien de temps le maître doit attendre en arrière-plan de nouveaux clients après la fermeture de la connexion client initiale. Les valeurs possibles sont soit :- pour fermer la connexion immédiatement après la déconnexion du dernier client,
- un temps en secondes,
- pour attendre éternellement, la connexion ne sera jamais fermée automatiquement.
- Le temps de connexion peut être raccourci en contournant la recherche IPv6 à l'aide de l'option ou de l'option .
- Enfin, si vous avez l'intention d'utiliser SSH pour SFTP ou SCP, High Performance SSH/SCP peut augmenter considérablement le débit en augmentant dynamiquement la taille des tampons SSH. Installez le paquet pour utiliser une version corrigée d'OpenSSH avec cette amélioration.
- Du côté du serveur, définit le délai en secondes après lequel, si aucune donnée n'a été reçue du client, sshd enverra une demande de réponse. La valeur par défaut est 0, aucun message n'est envoyé. Par exemple, pour demander une réponse toutes les 60 secondes au client, définissez l'option dans votre configuration du serveur. Consultez également les options et .
- Du côté client,
ServerAliveInterval
contrôle l'intervalle entre les demandes de réponse envoyées par le client au serveur. Par exemple, pour demander une réponse toutes les 120 secondes au serveur, ajoutez l'option à votre client. Consultez également les options et . - utiliser le fichier sur l'hôte distant (consultez dans )
- utiliser sur l'hôte distant si le serveur a activé l'option .
- Utilisez votre fichier de configuration du shell sur l'hôte distant, par exemple .
- Supprimez toutes les clés, par ex :
- Redémarrez
sshdgenkeys.service
ou exécuter en tant que root. - Le répertoire de configuration , son contenu ne doit être accessible que par l'utilisateur (vérifiez-le sur le client et le serveur), et le répertoire personnel de l'utilisateur ne doit être accessible en écriture que par l'utilisateur :
- Vérifiez que la clé publique du client (par exemple,
id_rsa.pub
) se trouve dans~/.ssh/authorized_keys
sur le serveur. - Vérifiez que vous n'avez pas limité l'accès SSH avec ou dans la configuration du serveur.
- Vérifiez si l'utilisateur a défini un mot de passe. Parfois, les nouveaux utilisateurs qui ne se sont pas encore connectés au serveur n'ont pas de mot de passe.
- Ajoutez à .
- Exécutez en tant que root pour les éventuels messages (d'erreur).
- Redémarrez et déconnexion/login sur le client et le serveur.
- Se défendre contre les attaques ssh par force brute
- Gestion des clés OpenSSH : Partie 1 sur IBM developerWorks, Partie 2, Partie 3 sur funtoo.org
- Sécuriser Secure Shell
Installation
Installez le paquet .
Utilisation du client
Pour se connecter à un serveur, exécutez :
$ ssh -p port utilisateur @ adresse du serveur.Si le serveur n'autorise que l'authentification par clé publique, suivez SSH keys.
Configuration
Le client peut être configuré pour stocker les options et les hôtes courants. Toutes les options peuvent être déclarées globalement ou restreintes à des hôtes spécifiques. Par exemple :
Avec une telle configuration, les commandes suivantes sont équivalentes
$ ssh -p port user@server-address' (utilisateur) $ ssh myserverConsultez pour plus d'informations.
Certaines options n'ont pas d'équivalent en ligne de commande, mais vous pouvez spécifier des options de configuration sur la ligne de commande avec -o
. Par exemple -oKexAlgorithmes=+diffie-hellman-group1-sha1
.
Utilisation du serveur
est le daemon du serveur OpenSSH, configuré avec et géré par . Chaque fois que vous modifiez la configuration, utilisez en mode test avant de redémarrer le service pour vous assurer qu'il pourra démarrer proprement. Les configurations valides ne produisent aucune sortie. # sshd -tConfiguration
Pour autoriser l'accès uniquement à certains utilisateurs, ajoutez cette ligne :
AllowUsers user1 user2Pour autoriser l'accès uniquement à certains groupes :
AllowGroups group1 group2Pour ajouter un beau message de bienvenue (par exemple à partir du fichier ), configurez l'option :
Banner /etc/issueLes clés d'hôte publiques et privées sont automatiquement générées dans par le service sshdgenkeys et régénérées si elles sont manquantes, même si l'option de n'en autorise que quelques-unes. Quatre paires de clés sont fournies, basées sur les algorithmes dsa, rsa, ecdsa et ed25519. Pour que sshd utilise une clé particulière, spécifiez l'option suivante :
HostKey /etc/ssh/ssh_host_rsa_keySi le serveur doit être exposé au WAN, il est recommandé de changer le port par défaut de 22 à un port supérieur aléatoire comme ceci :
Port 39901Gestion des daemons
Démarrez et activez . Il maintiendra le daemon SSH actif en permanence et forkera pour chaque connexion entrante.
sshd.socket
qui utilisait l'activation de socket de systemd en raison de sa sensibilité au déni de service. Consultez FS#62248 pour plus de détails. Si sshd.socket
est activé lors de la mise à jour vers openssh 8.0p1-3, les unités sshd.socket
et sshd@.service
seront copiées dans /etc/systemd/system/
et réactivés. Ceci est fait uniquement pour ne pas casser les configurations existantes, il est toujours conseillé aux utilisateurs de migrer vers sshd.service
.Protection
Autoriser la connexion à distance via SSH est une bonne chose à des fins administratives, mais peut constituer une menace pour la sécurité de votre serveur. Souvent la cible d'attaques par force brute, l'accès SSH doit être limité correctement pour empêcher des tiers d'accéder à votre serveur.
offre une analyse automatisée de la configuration du serveur et du client. Plusieurs autres bons guides et outils sont disponibles sur le sujet, par exemple :Forcer l'authentification par clé publique
Si un client ne peut pas s'authentifier au moyen d'une clé publique, le serveur SSH revient par défaut à l'authentification par mot de passe, ce qui permet à un utilisateur malveillant de tenter d'obtenir un accès en force brute par mot de passe. L'un des moyens les plus efficaces de se protéger contre cette attaque est de désactiver complètement les connexions par mot de passe et de forcer l'utilisation de clés SSH. Ceci peut être réalisé en définissant les options suivantes dans le fichier de configuration du daemon :
Authentification à deux facteurs et clés publiques
SSH peut être configuré pour nécessiter plusieurs méthodes d'authentification. Vous pouvez indiquer les méthodes d'authentification requises à l'aide de l'option . Cela vous permet d'utiliser des clés publiques ainsi qu'une autorisation à deux facteurs.
Fournisseurs d'authentification
Consultez Google Authenticator pour configurer Google Authenticator.
Pour Duo, installez qui fournira le module pam_duo.so
. Lisez la documentation Duo Unix pour savoir comment configurer les informations d'identification Duo nécessaires (clé d'intégration, clé secrète, nom d'hôte API).
Configuration de PAM
Pour utiliser PAM avec OpenSSH, éditez les fichiers suivants :
Vous pouvez alors vous connecter avec une clé publique ou l'authentification de l'utilisateur comme requis par votre configuration PAM.
Si, par contre, vous voulez authentifier l'utilisateur à la fois avec une clé publique et l'authentification utilisateur requise par votre configuration PAM, utilisez une virgule au lieu d'un espace pour séparer les AuthenticationMethods :
Si l'authentification par pubkey et pam est requise, vous pouvez désactiver le mot de passe :
/etc/pam.d/sshd
auth required pam_securetty.so #disable remote root #Require google authenticator auth required pam_google_authenticator.so #But not password #auth include system-remote-login account include system-remote-login password include system-remote-login session include system-remote-login
Protection contre les attaques par force brute
Le forçage brutal est un concept simple : on essaie continuellement de se connecter à une page Web ou à une invite de connexion à un serveur comme SSH avec un grand nombre de combinaisons aléatoires de nom d'utilisateur et de mot de passe.
Consultez ufw#Rate limiting with ufw ou Simple stateful firewall#Bruteforce attacks pour iptables.
Vous pouvez également vous protéger contre les attaques par force brute en utilisant un script automatisé qui bloque toute personne essayant d'entrer par force brute, par exemple fail2ban ou sshguard.
Limiter la connexion root
Il est généralement considéré comme une mauvaise pratique de permettre à l'utilisateur root de se connecter sans contrainte via SSH. Il existe deux méthodes permettant de restreindre l'accès root SSH pour une sécurité accrue.
Refuser
Sudo fournit de manière sélective les droits root pour les actions qui le nécessitent sans avoir à s'authentifier auprès du compte root. Cela permet de verrouiller le compte root contre l'accès via SSH et fonctionne potentiellement comme une mesure de sécurité contre les attaques par force brute, puisque maintenant un attaquant doit deviner le nom du compte en plus du mot de passe.
SSH peut être configuré pour refuser les connexions à distance avec l'utilisateur root en modifiant la section "Authentification" du fichier de configuration du daemon. Définissez simplement à :
Ensuite, redémarrez le daemon SSH.
Vous ne pourrez plus vous connecter par SSH sous root, mais vous pourrez toujours vous connecter avec votre utilisateur normal et utiliser su ou sudo pour administrer le système.
Restreindre
Certaines tâches automatisées, telles que la sauvegarde complète du système à distance, nécessitent un accès complet à root. Pour les autoriser de manière sécurisée, au lieu de désactiver la connexion root via SSH, il est possible de n'autoriser la connexion root que pour certaines commandes. Ceci peut être réalisé en éditant , en préfixant la clé désirée, par exemple comme suit :
command="/usr/lib/rsync/rrsync -ro /" ssh-rsa ...Cela permettra à toute connexion avec cette clé spécifique d'exécuter la commande spécifiée entre les guillemets.
L'augmentation de la surface d'attaque créée par l'exposition du nom d'utilisateur root à la connexion peut être compensée en ajoutant ce qui suit à :
PermitRootLogin forced-commands-onlyCe paramètre ne limitera pas seulement les commandes que root peut exécuter via SSH, mais il désactivera également l'utilisation de mots de passe, forçant l'utilisation de l'authentification par clé publique pour le compte root.
Une alternative un peu moins restrictive autorise n'importe quelle commande pour root, mais rend les attaques par force brute infaisables en imposant l'authentification par clé publique. Pour cette option, définissez :
PermitRootLogin prohibit-passwordVerrouillage du fichier authorized_keys
Si, pour une raison quelconque, vous pensez que l'utilisateur en question ne devrait pas pouvoir ajouter ou modifier des clés existantes, vous pouvez l'empêcher de manipuler le fichier.
Sur le serveur, mettez le fichier en lecture seule pour l'utilisateur et refusez toutes les autres autorisations :
$ chmod 400 ~/.ssh/authorized_keysPour empêcher l'utilisateur de simplement rétablir les autorisations, définissez le bit immuable sur le fichier . Pour empêcher l'utilisateur de renommer le répertoire et de créer un nouveau répertoire et un nouveau fichier , définissez également le bit immuable sur le répertoire . Pour ajouter ou supprimer des clés, vous devrez supprimer le bit immuable de et le rendre temporairement accessible en écriture.
authorized_keys
via, par exemple, auditd.Trucs et astuces
Tunnel SOCKS chiffré
Ceci est très utile pour les utilisateurs d'ordinateurs portables connectés à diverses connexions sans fil non sécurisées. La seule chose dont vous avez besoin est un serveur SSH fonctionnant dans un endroit quelque peu sécurisé, comme votre domicile ou votre lieu de travail. Il peut être utile d'utiliser un service DNS dynamique comme DynDNS pour ne pas avoir à se souvenir de votre adresse IP.
Étape 1 : démarrer la connexion
Vous n'avez qu'à exécuter cette seule commande pour démarrer la connexion :
$ ssh -TND 4711 user@hostoù est votre nom d'utilisateur sur le serveur SSH fonctionnant sur . Il vous demandera votre mot de passe, et vous serez alors connecté. L'option désactive l'invite interactive, et l'option spécifie le port local sur lequel écouter (vous pouvez choisir n'importe quel numéro de port si vous le souhaitez). L'option désactive l'allocation de pseudo-tty.
Il est intéressant d'ajouter l'option verbose (-v
), car vous pouvez alors vérifier que le système est réellement connecté à partir de cette sortie.
Étape 2 (Variante A) : configurez votre navigateur (ou d'autres programmes)
L'étape ci-dessus n'est utile qu'en combinaison avec un navigateur web ou un autre programme qui utilise ce tunnel SOCKS nouvellement créé. Comme SSH prend actuellement en charge SOCKS v4 et SOCKS v5, vous pouvez utiliser l'un ou l'autre.
OU
function secure_chromium { port=4711 chromium --proxy-server="socks://localhost:$port" & exit }Maintenant, ouvrez un terminal et faites simplement :
$ secure_chromiumProfitez de votre tunnel sécurisé !
Étape 2 (Variante B) : configurer une interface TUN locale
Cette variante est un peu plus complexe au départ, mais elle vous évite de devoir configurer manuellement chaque application une par une pour utiliser le proxy SOCKS. Elle consiste à configurer une interface TUN locale et à acheminer le trafic à travers celle-ci.
Déport d'affichage X11
Le déport d'affichage avec X11 est un mécanisme qui permet aux interfaces graphiques des programmes X11 s'exécutant sur un système distant d'être affichées sur une machine cliente locale. Pour la redirection X11, l'hôte distant n'a pas besoin d'avoir un système X11 complet installé, mais il doit au moins avoir xauth installé. xauth est un utilitaire qui maintient les configurations Xauthority
utilisées par le serveur et le client pour l'authentification de la session X11 (source).
Configuration
A distance
Client
Utilisation
Connectez-vous à la machine distante normalement, en spécifiant le paramètre -X
si ForwardX11 n'a pas été activé dans le fichier de configuration du client :
Si vous recevez des erreurs en essayant d'exécuter des applications graphiques, essayez plutôt ForwardX11Trusted :
$ ssh -Y user@hostSi vous obtenez , recommencez la configuration pour votre machine distante. Une fois que la demande de transfert X11 a réussi, vous pouvez lancer n'importe quel programme X sur le serveur distant et il sera transféré à votre session locale :
$ xclock
Une erreur contenant indique que n'est pas correctement configuré.
Soyez prudent avec certaines applications car elles vérifient qu'une instance est en cours d'exécution sur la machine locale. Firefox est un exemple : fermez l'instance de Firefox en cours d'exécution ou utilisez le paramètre de démarrage suivant pour lancer une instance distante sur la machine locale :
$ firefox --no-remoteSi vous obtenez "X11 forwarding request failed on channel 0" lorsque vous vous connectez (et que le serveur affiche "Failed to allocate internet-domain X11 display socket"), vérifiez que le paquet est installé. Si son installation ne fonctionne pas, essayez soit de :
Le réglage sur inet peut résoudre les problèmes avec les clients Ubuntu sur IPv4.
Pour exécuter des applications X en tant qu'autre utilisateur sur le serveur SSH, vous devez la ligne d'authentification prise dans de l'utilisateur connecté à SSH.
Transfert d'autres ports
En plus du support intégré de SSH pour X11, il peut également être utilisé pour tunnelliser de manière sécurisée toute connexion TCP, en utilisant la redirection locale ou la redirection à distance.
Le transfert local ouvre un port sur la machine locale, dont les connexions seront transférées vers l'hôte distant et de là, vers une destination donnée. Très souvent, la destination de la redirection sera la même que l'hôte distant, fournissant ainsi un shell sécurisé et, par exemple, une connexion VNC sécurisée, à la même machine. Le transfert local est accompli au moyen du paramètre et il accompagne la spécification du transfert sous la forme .
Ainsi :
$ ssh -L 1000:mail.google.com:25 192.168.0.100utilisera SSH pour se connecter et ouvrir un shell sur , et créera également un tunnel depuis le port TCP 1000 de la machine locale vers mail.google.com sur le port 25. Une fois établi, les connexions à se connecteront au port SMTP de Gmail. Pour Google, il apparaîtra que cette connexion (mais pas nécessairement les données transmises par cette connexion) provient de , et ces données seront sécurisées entre la machine locale et 192.168.0.100, mais pas entre et Google, sauf si d'autres mesures sont prises.
De même :
$ ssh -L 2000:192.168.0.100:6001 192.168.0.100permettra les connexions à qui seront envoyées de manière transparente à l'hôte distant sur le port 6001. L'exemple précédent est utile pour les connexions VNC utilisant l'utilitaire vncserver - qui fait partie du paquet tightvnc - qui, bien que très utile, est explicite quant à son manque de sécurité.
Le transfert à distance permet à l'hôte distant de se connecter à un hôte arbitraire via le tunnel SSH et la machine locale, ce qui constitue une inversion fonctionnelle du transfert local, et est utile dans les situations où, par exemple, l'hôte distant a une connectivité limitée en raison d'un pare-feu. Il est activé avec le paramètre et une spécification de transfert sous la forme .
Ainsi :
$ ssh -R 3000:irc.libera.chat:6667 192.168.0.200fera apparaître un shell sur 192.168.0.200
, et les connexions de 192.168.0.200
à lui-même sur le port 3000 (le de l'hôte distant) seront envoyées via le tunnel à la machine locale, puis à irc.libera.chat sur le port 6667, ce qui, dans cet exemple, permet d'utiliser les programmes IRC sur l'hôte distant, même si le port 6667 lui serait normalement bloqué.
La redirection locale et distante peut être utilisée pour fournir une "passerelle" sécurisée, permettant à d'autres ordinateurs de profiter d'un tunnel SSH, sans réellement exécuter SSH ou le daemon SSH en fournissant une adresse de liaison pour le début du tunnel dans le cadre de la spécification de la redirection, par exemple . L'adresse <tunnel address>
peut être n'importe quelle adresse sur la machine au début du tunnel. L'adresse autorise les connexions via l'interface ou loopback, et une adresse vide ou autorise les connexions via n'importe quelle interface. Par défaut, le transfert est limité aux connexions provenant de la machine située au "début" du tunnel, c'est-à-dire que l'adresse est définie sur . La redirection locale ne nécessite aucune configuration supplémentaire, mais la redirection à distance est limitée par la configuration du daemon SSH du serveur distant. Consultez l'option dans et l'option dans pour plus d'informations sur le transfert à distance et le transfert local, respectivement.
Hôtes de saut
Dans certains scénarios, il se peut qu'il n'y ait pas de connexion directe à votre daemon SSH cible, et l'utilisation d'un serveur de saut (ou serveur bastion) est nécessaire. Ainsi, nous essayons de connecter ensemble deux ou plusieurs tunnels SSH, et supposons que vos clés locales sont autorisées pour chaque serveur de la chaîne. Ceci est possible en utilisant le transfert d'agent SSH () et l'allocation de pseudo-terminaux () qui transmet votre clé locale avec la syntaxe suivante :
$ ssh -A -t -l user1 bastion1 \ ssh -A -t -l utilisateur2 intermédiaire2 \ ssh -A -t -l utilisateur3 cibleUne façon plus simple de le faire est d'utiliser l'option -J
:
Plusieurs hôtes dans la directive -J
peuvent être séparés par une virgule, ils seront connectés dans l'ordre de la liste. La partie n'est pas obligatoire, mais peut être utilisée. Les spécifications de l'hôte pour -J
utilisent le fichier de configuration ssh, donc des options spécifiques par hôte peuvent être définies ici, si nécessaire.
Un équivalent de l'indicateur -J
dans le fichier de configuration est l'option , consultez pour plus de détails.
Inverser SSH à travers un relais
L'idée est que le client se connecte au serveur via un autre relais, tandis que le serveur est connecté au même relais en utilisant un tunnel SSH inverse. Ceci est par exemple utile lorsque le serveur est derrière un NAT et que le relais est un serveur SSH accessible au public utilisé comme proxy auquel l'utilisateur a accès. La condition préalable est donc que les clés du client soient autorisées à la fois par le relais et le serveur et que les clés du serveur soient également autorisées par le relais pour la connexion SSH inverse.
L'exemple de configuration suivant suppose que l'utilisateur1 est le compte utilisateur utilisé sur le client, l'utilisateur2 sur le relais et l'utilisateur3 sur le serveur. Tout d'abord, le serveur doit établir le tunnel inverse avec :
ssh -R 2222:localhost:22 -N user2@relayCe qui peut également être automatisé avec un script de démarrage, un service systemd ou autossh.
Du côté client, la connexion est établie avec :
ssh -t user2@relay ssh user3@localhost -p 2222La commande à distance pour établir la connexion au tunnel inverse peut également être définie dans le ~/.ssh/authorized_keys
du relais en incluant le champ comme suit :
Dans ce cas, la connexion est établie avec :
ssh user2@relayNotez que la fonction d'autocomplétion de SCP dans le terminal du client ne fonctionne pas et que les transferts SCP eux-mêmes ne fonctionnent pas dans certaines configurations.
Multiplexage
Le daemon SSH écoute généralement sur le port 22. Cependant, il est courant pour de nombreux points d'accès publics à Internet de bloquer tout le trafic qui n'est pas sur les ports HTTP/S habituels (80 et 443, respectivement), bloquant ainsi efficacement les connexions SSH. La solution immédiate à ce problème consiste à faire en sorte que écoute en plus sur l'un des ports de la liste blanche :
Cependant, il est probable que le port 443 soit déjà utilisé par un serveur web servant du contenu HTTPS, auquel cas il est possible d'utiliser un multiplexeur, tel que , qui écoute sur le port multiplexé et peut transférer intelligemment les paquets vers de nombreux services.
Accélérer SSH
Il existe plusieurs options configuration du client qui peuvent accélérer les connexions de manière globale ou pour des hôtes spécifiques. Consultez pour une description complète de ces options.
Montage d'un système de fichiers distant avec SSHFS
Veuillez vous référer à l'article SSHFS pour monter un système distant accessible par SSH dans un répertoire local, ce qui vous permettra d'effectuer n'importe quelle opération sur les fichiers montés avec n'importe quel outil (copier, renommer, éditer avec vim, etc.). sshfs est généralement préféré à shfs, ce dernier n'ayant pas été mis à jour depuis 2004.
Maintenir en vie
Par défaut, la session SSH se déconnecte automatiquement si elle est restée inactive pendant un certain temps. Pour maintenir la session en vie, le client peut envoyer un signal de maintien en vie au serveur si aucune donnée n'a été reçue depuis un certain temps, ou symétriquement, le serveur peut envoyer des messages à intervalles réguliers s'il n'a pas reçu de nouvelles du client.
ServerAliveInterval
positif et de laisser les autres clients et serveurs dans leur configuration par défaut.Redémarrer automatiquement les tunnels SSH avec systemd
systemd peut démarrer automatiquement les connexions SSH au démarrage/à la connexion et les redémarrer lorsqu'elles échouent. Cela en fait un outil utile pour la maintenance des tunnels SSH.
Le service suivant peut démarrer un tunnel SSH à la connexion en utilisant les paramètres de connexion dans votre ssh configuration. Si la connexion se ferme pour une raison quelconque, il attend 10 secondes avant de la redémarrer :
Puis activez et démarrez le service comme utilisateur. Consultez #Maintenir en vie pour savoir comment empêcher le tunnel de s'interrompre. Si vous souhaitez démarrer le tunnel au démarrage, vous pourriez vouloir réécrire l'unité en tant que service système.
Autossh - redémarrer automatiquement les sessions et tunnels SSH
Lorsqu'une session ou un tunnel ne peut être maintenu en vie, par exemple en raison de mauvaises conditions de réseau provoquant des déconnexions du client, vous pouvez utiliser pour les redémarrer automatiquement.
Exemples d'utilisation :
$ autossh -M 0 -o "ServerAliveInterval 45" -o "ServerAliveCountMax 2" username@example.comCombiné avec SSHFS :
$ sshfs -o reconnect,compression=yes,transform_symlinks,ServerAliveInterval=45,ServerAliveCountMax=2,ssh_command='autossh -M 0' username@example.com : /mnt/exempleConnexion via un proxy SOCKS défini par Paramètres du proxy :
$ autossh -M 0 -o "ServerAliveInterval 45" -o "ServerAliveCountMax 2" -NCD 8080 username@example.comAvec l'option , autossh peut être exécuté en tant que processus de fond. Cependant, cela signifie que la phrase de passe ne peut pas être saisie de manière interactive.
La session se termine lorsque vous tapez dans la session, ou lorsque le processus autossh reçoit un signal SIGTERM, SIGINT ou SIGKILL.
Lancer automatiquement autossh au démarrage via systemd
Si vous souhaitez lancer automatiquement autossh, vous pouvez créer un fichier d'unité systemd :
Ici est une variable d'environnement qui spécifie combien de temps ssh doit être actif avant qu'autossh ne le considère comme une connexion réussie. En lui donnant la valeur 0, autossh ignore également l'échec de la première exécution de ssh. Cela peut être utile lorsque autossh est lancé au démarrage. D'autres variables d'environnement sont disponibles à autossh(1). Bien sûr, vous pouvez rendre cette unité plus complexe si nécessaire (consultez la documentation de systemd pour plus de détails), et vous pouvez évidemment utiliser vos propres options pour autossh, mais notez que le impliquant ne fonctionne pas avec systemd.
N'oubliez pas : démarrez et/ou activez le service par la suite.
Vous pouvez également avoir besoin de désactiver ControlMaster, par ex.
ExecStart=/usr/bin/autossh -M 0 -o ControlMaster=no -NL 2222:localhost:2222 -o TCPKeepAlive=yes foo@bar.comService alternatif en cas d'échec du daemon SSH
Pour les serveurs distants ou sans tête qui reposent exclusivement sur SSH, un échec du démarrage du daemon SSH (par exemple, après une mise à jour du système) peut empêcher l'accès à l'administration. systemd offre une solution simple via l'option .
Supposons que le serveur exécute et que telnet soit l'alternative de choix en cas d'échec. Créez un fichier comme suit. N'activez pas telnet.socket
!
C'est tout. Telnet n'est pas disponible lorsque est en cours d'exécution. Si le démarrage de échoue, une session telnet peut être ouverte pour la récupération.
Couleur de fond du terminal basée sur l'hôte
Pour mieux distinguer si vous êtes sur différents hôtes, vous pouvez définir une couleur de fond différente en fonction du type d'hôte.
Cette solution fonctionne, mais n'est pas universelle (ZSH uniquement).
Configuration spécifique au réseau
Vous pouvez utiliser une configuration d'hôte spécifique au réseau auquel vous êtes connecté en utilisant un .
Par exemple, lorsque vous utilisez nmcli, et que la connexion est configurée (manuellement ou par DHCP) pour utiliser un domaine de recherche :
Vérification des clés d'hôtes des réseaux privés
Parce que différents serveurs sur différents réseaux sont susceptibles de partager une adresse IP privée commune, vous pourriez vouloir les traiter différemment.
La meilleure solution consiste à utiliser la #Configuration spécifique au réseau pour utiliser un différent selon le réseau sur lequel vous vous trouvez. La seconde solution, qu'il est préférable d'utiliser par défaut lorsque vous travaillez sur des réseaux nouveaux/prototypes, serait d'ignorer tout simplement les clés d'hôte pour les réseaux privés :
Exécuter une commande à la connexion
Si vous utilisez une session interactive, il existe plusieurs façons d'exécuter une commande à la connexion :
Transfert d'agent
Le transfert d'agent SSH vous permet d'utiliser vos clés locales lorsque vous êtes connecté à un serveur. Il est recommandé d'activer le transfert d'agent uniquement pour certains hôtes.
Ensuite, configurez un agent SSH et ajoutez votre clé locale avec ssh-add.
Si vous vous connectez maintenant à un serveur distant, vous pourrez vous connecter à d'autres services en utilisant vos clés locales.
Génération de nouvelles clés
De nouvelles clés privées de serveur peuvent être générées :
Dépannage
Checklist
Vérifiez ces problèmes simples avant de chercher plus loin.
Connexion refusée ou problème de timeout
Redirection de port
Si vous êtes derrière un mode/routeur NAT (ce qui est probable, sauf si vous êtes sur un VPS ou un hôte à adresse publique), assurez-vous que votre routeur transfère les connexions ssh entrantes vers votre machine. Trouvez l'adresse IP interne du serveur avec et configurez votre routeur pour qu'il transfère le TCP sur votre port SSH vers cette IP. portforward.com peut vous aider à le faire.
Est-ce que SSH fonctionne et écoute ?
L'utilitaire ss affiche tous les processus qui écoutent un port TCP avec la ligne de commande suivante :
$ ss --tcp --listeningSi la commande ci-dessus ne montre pas que le système écoute le port , alors SSH ne fonctionne pas : vérifiez le journal pour les erreurs, etc.
Des règles de pare-feu bloquent-elles la connexion ?
iptables peut bloquer les connexions sur le port . Vérifiez-le avec :
et recherchez les règles qui pourraient bloquer des paquets sur la chaîne INPUT
. Ensuite, si nécessaire, débloquez le port avec une commande telle que :
# iptables -I INPUT 1 -p tcp --dport 22 -j ACCEPT
Pour plus d'aide sur la configuration des pare-feu, consultez pare-feu.
Le trafic arrive-t-il jusqu'à votre ordinateur ?
Lancez une vidange du trafic sur l'ordinateur avec lequel vous avez des problèmes :
# tcpdump -lnn -i any port ssh et tcp-synCette opération devrait afficher des informations de base, puis attendre qu'un trafic correspondant se produise avant de l'afficher. Essayez votre connexion maintenant. Si vous ne consultez aucun résultat lorsque vous tentez de vous connecter, c'est que quelque chose d'extérieur à votre ordinateur bloque le trafic (par exemple, un pare-feu matériel, un routeur NAT, etc.).
Votre FAI ou un tiers bloque le port par défaut ?
Dans certains cas, votre FAI peut bloquer le port par défaut (port SSH 22), de sorte que tout ce que vous tentez (ouverture de ports, durcissement de la pile, défense contre les attaques par inondation, etc.) est inutile. Pour confirmer cela, créez un serveur sur toutes les interfaces (0.0.0.0) et connectez-vous à distance.
Si vous obtenez un message d'erreur comparable à celui-ci :
ssh : connect to host www.inet.hr port 22 : Connection refusedCela signifie que le port n'est pas bloqué par le FAI, mais que le serveur n'exécute pas SSH sur ce port (consultez wikipedia:fr:Sécurité par l'obscurité).
Toutefois, si vous obtenez un message d'erreur comparable à celui-ci :
ssh : connect to host 111.222.333.444 port 22 : Operation timed outCela signifie que quelque chose rejette votre trafic TCP sur le port 22. En fait, ce port est furtif, soit à cause de votre pare-feu, soit à cause de l'intervention d'un tiers (comme un FAI qui bloque et/ou rejette le trafic entrant sur le port 22). Si vous savez que vous n'exécutez pas de pare-feu sur votre ordinateur et que vous savez que les Gremlins ne pullulent pas dans vos routeurs et switchs, alors votre FAI bloque le trafic.
Pour vérifier, vous pouvez exécuter Wireshark sur votre serveur et écouter le trafic sur le port 22. Étant donné que Wireshark est un utilitaire de reniflage de paquets de couche 2, et que TCP/UDP sont des couches 3 et plus (consultez IP Network stack), si vous ne recevez rien lorsque vous vous connectez à distance, il est fort probable qu'un tiers bloque le trafic sur ce port vers votre serveur.
Diagnostic
Installez soit soit Wireshark avec le paquet .
Pour tcpdump :
# tcpdump -ni interface "port 22"Pour Wireshark :
$ tshark -f "tcp port 22" -i interfaceoù est l'interface réseau pour une connexion WAN (consultez pour vérifier). Si vous ne recevez aucun paquet lorsque vous essayez de vous connecter à distance, vous pouvez être certain que votre FAI bloque le trafic entrant sur le port 22.
Solution possible
La solution consiste simplement à utiliser un autre port que le FAI ne bloque pas. Ouvrez le et configurez le fichier pour utiliser différents ports. Par exemple, ajoutez :
Port 22 Port 1234Assurez-vous également que les autres lignes de configuration du "Port" dans le fichier sont commentées. Le fait de commenter "Port 22" et de mettre "Port 1234" ne résoudra pas le problème car sshd n'écoutera que sur le port 1234. Utilisez les deux lignes pour exécuter le serveur SSH sur les deux ports.
Redémarrez le serveur et vous avez presque terminé. Vous devez encore configurer votre ou vos clients pour qu'ils utilisent l'autre port au lieu du port par défaut. Il existe de nombreuses solutions à ce problème, mais nous allons en aborder deux ici.
Échec de la lecture de la socket : la connexion a été réinitialisée par le pair
Les versions récentes d'openssh échouent parfois avec le message d'erreur ci-dessus lors de la connexion à des serveurs ssh plus anciens. Ce problème peut être contourné en définissant diverses options du client pour cet hôte. Consultez pour plus d'informations sur les options suivantes.
Le problème peut provenir des algorithmes de clé hôte elliptique . Ceux-ci peuvent être désactivés en définissant comme une liste excluant ces algorithmes.
Si cela ne fonctionne pas, il se peut que la liste des algorithmes de chiffrement soit trop longue. Définissez l'option sur une liste plus courte (moins de 80 caractères devraient suffire). De même, vous pouvez essayer de raccourcir la liste des MAC
.
Consultez également la discussion sur le forum des bogues d'openssh.
"[votre shell] : No such file or directory" / problème de ssh_exchange_identification
Une cause possible de ce problème est le besoin de certains clients SSH de trouver un chemin absolu (celui renvoyé par , par exemple) dans , même si le binaire du shell est situé dans l'une des entrées $PATH
.
Message d'erreur "Terminal inconnu" ou "Erreur d'ouverture de terminal"
Si vous recevez les erreurs ci-dessus lors de la connexion, cela signifie que le serveur ne reconnaît pas votre terminal. Les applications Ncurses comme nano peuvent échouer avec le message "Error opening terminal".
La bonne solution est d'installer le fichier terminfo du terminal du client sur le serveur. Ce fichier indique aux programmes de console sur le serveur comment interagir correctement avec votre terminal. Vous pouvez obtenir des informations sur le fichier terminfo actuel à l'aide de , puis trouver à quel paquet il appartient.
Si vous ne pouvez pas l'installer normalement, vous pouvez copier votre terminfo dans votre répertoire personnel sur le serveur :
$ ssh myserver mkdir -p ~/.terminfo/${TERM:0:1} $ scp /usr/share/terminfo/${TERM:0:1}/$TERM myserver:~/.terminfo/${TERM:0:1}/Après avoir ouvert et fermé une session sur le serveur, le problème devrait être résolu.
TERM hack
Vous pouvez aussi simplement définir dans votre environnement sur le serveur (par exemple dans ). Cela fera taire l'erreur et permettra aux applications ncurses de s'exécuter à nouveau, mais vous pouvez avoir un comportement étrange et des problèmes graphiques à moins que les séquences de contrôle de votre terminal ne correspondent exactement à celles de xterm.
Connexion fermée par x.x.x.x [preauth]
Si vous consultez cette erreur dans les journaux sshd, vérifiez que vous avez défini une clé d'hôte valide.
HostKey /etc/ssh/ssh_host_rsa_keysubsystem request failed
Depuis OpenSSH 8.8, scp utilise SFTP comme protocole par défaut pour les transferts de données en demandant le sous-système nommé . Si vous exécutez scp en mode verbeux, , vous pouvez déterminer quel sous-système votre client utilise (par exemple, ). Les erreurs telles que subsystem request failed on channel 0
peuvent être corrigées en configurant les paramètres du sous-système du serveur : . La configuration du serveur doit ressembler à l'exemple ci-dessous.
id_dsa refusé par OpenSSH 7.0
OpenSSH 7.0 a déprécié les clés publiques DSA pour des raisons de sécurité. Si vous devez absolument les activer, définissez l'option de configuration . (https://www.openssh.com/legacy.html ne le mentionne pas).
Aucune méthode d'échange de clés correspondante trouvée par OpenSSH 7.0
OpenSSH 7.0 a déprécié l'algorithme de clé diffie-hellman-group1-sha1 car il est faible et se trouve dans la portée théorique de l'attaque dite Logjam (consultez https://www.openssh.com/legacy.html). Si l'algorithme de clé est nécessaire pour un hôte particulier, ssh produira un message d'erreur comme celui-ci :
Unable to negotiate with 127.0.0.1: no matching key exchange method found. Their offer: diffie-hellman-group1-sha1La meilleure solution pour ces échecs est de mettre à jour/configurer le serveur pour ne pas utiliser les algorithmes dépréciés. Si cela n'est pas possible, vous pouvez forcer le client à réactiver l'algorithme avec l'option client. .
Session tmux/screen tuée lors de la déconnexion de SSH
Si vos processus sont tués à la fin de la session, il est possible que vous utilisiez l'activation de la socket et qu'elle soit tuée par lorsqu'elle remarque que le processus de la session SSH a quitté. Dans ce cas, il existe deux solutions. La première consiste à éviter d'utiliser l'activation de socket en utilisant ssh.service
au lieu de . L'autre consiste à définir dans la section Service de .
Le paramètre peut également être utile avec le classique ssh.service
, car il évite de tuer le processus de session SSH ou les processus screen ou lorsque le serveur est arrêté ou redémarré.
La session SSH cesse de répondre
SSH répond aux commandes de contrôle de flux et . Il se fige/se fige/cesse de répondre lorsque vous appuyez sur . Utilisez pour reprendre votre session.
Broken pipe
Si vous tentez de créer une connexion qui donne lieu à une réponse Broken pipe
pour , vous devez réessayer la connexion en mode débogage et consulter si la sortie se termine par une erreur :
La ligne send packet
ci-dessus indique que le paquet de réponse n'a jamais été reçu. Il s'ensuit donc qu'il s'agit d'un problème de QoS. Pour diminuer la probabilité qu'un paquet soit abandonné, définissez :
Le paramètre () devrait résoudre le problème, ainsi que les types de service et . (0x08
).
Démarrage lent des daemons après un redémarrage
Si vous rencontrez des temps de démarrage de daemon excessivement longs après les redémarrages (par exemple, plusieurs minutes avant que le daemon ne commence à accepter des connexions), en particulier sur des serveurs «headless» ou virtualisés, cela peut être dû à un manque d'entropie . Cela peut être résolu en installant Rng-tools ou Haveged, selon ce qui convient à votre système. Cependant, prenez note des implications de sécurité associées discutées dans la page wiki respective de chaque paquet.
Terminer une connexion SSH qui ne répond pas
Si une session client ne répond plus et ne peut être interrompue en donnant des instructions au programme en cours d'exécution (par exemple, le shell), vous pouvez toujours mettre fin à la session en appuyant successivement sur , et dans cet ordre.
Le est un caractère d'échappement pseudo-terminal (consultez ssh(1) § ESCAPE CHARACTERS), qui peut être ajouté plusieurs fois en fonction de la session client à interrompre. Par exemple, si vous vous êtes connecté de A à B puis de B à C et que la session de B à C se fige, vous pouvez y mettre fin en appuyant sur et en tapant , ce qui vous laissera dans une session de travail sur B.
Attention : l'identification de l'hôte distant a changé !
Si le client vous avertit que la clé d'un serveur ssh a changé, vous devez vérifier que la nouvelle clé proposée appartient bien à l'opérateur du serveur. Ensuite, supprimez l'ancienne clé du fichier avec et acceptez la nouvelle clé comme s'il s'agissait d'un nouveau serveur.
Connexion à un serveur distant sans l'entrée terminfo appropriée
Lorsque vous vous connectez à des hôtes qui n'ont pas d'entrée terminfo pour votre terminal, par exemple, lorsque vous utilisez un émulateur de terminal dont l'entrée terminfo n'est pas fournie avec . (par exemple, kitty et rxvt-unicode), ou lorsque vous vous connectez à des hôtes dont la base de données terminfo est limitée (par exemple, les systèmes exécutant OpenWrt), divers problèmes peuvent survenir avec les logiciels qui reposent sur .
Une bonne solution consiste à placer l'entrée terminfo appropriée sur l'hôte. Si cela n'est pas possible, une alternative est de définir à une valeur qui est à la fois prise en charge par l'hôte distant et compatible avec le terminal.
Depuis OpenSSH 8.7, une variable d'environnement personnalisée peut être passée aux hôtes distants avec un simple extrait de configuration :
~/.ssh/config
Host example.com SetEnv TERM=xterm-256color
La connexion à travers l'hôte de saut échoue avec "bash : No such file or directory"
Si la variable d'environnement n'est pas définie sur un chemin complet et valide (sur le serveur de saut), la connexion échouera avec un message d'erreur similaire à celui-ci :
bash: No such file or directory kex_exchange_identification: Connection closed by remote host Connection closed by UNKNOWN port 65535Vous pouvez simplement résoudre ce problème en définissant votre à un nom de chemin complet d'un shell qui sera également valide sur le serveur de saut ou en définissant une variable spécifique pour chaque serveur dans votre fichier .