Man page - sshd(8)

Packages contains this manual

Package:  openssh-server
apt-get install openssh-server

Manuals in package:
• authorized_keys(5)
• sshd_config(5)
• moduli(5)
• sshd(8)

Available languages:

en fr ro de

Manual

---

SSHD (8) System Manager’s Manual SSHD (8)

NOM

sshd — Démon d’OpenSSH

SYNOPSIS

sshd [ -46DdeGiqTtV ] [ -C spec_connexion ] [ -c fich_certificat_hote ] [ -E fich_journal ] [ -f fich_config ] [ -g delai_grace_connexion ] [ -h fich_clef_hote ] [ -o option ] [ -p port ] [ -u longueur ]

DESCRIPTION

sshd (le démon d’OpenSSH) est le programme démon pour ssh (1). Il permet des communications sécurisées et chiffrées entre deux machines considérées comme non fiables, et ce sur un réseau non sécurisé.

sshd attend les demandes de connexion en provenance des clients. Il est normalement démarré à l’amorçage de la machine (boot) depuis /etc/init.d/ssh . Il crée un nouveau démon en se clonant à l’aide d’un « fork » à chaque connexion entrante. Les démons clonés prennent en charge l’échange de clés, le chiffrement, l’authentification, l’exécution de commandes et l’échange de données.

sshd peut être configuré à l’aide d’options sur la ligne de commande ou d’un fichier de configuration (par défaut sshd_config (5))  ; les options sur la ligne de commande l’emportent sur les valeurs spécifiées dans le fichier de configuration. sshd relit son fichier de configuration quand il reçoit le signal de raccrochage SIGHUP en s’exécutant lui-même avec le nom et les options avec lesquels il a été démarré, par exemple /usr/sbin/sshd .

Les options sont les suivantes :

-4

Forcer sshd à n’utiliser que des adresses IPv4.

-6

Forcer sshd à n’utiliser que des adresses IPv6.

-C spec_connexion

Cette option permet de spécifier les paramètres de connexion à utiliser pour le mode de test étendu -T . Si elle est définie, toute directive Match du fichier de configuration qui s’appliquerait est exécutée avant que la configuration ne soit affichée sur la sortie standard. Les paramètres de connexion sont spécifiés sous forme de paires mot-clé=valeur dans un ordre quelconque, soit à l’aide de plusieurs options -C , soit sous la forme d’une liste de paires mot-clé=valeur séparées par des virgules. Les mots-clés sont « addr », « user », « host », « laddr », « port » et « rdomain » et correspondent respectivement à l’adresse source, l’utilisateur, le nom résolu de l’hôte source, l’adresse locale, le numéro de port local et le domaine de routage. De plus, le drapeau “invalid-user” (qui ne prend pas d’argument de valeur) peut être spécifier pour simuler une connexion à partir d’un nom d’utilisateur non reconnu.

-c fich_certificat_hote

Cette option permet de spécifier le chemin d’un fichier de certificat pour identifier sshd lors d’un échange de clés. Le fichier de certificat doit correspondre à un fichier de clé d’hôte spécifié à l’aide de l’option -h ou de la directive de configuration HostKey .

-D

Si cette option est spécifiée, sshd ne se détachera pas du terminal et ne deviendra pas un démon, ce qui permet de surveiller facilement sshd .

-d

Mode de débogage. Le serveur envoie une sortie de débogage prolixe sur la sortie d’erreur standard et ne se place pas lui-même à l’arrière-plan. En outre, le serveur n’exécute pas de fork (2) et ne traite qu’une connexion. Cette option n’est utilisée que pour le débogage du serveur. Le niveau de débogage augmente avec le nombre d’options -d spécifiées (au maximum 3).

-E fichier_journal

Si cette option est définie, les messages de journalisation de débogage sont enregistrés dans log_file au lieu du journal système.

-e

Cette option permet d’envoyer les messages de journalisation de débogage sur la sortie d’erreur standard au lieu du journal système.

-f fich_config

Cette option permet de spécifier le nom du fichier de configuration. Le fichier par défaut est /etc/ssh/sshd_config . sshd refusera de démarrer s’il n’y a pas de fichier de configuration.

-G

Cette option permet l’analyse et l’affichage du contenu du fichier de configuration. sshd vérifie la validité du fichier de configuration, affiche la configuration effective sur la sortie standard et quitte. Les règles Match peuvent s’appliquer en spécifiant les paramètres de connexion à l’aide d’une ou plusieurs options -C .

-g delai_grace_connexion

Cette option permet d’accorder un délai de grâce aux clients pour s’authentifier (par défaut 120 secondes). Si le client ne parvient pas à authentifier l’utilisateur avant ce délai, le serveur se déconnecte et quitte. Une valeur de 0 indique qu’il n’y a pas de limite.

-h fich_clef_hote

