| SSHD(8) | System Manager's Manual | SSHD(8) |
sshd —
Démon d’OpenSSH
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] |
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 :
-4sshd à n’utiliser que des
adresses IPv4.-6sshd à n’utiliser que des
adresses IPv6.-C
spec_connexion-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_hotesshd 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.-Dsshd
ne se détachera pas du terminal et ne deviendra pas un
démon, ce qui permet de surveiller facilement
sshd.-d-d
spécifiées (au maximum 3).-E
fichier_journal-e-f
fich_configsshd
refusera de démarrer s'il n'y a pas de fichier de
configuration.-Gsshd 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-h
fich_clef_hotesshd 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.-isshd est
exécuté par inetd(8).-o
option-p
portPort 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-TMatch
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.-tsshd de
manière fiable, car des options de configuration peuvent
changer.-u
longueur-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.-VLe 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.
Lorsqu’un utilisateur se connecte avec succès,
sshd effectue les opérations
suivantes :
PermitUserEnvironment dans
sshd_config(5).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.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.
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 :
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-forwardingrestrict.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"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"PermitUserEnvironment permet
de contrôler le traitement de l’environnement, ce traitement
étant désactivé par défaut.expiry-time="spec_temps"from="liste_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-forwardingno-port-forwardingcommand.no-ptyno-user-rcno-X11-forwardingpermitlisten="[machine:]port"-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"-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-forwardingrestrict.principals="principals"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.ptyrestrict.no-touch-requiredecdsa-sk et
ed25519-sk.verify-requiredecdsa-sk et
ed25519-sk.restricttunnel="n"user-rcrestrict.X11-forwardingrestrict.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 ...
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...
PrintMotd et
PrintLastLog, respectivement, sont
activées. Il ne supprime pas l’affichage de la
bannière spécifiée par
Banner.
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.
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 ».
PermitUserEnvironment.
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.
sshd ne démarrera pas si ces fichiers sont
accessibles pour le groupe et/ou les autres.
sshd. Son format et les options de configuration
sont décrits dans sshd_config(5).
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.
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.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)
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.
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 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
| September 15, 2024 | Debian |