Provided by: manpages-fr_4.27.0-1_all 
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)