Cette option permet de spécifier un fichier à partir duquel la clé d’hôte sera lue. Cette option doit être utilisée si sshd n’est pas exécuté par le superutilisateur, car les fichiers de clé d’hôte normaux ne sont en général accessibles en lecture que par le superutilisateur. Les fichiers par défaut sont /etc/ssh/ssh_host_ecdsa_key , /etc/ssh/ssh_host_ed25519_key et /etc/ssh/ssh_host_rsa_key . Il est possible de spécifier plusieurs fichiers de clé d’hôte pour les différents algorithmes de clé d’hôte.

-i

Cette option permet d’indiquer que sshd est exécuté par inetd (8).

-o option

Cette option permet de spécifier des options au format du fichier de configuration. Elle permet de spécifier des options qui n’ont pas d’équivalent en ligne de commande. Pour des détails complets à propos des options et de leurs valeurs, voir sshd_config (5).

-p port

Cette option permet de spécifier le port sur lequel le serveur écoute les connexions entrantes (par défaut 22). On peut spécifier plusieurs options de port. Les ports spécifiés dans le fichier de configuration avec l’option Port sont ignorés quand un port est passé en option sur la ligne de commande. Les ports spécifiés en utilisant l’option ListenAddress l’emportent sur ceux spécifiés sur la ligne de commande.

-q

Mode silencieux. Rien n’est envoyé au journal système. Normalement, le début, l’authentification et la fin de chaque connexion sont journalisés.

-T

Mode de test étendu. Ce mode vérifie la validité du fichier de configuration, affiche la configuration effective sur la sortie standard et quitte. Les règles Match peuvent éventuellement s’appliquer en spécifiant des paramètres de connexion à l’aide d’une ou plusieurs options -C . Identique au drapeau -G , il inclut en plus les tests effectués par le drapeau -t .

-t

Mode de test. Ce mode vérifie uniquement la validité du fichier de configuration et des clés. Il s’avère utile pour mettre à jour sshd de manière fiable, car des options de configuration peuvent changer.

-u longueur

Cette option permet de spécifier la taille du champ de la structure utmp qui contient le nom de la machine distante. Si le nom de la machine après résolution est plus long que longueur , c’est la valeur décimale contenant des points de l’adresse qui sera utilisée à la place. Cela permet d’identifier de manière unique les machines avec des noms très longs, même si ces derniers dépassent la capacité de ce champ. Spécifier -u0 impose que seules les adresses en valeurs décimales contenant des points seront enregistrées dans le fichier utmp . -u0 permet aussi d’empêcher sshd de faire des requêtes DNS, à moins que le mécanisme d’authentification ou la configuration le nécessite. Les mécanismes d’authentification qui peuvent nécessiter des requêtes DNS comprennent HostbasedAuthentication et l’utilisation d’une option from="liste_motifs" dans un fichier de clé. Les options de configuration qui nécessitent une requête DNS comprennent l’utilisation d’un motif UTILISATEUR@HOTE dans les options AllowUsers ou DenyUsers .

-V

Affiche le numéro de version et quitte.

AUTHENTIFICATION

Le démon SSH d’OpenSSH ne prend en charge que la version 2 du protocole SSH. Pour s’identifier, chaque hôte possède une clé spécifique aux hôtes. Chaque fois qu’un client se connecte, le démon répond avec sa clé d’hôte publique. Le client compare cette clé avec sa propre base de données pour vérifier qu’elle n’a pas changé. La sécurité des transmissions est mise en œuvre au moyen d’un échange de clés Diffie-Hellman. Cet échange de clés résulte en une clé de session partagée. Le reste de la session est chiffré en utilisant un algorithme de chiffrement symétrique. Le client sélectionne l’algorithme de chiffrement à utiliser parmi ceux que propose le serveur. En outre, l’intégrité de la session est assurée à l’aide d’un code cryptographique d’authentification de message (MAC).

En fin de compte, le serveur et le client entament un dialogue d’authentification. Le client tente de s’authentifier en utilisant une authentification basée sur la machine, une authentification par clé publique, une authentification par questions-réponses ou une authentification par mot de passe.

Quel que soit le type d’authentification, le compte est vérifié pour s’assurer qu’il est accessible. Un compte n’est pas accessible s’il est verrouillé, s’il fait partie de la liste DenyUsers ou si son groupe fait partie de la liste DenyGroups . La définition d’un compte verrouillé dépend du système. Certaines plateformes possèdent leur propre base de données de comptes (par exemple AIX), tandis que d’autres modifient le champ mot de passe (« *LK* » sur Solaris et UnixWare, « * » sur HP-UX, « Nologin » sur Tru64, « *LOCKED* » au début sur FreeBSD et un « ! » au début sur la plupart des Linux). S’il faut désactiver l’authentification par mot de passe pour un compte tout en autorisant l’authentification par clé publique, le champ mot de passe doit être défini à une valeur différente de celles ci-dessus (par exemple « NP » ou « *NP* »).

