sshd — Démon OpenSSH
SYNTAXE
sshd [-46DdeGiqTtV] [-C connection_spec] [-c host_certificate_file] [-E log_file]
[-f config_file] [-g login_grace_time] [-h host_key_file] [-o option] [-p port] [-u len]
DESCRIPTION
sshd (Démon OpenSSH) est le programme démon pour ssh(1). Il fournit des communications chiffrées sécurisées entre deux hôtes non fiables sur un réseau non sécurisé.
sshd écoute les connexions des clients. Il est généralement démarré au démarrage du système à partir de /etc/init.d/ssh.
Il crée une nouvelle instance de démon pour chaque connexion entrante. Les instances de démon créées gèrent 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 de ligne de commande ou d’un fichier de configuration (par défaut
sshd_config(5) ; les options de ligne de commande ont priorité sur les valeurs spécifiées dans le fichier de configuration. sshd relit son fichier de configuration lorsqu’il reçoit un signal de raccrochage, SIGHUP, en s’exécutant avec le nom et les options avec lesquels il a été démarré, par exemple /usr/sbin/sshd.
Les options sont les suivantes :
-4 Force sshd à utiliser uniquement les adresses IPv4.
-6 Force sshd à utiliser uniquement les adresses IPv6.
-C connection_spec
Spécifie les paramètres de connexion à utiliser pour le mode de test étendu -T. Si cette option est fournie, les directives Match du fichier de configuration qui s’appliqueraient sont appliquées avant que la configuration ne soit écrite sur la sortie standard. Les paramètres de connexion sont fournis sous forme de paires clé=valeur et peuvent être fournis dans n’importe quel ordre, soit avec plusieurs options -C, soit sous forme de liste séparée par des virgules. Les mots-clés sont « addr », « user », « host », « laddr », « lport » et « rdomain » et correspondent respectivement à l’adresse source, à l’utilisateur, au nom d’hôte source résolu, à l’adresse locale, au numéro de port local et au domaine de routage. De plus, l’indicateur « invalid-user » (qui ne prend pas d’argument de valeur) peut être spécifié pour simuler une connexion à partir d’un nom d’utilisateur non reconnu.
-c host_certificate_file
Spécifie le chemin d’accès à un fichier de certificat pour identifier sshd pendant l’é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 Lorsque cette option est spécifiée, sshd ne se détache pas et ne devient pas un démon. Cela permet de surveiller facilement sshd.
-d Mode de débogage. Le serveur envoie une sortie de débogage détaillée à la sortie standard d’erreur et ne se lance pas en arrière-plan. Le serveur ne fera pas non plus de fork(2) et ne traitera qu’une seule connexion. Cette option est uniquement destinée au débogage du serveur. Plusieurs options -d augmentent le niveau de débogage. Le maximum est 3.
-E log_file
Ajoute les journaux de débogage au fichier log_file au lieu du journal système.
-e
Écrit les journaux de débogage sur la sortie d’erreur standard au lieu du journal système.
-f config_file
Spécifie le nom du fichier de configuration. Par défaut, il s’agit de /etc/ssh/sshd_config. sshd refuse de démarrer s’il n’y a pas de fichier de configuration.
-G
Analyse et affiche le fichier de configuration. Vérifie la validité du fichier de configuration, affiche la configuration effective sur la sortie standard, puis quitte. Facultativement, les règles Match peuvent être appliquées en spécifiant les paramètres de connexion à l’aide d’une ou plusieurs options -C.
-g login_grace_time
Définit le délai de grâce pour que les clients s’authentifient (par défaut : 120 secondes). Si le client ne parvient pas à authentifier l’utilisateur dans ce délai, le serveur se déconnecte et se ferme. Une valeur de zéro indique qu’il n’y a pas de limite.
-h host_key_file
Spécifie un fichier à partir duquel une clé d’hôte est lue. Cette option doit être fournie si sshd n’est pas exécuté en tant que root (car les fichiers de clé d’hôte normaux ne sont généralement accessibles qu’à root). La valeur par défaut est /etc/ssh/ssh_host_ecdsa_key, /etc/ssh/ssh_host_ed25519_key et /etc/ssh/ssh_host_rsa_key. Il est possible d’avoir plusieurs fichiers de clé d’hôte pour les différents algorithmes de clé d’hôte.
-i
Indique que sshd est exécuté à partir d’inetd(8).
-o option
Peut être utilisé pour fournir des options dans le format utilisé dans le fichier de configuration. Ceci est utile pour spécifier des options pour lesquelles il n’existe pas de drapeau en ligne de commande distinct. Pour plus de détails sur les options et leurs valeurs, consultez sshd_config(5).
-p port
Spécifie le port sur lequel le serveur écoute les connexions (par défaut : 22). Plusieurs options de port sont autorisées. Les ports spécifiés dans le fichier de configuration avec l’option Port sont ignorés lorsqu’un port en ligne de commande est spécifié. Les ports spécifiés à l’aide de l’option ListenAddress remplacent les ports en 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 enregistrés.
-T
Mode de test étendu. Vérifie la validité du fichier de configuration, affiche la configuration effective sur la sortie standard, puis quitte. Facultativement, les règles Match peuvent être appliquées en spécifiant les paramètres de connexion à l’aide d’une ou plusieurs options -C. Ceci est similaire au drapeau -G, mais il inclut les tests supplémentaires effectués par le drapeau -t.
-t
Mode de test. Vérifie uniquement la validité du fichier de configuration et la cohérence des clés. Ceci est utile pour mettre à jour sshd de manière fiable, car les options de configuration peuvent changer.
-u len
Cette option est utilisée pour spécifier la taille du champ dans la structure utmp qui contient le nom d’hôte distant. Si le nom d’hôte résolu est plus long que len, la valeur décimale pointée sera utilisée à la place. Cela permet aux hôtes avec des noms d’hôte très longs qui dépassent ce champ d’être toujours identifiés de manière unique. La spécification de -u0 indique que seules les adresses décimales pointées doivent être placées dans le fichier utmp. -u0 peut également être utilisé pour empêcher sshd d’effectuer des requêtes DNS, sauf si le mécanisme d’authentification ou la configuration l’exige. Les mécanismes d’authentification qui peuvent nécessiter DNS incluent HostbasedAuthentication et l’utilisation d’une option from="pattern-list" dans un fichier de clé. Les options de configuration qui nécessitent DNS incluent l’utilisation d’un modèle USER@HOST dans AllowUsers ou DenyUsers.
-V Affiche le numéro de version et quitte.
AUTHENTIFICATION
Le démon SSH d’OpenSSH prend en charge uniquement le protocole SSH 2. Chaque hôte possède une clé spécifique, utilisée pour l’identifier. Chaque fois qu’un client se connecte, le démon répond avec sa clé publique. Le client compare la clé de l’hôte à sa propre base de données pour vérifier qu’elle n’a pas été modifiée.
La confidentialité est assurée par un accord de clé Diffie-Hellman. Cet accord de clé donne lieu à une clé de session partagée. Le reste de la session est chiffré à l’aide d’un chiffrement symétrique. Le client sélectionne l’algorithme de chiffrement à utiliser parmi ceux proposés par le serveur. De plus, l’intégrité de la session est assurée par un code d’authentification de message cryptographique (MAC).
Enfin, le serveur et le client entrent dans un dialogue d’authentification. Le client tente de s’authentifier à l’aide de l’authentification basée sur l’hôte, de l’authentification par clé publique, de l’authentification par défi-réponse ou de l’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é, figurant dans DenyUsers ou si son groupe figure dans DenyGroups. La définition d’un compte verrouillé dépend du système. Certaines plateformes disposent de leur propre base de données de comptes (par exemple, AIX) et d’autres modifient le champ passwd (« *LK* » sur Solaris et UnixWare, « * » sur HP-UX, contenant « Nologin » sur Tru64, un préfixe « *LOCKED* » sur FreeBSD et un préfixe « ! » sur la plupart des systèmes Linux). S’il est nécessaire de désactiver l’authentification par mot de passe pour le compte tout en autorisant toujours l’authentification par clé publique, le champ passwd doit être défini sur une autre valeur (par exemple, « NP » ou « *NP* »).
Si le client s’authentifie avec succès, un dialogue de préparation de la session est lancé. À ce moment-là, le client peut demander des choses telles que l’allocation d’un pseudo-terminal, le transfert de connexions X11, le transfert de connexions TCP ou le transfert de la connexion de l’agent d’authentification sur le canal sécurisé.
Après cela, le client demande soit un shell interactif, soit l’exécution d’une commande non interactive, que sshd exécutera via le shell de l’utilisateur à l’aide de son option -c. Les deux parties entrent ensuite en mode session. Dans ce mode, l’une ou l’autre des parties peut envoyer des données à tout moment, et ces données sont transmises au shell ou à la commande côté serveur, et au terminal utilisateur côté client.
Lorsque le programme utilisateur se termine et que toutes les connexions X11 et autres transférées sont fermées, le serveur envoie le statut de sortie de la commande au client, et les deux parties se terminent.
PROCESSUS DE CONNEXION
Lorsqu'un utilisateur se connecte avec succès, sshd effectue les opérations suivantes :
Si la connexion se fait sur un tty et qu'aucune commande n'a été spécifiée, affiche l'heure de la dernière connexion et le contenu de /etc/motd (sauf si cela est empêché dans le fichier de configuration ou par ~/.hushlogin ; voir la section « FICHIERS »).
Si la connexion se fait sur un tty, enregistre l'heure de la connexion.
Vérifie l'existence de /etc/nologin ; si le fichier existe, affiche son contenu et quitte (sauf pour l'utilisateur root).
Passe à l'exécution avec les privilèges utilisateur normaux.
Configure l'environnement de base.
Lit le fichier ~/.ssh/environment, s'il existe, et si les utilisateurs sont autorisés à modifier leur environnement. Voir l'option PermitUserEnvironment dans sshd_config(5).
Passe au répertoire personnel de l'utilisateur.
Si le fichier ~/.ssh/rc existe et que l'option PermitUserRC dans sshd_config(5) est définie, exécute ce fichier ; sinon, si le fichier /etc/ssh/sshrc existe, exécute ce dernier ; sinon, exécute [xauth]({filename}../../xauth)(1). Les fichiers « rc » reçoivent le protocole et le cookie d'authentification X11 en entrée standard. Voir la section « SSHRC » ci-dessous.
Exécute le shell ou la commande de l'utilisateur. Toutes les commandes sont exécutées sous le shell de connexion de l'utilisateur, tel que spécifié dans la base de données système des mots de passe.
SSHRC
Si le fichier ~/.ssh/rc existe, sh(1) l'exécute après avoir lu les fichiers d'environnement, mais avant de démarrer le shell ou la commande de l'utilisateur. Il ne doit produire aucune sortie sur stdout ; stderr doit être utilisé à la place. Si le transfert X11 est utilisé, il recevra la paire « proto cookie » en entrée standard (et DISPLAY dans son environnement). Le script doit appeler xauth(1) car sshd n'exécutera pas automatiquement xauth pour ajouter les cookies X11.
L'objectif principal de ce fichier est d'exécuter toutes les routines d'initialisation qui peuvent être nécessaires avant que le répertoire personnel de l'utilisateur ne devienne accessible ; AFS est un exemple particulier de cet environnement.
Ce fichier contiendra probablement un certain code d'initialisation, suivi de quelque chose de 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é, et si ce dernier n'existe pas non plus, xauth est utilisé pour ajouter le cookie.
FORMAT DU FICHIER AUTHORIZED_KEYS
AuthorizedKeysFile spécifie les fichiers contenant les clés publiques pour l'authentification par clé publique ; si cette option n'est pas spécifiée, la valeur par défaut est ~/.ssh/authorized_keys et ~/.ssh/authorized_keys2. Chaque ligne du fichier contient une clé (les lignes vides et les lignes commençant par un « # » sont ignorées en tant que commentaires). Les clés publiques sont composées des champs suivants, séparés par des espaces : options, type de clé, clé encodée en base64, commentaire. Le champ des options est facultatif. Les types de clés pris en charge sont :
_
ecdsa-sha2-nistp256
ecdsa-sha2-nistp384
ecdsa-sha2-nistp521
_
ssh-ed25519
ssh-rsa
Le champ de commentaire n'est utilisé à aucune fin (mais peut être pratique pour l'utilisateur afin d'identifier la clé).
Notez que les lignes de ce fichier peuvent comporter plusieurs centaines d'octets (en raison de la taille de l'encodage de la clé publique), jusqu'à une limite de 8 kilooctets, ce qui permet d'utiliser des clés RSA allant jusqu'à 16 kilobits. Vous ne voudrez pas les taper ; copiez plutôt les fichiers id_ecdsa.pub, id_ecdsa_sk.pub, id_ed25519.pub, id_ed25519_sk.pub ou id_rsa.pub et modifiez-les.
sshd applique une taille minimale de module de clé RSA de 1024 bits.
Les options (si elles sont présentes) consistent en des spécifications d'options séparées par des virgules. Aucun espace n'est autorisé, à l'exception de ceux situés entre guillemets. Les spécifications d'options suivantes sont prises en charge (notez que les mots-clés d'option ne respectent pas la casse) :
agent-forwarding
Active le transfert d'agent d'authentification précédemment désactivé par l'option restrict.
cert-authority
Indique que la clé répertoriée est une autorité de certification (AC) à laquelle il faut faire confiance pour valider les certificats signés pour l'authentification des utilisateurs.
Les certificats peuvent encoder des restrictions d'accès similaires à ces options de clé. Si à la fois les restrictions de certificat et les options de clé sont présentes, l'union la plus restrictive des deux est appliquée.
command="commande"
Indique que la commande est exécutée chaque fois que cette clé est utilisée pour l'authentification. La commande fournie par l'utilisateur (le cas échéant) 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 sans pseudo-terminal. Si un canal propre à 8 bits est requis, il ne faut pas demander de pseudo-terminal ou il faut spécifier no-pty. Une citation peut être incluse dans la commande en l'échappant avec une barre oblique inversée.
Cette option peut être utile pour restreindre certaines clés publiques à effectuer une opération spécifique. Un exemple pourrait être une clé qui permet des sauvegardes à distance, mais rien d'autre. Notez que le client peut spécifier le transfert TCP et/ou X11, à moins qu'ils ne soient explicitement interdits, par exemple en utilisant l'option de clé restrict.
La commande initialement fournie par le client est disponible dans la variable d'environnement SSH_ORIGINAL_COMMAND. Notez que cette option s'applique à l'exécution de shell, de commandes ou de sous-systèmes. Notez également que cette commande peut être remplacée par une directive ForceCommand dans sshd_config(5).
Si une commande est spécifiée et qu'une commande forcée est intégrée dans un certificat utilisé pour l'authentification, le certificat n'est accepté que si les deux commandes sont identiques.
environment="NOM=valeur"
Indique que la chaîne doit être ajoutée à l'environnement lors de la connexion à l'aide de cette clé. Les variables d'environnement définies de cette manière remplacent les autres valeurs d'environnement par défaut. Plusieurs options de ce type sont autorisées. Le traitement de l'environnement est désactivé par défaut et est contrôlé via l'option PermitUserEnvironment.
expiry-time="time"
Indique une heure après laquelle la clé ne sera plus acceptée. L'heure peut être spécifiée sous la forme d'une date YYYYMMDD[Z] ou d'une heure YYYYMMDDHHMM[SS][Z]. Les dates et les heures seront interprétées dans le fuseau horaire du système, à moins qu'elles ne soient suivies du caractère Z, auquel cas elles seront interprétées dans le fuseau horaire UTC.
from="liste de motifs"
Spécifie qu'en plus de l'authentification par clé publique, soit le nom canonique de l'hôte distant, soit son adresse IP, doivent être présents dans la liste de motifs séparés par des virgules.
Consultez la section PATTERNS dans ssh_config(5) pour plus d'informations sur les motifs.
En plus de la correspondance par caractères génériques qui peut être appliquée aux noms d'hôte ou aux adresses, une section « from » peut faire correspondre les adresses IP à l'aide de la notation CIDR adresse/masque.
L'objectif de cette option est d'accroître la sécurité de manière facultative : l'authentification par clé publique seule ne fait confiance à aucun élément du réseau, des serveurs de noms ou autre (sauf à la clé) ; cependant, si quelqu'un parvient à voler la clé, cette clé permet à un intrus de se connecter depuis n'importe où dans le monde. Cette option supplémentaire rend l'utilisation d'une clé volée plus difficile (les serveurs de noms et/ou les routeurs devraient également être compromis, en plus de la clé).
no-agent-forwarding
Interdit le transfert d'agent d'authentification lorsque cette clé est utilisée pour l'authentification.
no-port-forwarding
Interdit le transfert TCP lorsque cette clé est utilisée pour l'authentification. Toute demande de transfert de port du client renverra une erreur. Cela peut être utilisé, par exemple, en association avec l'option « command ».
no-pty
Empêche l'allocation d'un pseudo-terminal (une demande d'allocation d'un pseudo-terminal échouera).
no-user-rc
Désactive l'exécution de « ~/.ssh/rc ».
no-X11-forwarding
Interdit le transfert X11 lorsque cette clé est utilisée pour l'authentification. Toute demande de transfert X11 du client renverra une erreur.
permitlisten="[hôte:]port"
Limite le transfert de port distant avec l'option [ssh]({filename}../../ssh)(1) -R, de sorte qu'il ne puisse écouter que sur l'hôte (facultatif) et le port spécifiés. Les adresses IPv6 peuvent être spécifiées en encadrant l'adresse entre crochets. Plusieurs options « permitlisten » peuvent être appliquées, séparées par des virgules. Les noms d'hôte peuvent inclure des caractères génériques, comme décrit dans la section PATTERNS de ssh_config(5). Une spécification de port de « * » correspond à n'importe quel port. Notez que le paramètre de « GatewayPorts » peut restreindre davantage les adresses d'écoute. Notez que [ssh]({filename}../../ssh)(1) enverra un nom d'hôte de « localhost » si aucun hôte d'écoute n'a été spécifié lorsque le transfert a été demandé, et que ce nom est traité différemment des adresses « localhost » explicites « 127.0.0.1 » et « ::1 ».
permitopen="hôte:port"
Limite le transfert de port local avec l'option [ssh]({filename}../../ssh)(1) -L, de sorte qu'il ne puisse se connecter qu'à l'hôte et au port spécifiés. Les adresses IPv6 peuvent être spécifiées en encadrant l'adresse entre crochets. Plusieurs options « permitopen » peuvent être appliquées, séparées par des virgules. Aucun appariement de motifs ou recherche de noms n'est effectué sur les noms d'hôte spécifiés ; ils doivent être des noms d'hôte et/ou des adresses littéraux. Une spécification de port de « * » correspond à n'importe quel port.
port-forwarding
Active le transfert de port précédemment désactivé par l'option « restrict ».
principals="principals"
Sur une ligne d’autorité de certification, spécifie les principaux autorisés pour l’authentification par certificat sous forme de liste séparée par des virgules. Au moins un nom de la liste doit figurer dans la liste des principaux du certificat pour que le certificat soit accepté. Cette option est ignorée pour les clés qui ne sont pas marquées comme signataires de certificats de confiance à l’aide de l’option cert-authority.
pty Permet l’allocation de tty précédemment désactivée par l’option restrict.
no-touch-required
N’exige pas de preuve de présence de l’utilisateur pour les signatures effectuées à l’aide de cette clé. Cette option n’a de sens que pour les algorithmes d’authentificateur FIDO ecdsa-sk et ed25519-sk.
verify-required
Exige que les signatures effectuées à l’aide de cette clé attestent qu’elles ont vérifié l’utilisateur, par exemple via un code PIN. Cette option n’a de sens que pour les algorithmes d’authentificateur FIDO ecdsa-sk et ed25519-sk.
restrict
Active toutes les restrictions, c’est-à-dire désactive le transfert de port, d’agent et X11, ainsi que la désactivation de l’allocation de PTY et de l’exécution de ~/.ssh/rc. Si d’autres fonctionnalités de restriction sont ajoutées aux fichiers authorized_keys à l’avenir, elles seront incluses dans cet ensemble.
tunnel="n"
Force l’utilisation d’un périphérique tun(4) sur le serveur. Sans cette option, le périphérique disponible suivant sera utilisé si le client demande un tunnel.
user-rc
Active l’exécution de ~/.ssh/rc précédemment désactivée par l’option restrict.
X11-forwarding
Permet le transfert X11 précédemment désactivé par l’option restrict.
Un exemple de fichier authorized_keys :
# Les commentaires sont autorisés au début de la ligne. Les lignes vides sont autorisées.
# Clé simple, sans restrictions
ssh-rsa ...
# Commande forcée, désactive PTY et tout transfert
restrict,command="dump /home" ssh-rsa ...
# Restriction des destinations du transfert ssh -L
permitopen="192.0.2.1:80",permitopen="192.0.2.2:25" ssh-rsa ...
# Restriction des écouteurs du transfert ssh -R
permitlisten="localhost:8080",permitlisten="[::1]:22000" ssh-rsa ...
# Configuration pour le transfert de tunnel
tunnel="0",command="sh /etc/netstart tun0" ssh-rsa ...
# Annulation de la restriction pour autoriser l’allocation de PTY
restrict,pty,command="nethack" ssh-rsa ...
# Autoriser la clé FIDO sans exiger de contact
no-touch-required _ ...
# Exiger une vérification de l’utilisateur (par exemple, un code PIN ou une donnée biométrique) pour la clé FIDO
verify-required _ ...
# Faire confiance à la clé de l’autorité de certification, autoriser l’absence de contact FIDO si cela est demandé 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), et le fichier par utilisateur est maintenu automatiquement : chaque fois que l’utilisateur se connecte à un hôte inconnu, sa clé est ajoutée au fichier par utilisateur.
Chaque ligne de ces fichiers contient les champs suivants : marqueur (facultatif), noms d’hôtes, 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 l’un des suivants : « @cert-authority », pour indiquer que la ligne contient une clé d’autorité de certification (CA), ou « @revoked », pour indiquer que la clé contenue dans la ligne est révoquée et ne doit jamais être acceptée. Un seul marqueur doit être utilisé par ligne.
Hostnames est une liste de motifs séparés par des virgules (« * » et « ? » agissent comme des caractères génériques) ; chaque motif est à son tour mis en correspondance avec le nom d’hôte. Lorsque sshd authentifie un client, par exemple lors de l’utilisation de HostbasedAuthentication, il s’agira du nom d’hôte canonique du client. Lorsque ssh(1) authentifie un serveur, il s’agira du nom d’hôte fourni par l’utilisateur, de la valeur de ssh(1) HostkeyAlias s’il a été spécifié, ou du nom d’hôte canonique du serveur si l’option ssh(1) CanonicalizeHostname a été utilisée.
Un motif peut également être précédé de « ! » pour indiquer une négation : si le nom d’hôte correspond à un motif nié, il n’est pas accepté (par cette ligne), même s’il correspond à un autre motif sur la ligne. Un nom d’hôte ou une adresse peut éventuellement être encadré entre crochets « [ » et « ] », puis suivi de « : » et d’un numéro de port non standard.
Alternativement, les noms d’hôte peuvent être stockés sous forme hachée, ce qui masque les noms d’hôte et les adresses si le contenu du fichier est divulgué. Les noms d’hôte hachés commencent par le caractère « | ». Seul un nom d’hôte haché peut apparaître sur une seule ligne, et aucun des opérateurs de négation ou de caractère générique ci-dessus ne peut être appliqué.
Le type de clé et la clé encodée en base64 sont extraits directement de la clé hôte ; ils peuvent être obtenus, par exemple, à partir de /etc/ssh/ssh_host_rsa_key.pub. Le champ de commentaire facultatif se poursuit jusqu’à la fin de la ligne et n’est pas utilisé.
Les lignes commençant par « # » et les lignes vides sont ignorées en tant que commentaires.
Lors de l’exécution de l’authentification d’hôte, l’authentification est acceptée si une ligne correspondante contient la clé appropriée ; soit une 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 qu’une clé soit considérée comme une autorité de certification, elle doit utiliser le marqueur « @cert-authority » décrit ci-dessus.
Le fichier des hôtes connus fournit également un moyen de marquer les clés comme révoquées, par exemple lorsque l’on sait que la clé privée associée a été volée. Les clés révoquées sont spécifiées en incluant le marqueur « @revoked » au début de la ligne de clé, et ne sont jamais acceptées pour l’authentification ou en tant qu’autorités de certification, mais produiront plutôt un avertissement de ssh(1) lorsqu’elles sont rencontrées.
Il est possible (mais non recommandé) d’avoir plusieurs lignes ou différentes clés d’hôte pour les mêmes noms. Cela se produit inévitablement lorsque des formes courtes de noms d’hôte de différents domaines sont placées dans le fichier. Il est possible que les fichiers contiennent des informations contradictoires ; l’authentification est acceptée si des informations valides peuvent être trouvées dans l’un ou l’autre des fichiers.
Notez que les lignes de ces fichiers sont généralement très longues (plusieurs centaines de caractères), et vous ne voudrez certainement pas saisir les clés d’hôte à la main. Il est préférable de les générer à l’aide d’un script, de la commande ssh-keyscan(1), ou en prenant, par exemple, le fichier /etc/ssh/ssh_host_rsa_key.pub et en ajoutant les noms d’hôte au début. La commande ssh-keygen(1) propose également quelques options d’édition automatisées pour ~/.ssh/known_hosts, notamment la suppression des hôtes correspondant à un nom d’hôte et 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 au début de la 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é d’autorité de certification, acceptée pour tous les hôtes de *.mydomain.com ou *.mydomain.org
@cert-authority *.mydomain.org,*.mydomain.com ssh-rsa AAAAB5W...
FICHIERS
~/.hushlogin
Ce fichier est utilisé pour supprimer l’affichage de l’heure de la dernière connexion et du fichier /etc/motd, si les options PrintLastLog et PrintMotd sont activées, respectivement. Il ne supprime pas l’affichage du message spécifié par Banner.
~/.rhosts
Ce fichier est utilisé pour l’authentification basée sur l’hôte (voir [ssh]({filename}../../ssh)(1) pour plus d’informations). Sur certains systèmes, ce fichier peut avoir besoin d’être lisible par tous si le répertoire personnel de l’utilisateur se trouve sur une partition NFS, car sshd le lit en tant que root. De plus, ce fichier doit être la propriété de l’utilisateur et ne doit pas avoir de permissions d’écriture pour les autres. La permission recommandée pour la plupart des systèmes est lecture/écriture pour l’utilisateur, et inaccessible aux autres.
~/.shosts
Ce fichier est utilisé exactement de la même manière que .rhosts, mais permet l’authentification basée sur l’hôte sans autoriser la connexion avec rlogin/rsh.
~/.ssh/
Ce répertoire est l’emplacement par défaut pour toutes les configurations et informations d’authentification spécifiques à l’utilisateur. Il n’y a pas d’exigence générale pour que tout le contenu de ce répertoire soit secret, mais les permissions recommandées sont lecture/écriture/exécution pour l’utilisateur, et inaccessible aux autres.
~/.ssh/authorized_keys
Liste les clés publiques (ECDSA, Ed25519, RSA) qui peuvent être utilisées pour se connecter en tant que cet utilisateur. Le format de ce fichier est décrit ci-dessus. Le contenu du fichier n’est pas très sensible, mais les permissions recommandées sont lecture/écriture pour l’utilisateur, et inaccessible aux autres.
Si ce fichier, le répertoire ~/.ssh ou le répertoire personnel de l’utilisateur sont accessibles en écriture par d’autres utilisateurs, alors le fichier pourrait être modifié ou remplacé par des utilisateurs non autorisés. Dans ce cas, sshd ne permettra pas son utilisation, sauf si l’option StrictModes a été définie sur « no ».
~/.ssh/environment
Ce fichier est lu dans l’environnement lors de la connexion (s’il existe). Il ne peut contenir que des lignes vides, des lignes de commentaires (qui commencent par « # ») et des lignes d’affectation de la forme nom=valeur. Le fichier ne doit être accessible en écriture que par l’utilisateur ; il n’est pas nécessaire qu’il soit lisible par qui que ce soit. Le traitement de l’environnement est désactivé par défaut et est contrôlé via l’option PermitUserEnvironment.
~/.ssh/known_hosts
Contient une liste des clés d’hôte pour tous les hôtes sur lesquels l’utilisateur s’est connecté, et qui ne figurent pas déjà dans la liste des clés d’hôte connues au niveau du système. Le format de ce fichier est décrit ci-dessus. Ce fichier ne doit être accessible en écriture qu’à l’utilisateur root/au propriétaire et peut, mais n’est pas obligé d’être, accessible en lecture par tous.
~/.ssh/rc
Contient des routines d’initialisation à exécuter avant que le répertoire personnel de l’utilisateur ne devienne accessible. Ce fichier ne doit être accessible en écriture que par l’utilisateur, et n’est pas obligé d’être accessible en lecture par qui que ce soit.
/etc/hosts.allow
/etc/hosts.deny
Les contrôles d’accès qui doivent être appliqués par tcp-wrappers sont définis ici. Pour plus de détails, voir hosts_access(5).
/etc/hosts.equiv
Ce fichier est destiné à l’authentification basée sur l’hôte (voir ssh(1)). Il ne doit être accessible en écriture qu’à l’utilisateur root.
/etc/ssh/moduli
Contient les groupes Diffie-Hellman utilisés pour la méthode d’échange de clés « Diffie-Hellman Group Exchange ». Le format du fichier est décrit dans moduli(5). Si aucun groupe utilisable n’est trouvé dans ce fichier, des groupes internes fixes seront utilisés.
/etc/motd
Voir motd(5).
/etc/nologin
Si ce fichier existe, sshd refuse de laisser quiconque, sauf root, se connecter. Le contenu du fichier est affiché à toute personne qui tente de se connecter, et les connexions non root sont refusées. Le fichier doit être accessible en lecture par tous.
/etc/ssh/shosts.equiv
Ce fichier est utilisé exactement de la même manière que hosts.equiv, mais permet l’authentification basée sur l’hôte sans permettre la connexion avec rlogin/rsh.
/etc/ssh/ssh_host_ecdsa_key
/etc/ssh/ssh_host_ed25519_key
/etc/ssh/ssh_host_rsa_key
Ces fichiers contiennent les parties privées des clés d’hôte. Ces fichiers ne doivent être possédés que par root, accessibles en lecture uniquement par root, et ne doivent pas être accessibles aux autres. Notez que sshd ne démarre pas si ces fichiers sont accessibles en groupe/lecture par tous.
/etc/ssh/ssh_host_ecdsa_key.pub
/etc/ssh/ssh_host_ed25519_key.pub
/etc/ssh/ssh_host_rsa_key.pub
Ces fichiers contiennent les parties publiques des clés d’hôte. Ces fichiers doivent être accessibles en lecture par tous, mais accessibles en écriture uniquement par root. Leur contenu doit correspondre aux parties privées respectives. Ces fichiers ne sont pas réellement utilisés à des fins spécifiques ; ils sont fournis pour le confort de l’utilisateur afin que leur contenu puisse être copié dans les fichiers known_hosts. Ces fichiers sont créés à l’aide de ssh-keygen(1).
/etc/ssh/ssh_known_hosts
Liste des clés d’hôte connues au niveau du système. Ce fichier doit être préparé par l’administrateur système pour contenir les clés d’hôte publiques de toutes les machines de l’organisation. Le format de ce fichier est décrit ci-dessus. Ce fichier ne doit être accessible en écriture qu’à l’utilisateur root/au propriétaire et doit être accessible en lecture par tous.
/etc/ssh/sshd_config
Contient les données de configuration pour sshd. Le format du fichier et les options de configuration sont décrits dans sshd_config(5).
/etc/ssh/sshrc
Semblable à ~/.ssh/rc, il peut être utilisé pour spécifier des initialisations globales spécifiques à la machine au moment de la connexion. Ce fichier ne doit être accessible en écriture qu’à l’utilisateur root, et doit être accessible en lecture par tous.
/run/sshd
Répertoire utilisé par sshd pour la séparation de privilèges durant la phase de pré-authentification. Ce répertoire ne doit pas contenir de fichiers et doit être la propriété de root, et ne doit pas être accessible en écriture par le groupe ou les autres utilisateurs.
/run/sshd.pid
Contient l’ID de processus du démon sshd qui écoute les connexions (s’il existe plusieurs démons en cours d’exécution simultanément pour différents ports, ce fichier contient l’ID de processus du dernier démarré). Le contenu de ce fichier n’est pas sensible ; il peut être accessible en lecture par tous.
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 une version dérivée de la version originale et gratuite de ssh 1.2.12 par Tatu Ylonen. Aaron Campbell, Bob Beck, Markus Friedl, Niels Provos, Theo de Raadt et Dug Song ont corrigé de nombreux bugs, réintroduit de nouvelles fonctionnalités et créé OpenSSH. Markus Friedl a contribué au support des versions 1.5 et 2.0 du protocole SSH. Niels Provos et Markus Friedl ont contribué au support de la séparation de privilèges.