Si le client s’authentifie avec succès, un dialogue est entamé pour préparer la session. À cet instant, le client peut demander l’allocation d’un pseudo-terminal, la redirection des connexions X11, la redirection des connexions TCP ou la redirection de la connexion de l’agent d’authentification sur le canal sécurisé.

Ensuite, le client demandera un interpréteur de commande interactif ou l’exécution d’une commande non interactive que sshd exécutera à l’aide de l’interpréteur de commande de l’utilisateur en utilisant son option -c . Les deux extrémités entrent alors en mode session. Dans ce mode, les deux extrémités peuvent envoyer des données à tout moment et ces données sont redirigées de/vers l’interpréteur de commande ou la commande côté serveur, et de/vers le terminal de l’utilisateur côté client.

Lorsque le programme de l’utilisateur se termine et que toutes les connexions redirigées X11 ou autres ont été fermées, le serveur envoie un code de fin de commande au client et les deux extrémités quittent.

PROCESSUS DE CONNEXION

Lorsqu’un utilisateur se connecte avec succès, sshd effectue les opérations suivantes :

1.

Si la connexion s’appuie sur un terminal et si aucune commande n’a été spécifiée, il affiche la date et l’heure de dernière connexion et le message du jour /etc/motd (sauf si cet affichage est annulé dans le fichier de configuration ou à l’aide de ˜/.hushlogin ; voir la section “FICHIERS”).

2.

Si la connexion s’appuie sur un terminal, il enregistre la date et l’heure de connexion.

3.

Il vérifie la présence du fichier /etc/nologin ; s’il existe, il affiche son contenu et quitte (sauf pour le superutilisateur).

4.

Il change ses privilèges d’exécution pour ceux d’un utilisateur normal.

5.

Il définit un environnement basique.

6.

Il lit le fichier ˜/.ssh/environment , s’il existe et si les utilisateurs ont l’autorisation de changer leur environnement. Voir l’option PermitUserEnvironment dans sshd_config (5).

7.

Il se place dans le répertoire personnel de l’utilisateur.

8.

Si le fichier ˜/.ssh/rc existe et si l’option PermitUserRC de sshd_config (5) est définie, il l’exécute ; sinon, si le fichier /etc/ssh/sshrc existe, il l’exécute ; sinon, il exécute xauth (1). Les fichiers « rc » reçoivent le protocole d’authentification et le cookie d’X11 sur l’entrée standard. Voir “SSHRC” ci-dessous.

9.

Il exécute la commande ou l’interpréteur de commande de l’utilisateur. Toutes les commandes sont exécutées par l’interpréteur de commande de connexion de l’utilisateur spécifié dans la base de données des mots de passe du système.

SSHRC

Si le fichier ˜/.ssh/rc existe, sh (1) l’exécute après avoir lu les fichiers d’environnement, mais avant d’exécuter la commande ou l’interpréteur de commande de l’utilisateur. Toute sortie consécutive à l’exécution de ce fichier doit être envoyée sur la sortie d’erreur standard (stderr) à la place de la sortie standard (stdout). Si la redirection d’X11 est activée, ce fichier recevra la paire « proto cookie » sur son entrée standard (et DISPLAY dans son environnement). Le script doit appeler xauth (1), car sshd ne le fait pas automatiquement pour ajouter les cookies d’X11.

Ce fichier avait initialement pour but d’exécuter toute routine d’initialisation qui pouvait être nécessaire avant que le répertoire personnel de l’utilisateur devienne accessible ; AFS est un exemple particulier de ce type d’environnement.

Ce fichier contiendra probablement du code d’initialisation suivi de quelque chose similaire à :

if read proto cookie && [ -n "$DISPLAY" ]; then

	if [ ‘echo $DISPLAY | cut -c1-10‘ = ’localhost:’ ]; then
		# X11UseLocalhost=yes
		echo add unix:‘echo $DISPLAY |
		cut -c11-‘ $proto $cookie
	else
		# X11UseLocalhost=no
		echo add $DISPLAY $proto $cookie
	fi | xauth -q -

fi

Si ce fichier n’existe pas, /etc/ssh/sshrc est exécuté s’il existe, sinon le cookie est ajouté à l’aide de xauth.

FORMAT DU FICHIER AUTHORIZED_KEYS

L’option AuthorizedKeysFile permet de spécifier les fichiers contenant les clés publiques pour l’authentification par clé publique ; si elle n’est pas définie, les fichiers par défaut sont ˜/.ssh/authorized_keys et ˜/.ssh/authorized_keys2 . Chaque ligne de ces fichiers contient une clé (les lignes vides et les lignes commençant par « # » sont considérées comme des commentaires et sont ignorées). Une clé publique se compose des champs suivants séparés par des espaces : options, type de clé, clé codée en base64 et commentaire. Le champ options est facultatif. Les types de clé pris en charge sont :

sk-ecdsa-sha2-nistp256@openssh.com
ecdsa-sha2-nistp256
ecdsa-sha2-nistp384
ecdsa-sha2-nistp521
sk-ssh-ed25519@openssh.com
ssh-ed25519
ssh-rsa

Le champ commentaire n’a pas d’utilité particulière (mais il peut s’avérer utile à l’utilisateur pour identifier la clé).

Notez que les lignes de ces fichiers peuvent avoir une longueur de plusieurs centaines d’octets (à cause de la taille de l’encodage de la clé publique) avec une limite à 8 Ko, ce qui autorise des clés RSA d’une taille jusqu’à 16 kbit. Plutôt que de les taper à la main, copiez le fichier id_ecdsa.pub , id_ecdsa_sk.pub , id_ed25519.pub , id_ed25519_sk.pub ou id_rsa.pub et éditez-le.

sshd impose une taille minimale de 1024 bits pour le modulo de la clé RSA.

Le champ options (si présent) contient des spécifications d’option séparées par des virgules. Aucune espace n’est permise, sauf si elle est entourée de guillemets hauts doubles. Les spécifications d’option suivantes sont prises en charge (notez que les noms d’option sont insensibles à la casse) :

agent-forwarding

Cette option permet d’activer la redirection d’un agent d’authentification préalablement désactivée par l’option restrict .

cert-authority

Cette option permet d’indiquer que la clé en question correspond à une autorité de certification (CA) qui est digne de confiance pour valider des certificats signés pour l’authentification de l’utilisateur.

Les certificats peuvent encoder des restrictions d’accès similaires à ces options de clé. Si les restrictions de certificat et les options de clé sont toutes deux présentes, c’est l’union des deux la plus restrictive qui s’applique.

command="commande"

Cette option permet de spécifier une commande à exécuter chaque fois que la clé est utilisée pour l’authentification. La commande spécifiée par l’utilisateur (si elle existe) est ignorée. La commande est exécutée sur un pseudo-terminal si le client en demande un ; sinon elle est exécutée en dehors de tout terminal. Si un canal apte à la transmission sur 8 bits (« 8-bit clean channel ») est requis, on ne doit pas demander de pseudo-terminal ou on peut spécifier no-pty . La commande peut contenir des guillemets si ces derniers sont échappés par des barres obliques inversées.

Cette option peut être utile pour restreindre certaines clés publiques à des actions spécifiques. Par exemple, une clé peut n’autoriser que les sauvegardes distantes, mais rien d’autre. Notez que le client peut spécifier des redirections TCP et/ou d’X11, sauf si elles sont explicitement interdites à l’aide de l’option restrict , par exemple.

La commande originelle fournie par le client est enregistrée dans la variable d’environnement SSH_ORIGINAL_COMMAND. Notez que cette option s’applique à l’exécution d’un interpréteur de commande, d’une commande ou d’un sous-système. Notez aussi que cette option peut être outrepassée par une directive ForceCommand de sshd_config (5).

Si une commande est spécifiée et si une commande forcée est embarquée dans un certificat utilisé pour l’authentification, le certificat ne sera accepté que si les deux commandes sont identiques.

environment="NOM=valeur"

Cette option indique que la chaîne spécifiée doit être ajoutée à l’environnement lorsqu’on se connecte avec cette clé. Les variables d’environnement définies de cette manière l’emportent sur les autres valeurs de l’environnement par défaut. Il est possible de spécifier plusieurs options de ce type. L’option PermitUserEnvironment permet de contrôler le traitement de l’environnement, ce traitement étant désactivé par défaut.

expiry-time="spec_temps"

Cette option permet de spécifier une date après laquelle la clé ne sera plus acceptée. La date peut être spécifiée sous la forme AAAAMMJJ[Z] ou AAAAMMJJHHMM[SS][Z]. Dates et heures seront interprétées selon la zone horaire du système, sauf s’ils sont suffixés par le caractère « Z », auquel cas elles seront interprétées dans la zone horaire UTC.

from="liste_motifs"

Cette option permet de spécifier qu’en plus de l’authentification par clé publique, la liste de motifs séparés par des virgules devra comporter soit le nom canonique de la machine distante, soit son adresse IP. Voir la section MOTIFS dans ssh_config (5) pour plus d’informations à propos des motifs.

En plus de la correspondance avec caractères génériques applicable aux noms des machines ou à leurs adresses, une directive from peut comparer des adresses IP en utilisant la notation CIDR adresse/taille_masque.

Cette option a pour but de permettre d’améliorer la sécurité : l’authentification par clé publique en elle-même ne fait confiance ni au réseau, ni aux serveurs de noms, ni à rien du tout (sauf à la clé) ; cependant, si quelqu’un de quelque manière que ce soit vole la clé, cette dernière lui permettra de se connecter depuis n’importe où dans le monde. L’ajout de cette option rend plus difficile l’utilisation d’une clé volée (en plus de la clé, les serveurs de noms et/ou les routeurs devraient aussi être compromis).

no-agent-forwarding

Cette option permet d’interdire la redirection de l’agent d’authentification lorsque cette clé est utilisée pour l’authentification.

no-port-forwarding

Cette option permet d’interdire la redirection TCP lorsque cette clé est utilisée pour l’authentification. Toute demande de redirection de port de la part du client renverra une erreur. Cette option peut être utilisée, par exemple, en combinaison avec l’option command .

no-pty

Cette option permet d’empêcher l’allocation d’un terminal (toute demande pour allouer un pseudo-terminal échouera).

no-user-rc

Cette option permet de désactiver l’exécution de ˜/.ssh/rc .

no-X11-forwarding

Cette option permet d’interdire la redirection d’X11 lorsque cette clé est utilisée pour l’authentification. Toute demande de redirection d’X11 de la part du client renverra une erreur.

permitlisten="[machine:]port"

Cette option permet de limiter la redirection du port distant avec l’option -R de ssh (1) de façon à ce qu’il ne puisse écouter que sur la machine (facultatif) et le port spécifiés. Il est possible de spécifier des adresses IPv6 en les entourant de crochets. Plusieurs options permitlisten peuvent être spécifiées en les séparant avec des virgules. Les noms de machine peuvent contenir des caractères génériques comme décrit dans la section MOTIFS de ssh_config (5). Une valeur de port de * correspond à n’importe quelle valeur de port. Notez qu’une définition de GatewayPorts pourra restreindre encore plus les adresses d’écoute. Notez aussi que ssh (1) enverra le nom de machine « localhost » si aucune machine d’écoute n’a été spécifiée lors de la demande de redirection, et que ce nom est traité différemment des adresses localhost explicites « 127.0.0.1 » et « ::1 ».

permitopen="machine:port"

Cette option permet de limiter la redirection du port local avec l’option -L de ssh (1) de façon à ce qu’il ne puisse écouter que sur la machine et le port spécifiés. Il est possible de spécifier des adresses IPv6 en les entourant de crochets. Plusieurs options permitopen peuvent être spécifiées en les séparant avec des virgules. Aucune comparaison de motifs ou recherche de nom n’est effectuée sur les noms de machine spécifiés, ces derniers devant être des noms de machine sous forme littérale et/ou des adresses. Si l’on spécifie une valeur de port de * , toute valeur de port correspondra.

port-forwarding

Cette option permet d’activer une redirection de port préalablement désactivée à l’aide de l’option restrict .

principals="principals"

Sur une ligne cert-authority , cette option permet de spécifier les « principals » autorisés pour l’authentification par certificat sous la forme d’une liste séparée par des virgules (NDT : un « principal » est une chaîne arbitraire définie au niveau du serveur pour un utilisateur et devant être présente dans le certificat du client pour que ce dernier puisse se connecter). Pour que le certificat soit accepté, au moins un nom de la liste doit apparaître dans la liste de « principal » du certificat. Cette option est ignorée pour les clés qui ne sont pas marquées comme signataires de certificat de confiance à l’aide de l’option cert-authority .

pty

Cette option permet d’activer une allocation de terminal préalablement désactivée à l’aide de l’option restrict .

no-touch-required

Avec cette option, démontrer la présence de l’utilisateur pour les signatures effectuées en utilisant cette clé n’est pas nécessaire. Cette option n’a de sens que pour les algorithmes d’authentificateur FIDO ecdsa-sk et ed25519-sk .

verify-required

Avec cette option, les signatures effectuées en utilisant cette clé doivent attester qu’elles identifient l’utilisateur, par exemple à l’aide d’un PIN. Cette option n’a de sens que pour les algorithmes d’authentificateur FIDO ecdsa-sk et ed25519-sk .

restrict

Cette option applique toutes les restrictions, à savoir la désactivation de la redirection de port, d’agent et d’X11, ainsi que la désactivation de l’allocation de pseudo-terminal et l’exécution de ˜/.ssh/rc . Toute capacité de restriction ajoutée par la suite aux fichiers authorized_keys sera incluse dans cette ensemble.

tunnel="n"

Cette option permet d’imposer un dispositif tun (4) sur le serveur. Si le client demande un tunnel et si cette option n’est pas définie, c’est le premier dispositif de tunnel disponible qui sera utilisé.

user-rc

Cette option permet d’activer l’exécution de ˜/.ssh/rc préalablement désactivée à l’aide de l’option restrict .

X11-forwarding

Cette option permet d’activer la redirection d’X11 préalablement désactivée à l’aide de l’option restrict .

Un exemple de fichier authorized_keys :

# Les commentaires sont autorisés en début de ligne. Les lignes vides sont autorisées.
# Clé complète, pas de restrictions
ssh-rsa ...
# Commande forcée, désactivation du pseudo-terminal et de toutes les redirections
restrict,command="dump /home" ssh-rsa ...
# Restriction des destinations de redirection à l’aide de ssh -L
permitopen="192.0.2.1:80",permitopen="192.0.2.2:25" ssh-rsa ...
# Restriction des écouteurs de redirection à l’aide de ssh -R
permitlisten="localhost:8080",permitlisten="[::1]:22000" ssh-rsa ...
# Configuration de la redirection par tunnel
tunnel="0",command="sh /etc/netstart tun0" ssh-rsa ...
# Outrepasser la restriction de l’allocation de pseudo-terminal
restrict,pty,command="nethack" ssh-rsa ...
# Autoriser les clés FIDO sans nécessiter la présence de l’utilisateur
no-touch-required sk-ecdsa-sha2-nistp256@openssh.com ...
# Nécessite la vérification de l’utilisateur (par exemple par PIN ou biométrie)
# pour la clé FIDO
verify-required sk-ecdsa-sha2-nistp256@openssh.com ...
# Faire confiance à la clé de CA, autoriser FIDO sans présence de l’utilisateur
# si demandée dans le certificat
cert-authority,no-touch-required,principals="user_a" ssh-rsa ...

FORMAT DU FICHIER SSH_KNOWN_HOSTS

Les fichiers /etc/ssh/ssh_known_hosts et ˜/.ssh/known_hosts contiennent les clés publiques de tous les hôtes connus. Le fichier global doit être préparé par l’administrateur (facultatif), mais le fichier de l’utilisateur est mis à jour automatiquement : chaque fois que l’utilisateur se connecte à un hôte inconnu, sa clé est ajoutée au fichier de l’utilisateur.

Chaque ligne de ces fichiers contient les champs suivants : marqueur (facultatif), noms d’hôte, type de clé, clé encodée en base64, commentaire. Les champs sont séparés par des espaces.

Le marqueur est facultatif mais s’il est présent, il doit être égal à « @cert-authority » pour indiquer que la ligne contient une clé d’autorité de certification (CA), ou à « @revoked » pour indiquer que la clé que la ligne contient est révoquée et ne doit plus être acceptée. Un seul marqueur doit être présent dans une ligne de clé.

Les noms d’hôte constituent une liste de motifs séparés par des virgules (« * » et « ? » sont des caractères génériques) ; chaque motif l’un après l’autre est mis en correspondance avec le nom d’hôte. Quand sshd authentifie un client, comme lorsqu’on utilise HostbasedAuthentication , il s’agira du nom de machine canonique du client. Quand ssh (1) authentifie un serveur, il s’agira du nom d’hôte donné par l’utilisateur, de la valeur de l’option HostkeyAlias de ssh (1) si elle est spécifiée ou du nom d’hôte canonique du serveur si l’option CanonicalizeHostname est spécifiée.

Un motif peut aussi être précédé d’un point d’exclamation « ! » pour indiquer une négation : si le nom d’hôte correspond à un tel motif inversé, il ne sera pas accepté (par cette ligne), même s’il correspond à un autre motif de cette même ligne. Un nom d’hôte ou une adresse peuvent éventuellement être entourés de crochets « [ » et « ] » et suivis de « : » et d’un numéro de port non standard.

Autrement, les noms d’hôte peuvent être stockés sous une forme hachée qui dissimule les adresses et noms d’hôte au cas où le contenu du fichier venait à être divulgué. Les noms d’hôte hachés commencent par le caractère « | ». Une ligne ne doit contenir qu’un seul nom d’hôte haché et aucune négation comme ci-dessus et aucun caractère générique ne doit s’appliquer.

Le type de clé et la clé encodée en base64 sont directement extraits de la clé d’hôte qui peut être obtenue à partir de /etc/ssh/ssh_host_rsa_key.pub par exemple. Le champ commentaire facultatif continue jusqu’à la fin de la ligne et n’est pas utilisé.

Les lignes vides ou débutant par le caractère « # » sont ignorées et considérées comme des commentaires.

Lors d’une authentification de machine, l’authentification est acceptée si une ligne comporte la clé appropriée : soit une clé qui correspond exactement, soit, si le serveur a présenté un certificat pour l’authentification, la clé de l’autorité de certification qui a signé le certificat. Pour une clé qui possède la fiabilité d’une autorité de certification, elle doit utiliser le marqueur « @cert-authority » décrit ci-dessus.

Le fichier des hôtes connus permet aussi de marquer des clés comme révoquées, par exemple lorsqu’on sait que la clé privée associée a été volée. Les clés révoquées sont spécifiées en ajoutant le marqueur « @revoked » en début de ligne de clé et ne sont jamais acceptées pour l’authentification ou en tant qu’autorité de certification, mais elles provoquent un avertissement de la part de ssh (1) lorsqu’on en rencontre une.

Il est permis (mais déconseillé) d’associer plusieurs lignes ou différentes clés d’hôte à un seul nom d’hôte. Cela arrive inévitablement quand des versions courtes de noms d’hôte de différents domaines sont enregistrées dans le fichier. Les fichiers peuvent contenir des informations qui entrent en conflit ; l’authentification est cependant acceptée si l’on peut trouver des informations valables dans un des fichiers.

Notez que les lignes dans ces fichiers contiennent généralement des centaines de caractères, et il n’est pas très intéressant de les saisir manuellement. On peut plutôt les générer à l’aide d’un script, par exemple /etc/ssh/ssh_host_rsa_key.pub , et ajouter les noms d’hôte au début. ssh-keygen (1) fournit aussi quelques possibilités d’édition automatique de ˜/.ssh/known_hosts comme la suppression des hôtes qui correspondent à un nom d’hôte ou la conversion de tous les noms d’hôte en leurs représentations hachées.

Un exemple de fichier ssh_known_hosts :

# Les commentaires sont autorisés en début de ligne
cvs.example.net,192.0.2.10 ssh-rsa AAAA1234.....=
# Un nom d’hôte haché
|1|JfKTdBh7rNbXkVAQCRp4OQoPfmI=|USECr3SWf1JUPsms5AqfD5QfxkM= ssh-rsa
AAAA1234.....=
# Une clé révoquée
@revoked * ssh-rsa AAAAB5W...
# Une clé de CA acceptée pour tout hôte dans *.mydomain.com ou *.mydomain.org
@cert-authority *.mydomain.org,*.mydomain.com ssh-rsa AAAAB5W...

FICHIERS
˜/.hushlogin

Ce fichier permet de supprimer l’affichage de /etc/motd et de la date de dernière connexion si PrintMotd et PrintLastLog , respectivement, sont activées. Il ne supprime pas l’affichage de la bannière spécifiée par Banner .

˜/.rhosts

Ce fichier est utilisé pour l’authentification basée sur la machine (voir ssh (1) pour plus d’informations). Sur certaines machines, ce fichier devra peut-être être accessible en lecture pour tout le monde si le répertoire personnel de l’utilisateur est sur une partition NFS, car sshd le lit en tant que superutilisateur. De plus, ce fichier doit être la propriété de l’utilisateur et ne doit être accessible en écriture par personne d’autre. Les permissions recommandées pour la plupart des machines sont : accès en lecture/écriture pour l’utilisateur et aucun accès pour les autres.

˜/.shosts

Ce fichier est utilisé exactement de la même façon que .rhosts , mais il permet l’authentification basée sur la machine sans autoriser les connexions avec rlogin/rsh .

˜/.ssh/

Ce répertoire correspond à l’emplacement par défaut de toutes les informations de configuration et d’authentification spécifiques à l’utilisateur. Il n’est globalement pas nécessaire de garder secret l’ensemble du contenu de ce répertoire, mais les permissions recommandées sont lecture/écriture/exécution pour l’utilisateur et aucun accès pour les autres.

˜/.ssh/authorized_keys

Ce fichier liste les clés publiques (ECDSA, Ed25519, RSA) utilisables pour se connecter avec le compte de l’utilisateur. Son format est décrit plus haut. Son contenu n’est pas hautement sensible, mais les permissions recommandées sont : accès en lecture/écriture pour l’utilisateur et aucun accès pour les autres

Si ce fichier, le répertoire ˜/.ssh ou le répertoire personnel de l’utilisateur étaient accessible en écriture par les autres utilisateurs, ce fichier pourrait être modifié ou remplacé par des utilisateurs non autorisés. Dans ce cas, sshd n’autorisera pas son utilisation, à moins que l’option StrictModes n’ait été définie à « no ».

˜/.ssh/environment

Ce fichier (s’il existe) est lu dans l’environnement lors de la connexion. Il ne peut contenir que des lignes vides, des lignes de commentaires (qui commencent par le caractère « # ») et des lignes d’affectation de la forme nom=valeur. Le fichier ne doit être accessible en écriture que pour l’utilisateur ; il n’a pas besoin d’être accessible en lecture pour les autres. Le traitement de l’environnement est désactivé par défaut et contrôlé à l’aide de l’option PermitUserEnvironment .

˜/.ssh/known_hosts

Ce fichier contient une liste des clés d’hôte pour tous les hôtes auxquels l’utilisateur s’est connecté et qui ne sont pas encore dans la liste globale des clés d’hôte connues du système. Son format est décrit plus haut. Il ne doit être accessible en écriture que pour son propriétaire et le superutilisateur et peut, mais ce n’est pas nécessaire, être accessible en lecture pour les autres.

˜/.ssh/rc

Ce fichier contient des routines d’initialisation à exécuter avant que le répertoire personnel de l’utilisateur devienne accessible. Il ne doit être accessible en écriture que pour l’utilisateur et n’a pas besoin d’être accessible en lecture pour les autres.

/etc/hosts.allow
/etc/hosts.deny

Ces fichiers permettent de définir les contrôles d’accès qui peuvent être appliqués par tcp-wrappers. Pour plus d’informations, voir hosts_access (5).

/etc/hosts.equiv

Ce fichier est utilisé pour l’authentification basée sur la machine (voir ssh (1)). Il ne doit être accessible en écriture que pour le superutilisateur.

/etc/ssh/moduli

Ce fichier contient les groupes Diffie-Hellman utilisés pour la méthode d’échange de clés « Diffie-Hellman Group Exchange ». Son format est décrit dans moduli (5). Si aucun groupe utilisable n’est trouvé dans ce fichier, ce sont les groupes internes fixes qui seront utilisés.

/etc/motd

Voir motd (5).

/etc/nologin

Si ce fichier existe, sshd empêche quiconque de se connecter, à l’exception du superutilisateur. Le contenu de ce fichier est communiqué à quiconque essayant de se connecter et les connexions non-superutilisateur sont refusées. Ce fichier doit être accessible en lecture pour tout le monde.

/etc/ssh/shosts.equiv

Ce fichier est utilisé exactement de la même manière que hosts.equiv , mais il permet l’authentification basée sur la machine sans autoriser les connexions avec rlogin/rsh .

/etc/ssh/ssh_host_ecdsa_key
/etc/ssh/ssh_host_ed25519_key
/etc/ssh/ssh_host_rsa_key

Ces fichiers contiennent la partie privée des clés d’hôte. Ils ne doivent être la propriété que du superutilisateur, accessibles en lecture uniquement pour ce dernier et inaccessibles pour les autres. Notez que sshd ne démarrera pas si ces fichiers sont accessibles pour le groupe et/ou les autres.

/etc/ssh/ssh_host_ecdsa_key.pub
/etc/ssh/ssh_host_ed25519_key.pub
/etc/ssh/ssh_host_rsa_key.pub

Ces fichiers contiennent la partie publique des clés d’hôte. Ils doivent être accessibles en lecture pour tous, mais accessibles en écriture uniquement pour le superutilisateur. Leurs contenus doivent correspondre à leurs parties privées respectives. Ils ne sont pas vraiment utilisés pour pour une action quelconque ; ils sont fournis par commodité pour l’utilisateur qui peut les copier dans ses fichiers des hôtes connus. Ces fichiers sont créés en utilisant ssh-keygen (1).

/etc/ssh/ssh_known_hosts

Ce fichier contient la liste globale du système des clés d’hôte connues. Il doit être préparé par l’administrateur système de manière à contenir les clés d’hôte publiques de toutes les machines de l’organisation. Son format est décrit plus haut. Il doit être accessible en écriture pour le superutilisateur et le propriétaire et en lecture pour les autres.

/etc/ssh/sshd_config

Ce fichier contient les données de configuration pour sshd . Son format et les options de configuration sont décrits dans sshd_config (5).

/etc/ssh/sshrc

Identique à ˜/.ssh/rc , ce fichier permet de spécifier globalement des initialisations pour la connexion machine par machine. Ce fichier ne doit être accessible en écriture que pour le superutilisateur et en lecture pour les autres.

/run/sshd

Il s’agit du répertoire de chroot (2) utilisé par sshd lors de la séparation de privilèges dans la phase de pré-authentification. Le répertoire ne doit contenir aucun fichier, est la propriété du superutilisateur et ne doit pas être accessible en écriture pour le groupe ou les autres.

/run/sshd.pid

Ce fichier contient l’identifiant du processus (PID) du démon sshd en attente de connexions (si plusieurs démons sont en cours d’exécution sur plusieurs ports, ce fichier contient l’identifiant du dernier démon démarré). Le contenu de ce fichier n’est pas sensible et il peut être accessible en lecture pour tout le monde.

VOIR AUSSI

scp (1), sftp (1), ssh (1), ssh-add (1), ssh-agent (1), ssh-keygen (1), ssh-keyscan (1), chroot (2), hosts_access (5), moduli (5), sshd_config (5), inetd (8), sftp-server (8)

AUTEURS

OpenSSH est dérivé de la version 1.2.12 originale et libre de ssh par Tatu Ylonen. Aaron Campbell, Bob Beck, Markus Friedl, Niels Provos, Theo de Raadt et Dug Song ont corrigé de nombreux bogues, rajouté des nouvelles fonctionnalités et créé OpenSSH. Markus Friedl a contribué à la prise en charge des versions 1.5 et 2.0 du protocole SSH. Niels Provos et Markus Friedl ont contribué à la prise en charge de la séparation des privilèges.

TRADUCTION

La traduction française de cette page de manuel a été créée par Laurent GAUTROT <l dot gautrot at free dot fr> et Lucien Gentis <lucien.gentis@waika9.com>

Cette traduction est une documentation libre ; veuillez vous reporter à la GNU General Public License version 3 : https://www.gnu.org/licenses/gpl-3.0.html concernant les conditions de copie et de distribution. Il n’y a aucune RESPONSABILITÉ LÉGALE.

Si vous découvrez un bogue dans la traduction de cette page de manuel, veuillez envoyer un message à debian-l10n-french@lists.debian.org . Debian September 15, 2024 SSHD (8)

---