SSHD(8) System Manager's Manual SSHD(8) NOM sshd - Demon 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 demon d'OpenSSH) est le programme demon pour ssh(1). Il permet des communications securisees et chiffrees entre deux machines considerees comme non fiables, et ce sur un reseau non securise. sshd attend les demandes de connexion en provenance des clients. Il est normalement demarre a l'amorcage de la machine (boot) depuis /etc/rc. Il cree un nouveau demon en se clonant a l'aide d'un << fork >> a chaque connexion entrante. Les demons clones prennent en charge l'echange de cles, le chiffrement, l'authentification, l'execution de commandes et l'echange de donnees. sshd peut etre configure a l'aide d'options sur la ligne de commande ou d'un fichier de configuration (par defaut sshd_config(5)) ; les options sur la ligne de commande l'emportent sur les valeurs specifiees dans le fichier de configuration. sshd relit son fichier de configuration quand il recoit le signal de raccrochage SIGHUP en s'executant lui-meme avec le nom et les options avec lesquels il a ete demarre, par exemple /usr/sbin/sshd. Les options sont les suivantes : -4 Forcer sshd a n'utiliser que des adresses IPv4. -6 Forcer sshd a n'utiliser que des adresses IPv6. -C spec_connexion Cette option permet de specifier les parametres de connexion a utiliser pour le mode de test etendu -T. Si elle est definie, toute directive Match du fichier de configuration qui s'appliquerait est executee avant que la configuration ne soit affichee sur la sortie standard. Les parametres de connexion sont specifies sous forme de paires mot-cle=valeur dans un ordre quelconque, soit a l'aide de plusieurs options -C, soit sous la forme d'une liste de paires mot-cle=valeur separees par des virgules. Les mots-cles sont << addr >>, << user >>, << host >>, << laddr >>, << port >> et << rdomain >> et correspondent respectivement a l'adresse source, l'utilisateur, le nom resolu de l'hote source, l'adresse locale, le numero de port local et le domaine de routage. De plus, le drapeau "invalid-user" (qui ne prend pas d'argument de valeur) peut etre specifier pour simuler une connexion a partir d'un nom d'utilisateur non reconnu. -c fich_certificat_hote Cette option permet de specifier le chemin d'un fichier de certificat pour identifier sshd lors d'un echange de cles. Le fichier de certificat doit correspondre a un fichier de cle d'hote specifie a l'aide de l'option -h ou de la directive de configuration HostKey. -D Si cette option est specifiee, sshd ne se detachera pas du terminal et ne deviendra pas un demon, ce qui permet de surveiller facilement sshd. -d Mode de debogage. Le serveur envoie une sortie de debogage prolixe sur la sortie d'erreur standard et ne se place pas lui- meme a l'arriere-plan. En outre, le serveur n'execute pas de fork(2) et ne traite qu'une connexion. Cette option n'est utilisee que pour le debogage du serveur. Le niveau de debogage augmente avec le nombre d'options -d specifiees (au maximum 3). -E fichier_journal Si cette option est definie, les messages de journalisation de debogage sont enregistres dans log_file au lieu du journal systeme. -e Cette option permet d'envoyer les messages de journalisation de debogage sur la sortie d'erreur standard au lieu du journal systeme. -f fich_config Cette option permet de specifier le nom du fichier de configuration. Le fichier par defaut est /etc/ssh/sshd_config. sshd refusera de demarrer 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 verifie la validite du fichier de configuration, affiche la configuration effective sur la sortie standard et quitte. Les regles Match peuvent s'appliquer en specifiant les parametres de connexion a l'aide d'une ou plusieurs options -C. -g delai_grace_connexion Cette option permet d'accorder un delai de grace aux clients pour s'authentifier (par defaut 120 secondes). Si le client ne parvient pas a authentifier l'utilisateur avant ce delai, le serveur se deconnecte et quitte. Une valeur de 0 indique qu'il n'y a pas de limite. -h fich_clef_hote Cette option permet de specifier un fichier a partir duquel la cle d'hote sera lue. Cette option doit etre utilisee si sshd n'est pas execute par le superutilisateur, car les fichiers de cle d'hote normaux ne sont en general accessibles en lecture que par le superutilisateur. Les fichiers par defaut sont /etc/ssh/ssh_host_ecdsa_key, /etc/ssh/ssh_host_ed25519_key et /etc/ssh/ssh_host_rsa_key. Il est possible de specifier plusieurs fichiers de cle d'hote pour les differents algorithmes de cle d'hote. -i Cette option permet d'indiquer que sshd est execute par inetd(8). -o option Cette option permet de specifier des options au format du fichier de configuration. Elle permet de specifier des options qui n'ont pas d'equivalent en ligne de commande. Pour des details complets a propos des options et de leurs valeurs, voir sshd_config(5). -p port Cette option permet de specifier le port sur lequel le serveur ecoute les connexions entrantes (par defaut 22). On peut specifier plusieurs options de port. Les ports specifies dans le fichier de configuration avec l'option Port sont ignores quand un port est passe en option sur la ligne de commande. Les ports specifies en utilisant l'option ListenAddress l'emportent sur ceux specifies sur la ligne de commande. -q Mode silencieux. Rien n'est envoye au journal systeme. Normalement, le debut, l'authentification et la fin de chaque connexion sont journalises. -T Mode de test etendu. Ce mode verifie la validite du fichier de configuration, affiche la configuration effective sur la sortie standard et quitte. Les regles Match peuvent eventuellement s'appliquer en specifiant des parametres de connexion a l'aide d'une ou plusieurs options -C. Identique au drapeau -G, il inclut en plus les tests effectues par le drapeau -t. -t Mode de test. Ce mode verifie uniquement la validite du fichier de configuration et des cles. Il s'avere utile pour mettre a jour sshd de maniere fiable, car des options de configuration peuvent changer. -u longueur Cette option permet de specifier la taille du champ de la structure utmp qui contient le nom de la machine distante. Si le nom de la machine apres resolution est plus long que longueur, c'est la valeur decimale contenant des points de l'adresse qui sera utilisee a la place. Cela permet d'identifier de maniere unique les machines avec des noms tres longs, meme si ces derniers depassent la capacite de ce champ. Specifier -u0 impose que seules les adresses en valeurs decimales contenant des points seront enregistrees dans le fichier utmp. -u0 permet aussi d'empecher sshd de faire des requetes DNS, a moins que le mecanisme d'authentification ou la configuration le necessite. Les mecanismes d'authentification qui peuvent necessiter des requetes DNS comprennent HostbasedAuthentication et l'utilisation d'une option from="liste_motifs" dans un fichier de cle. Les options de configuration qui necessitent une requete DNS comprennent l'utilisation d'un motif UTILISATEUR@HOTE dans les options AllowUsers ou DenyUsers. -V Affiche le numero de version et quitte. AUTHENTIFICATION Le demon SSH d'OpenSSH ne prend en charge que la version 2 du protocole SSH. Pour s'identifier, chaque hote possede une cle specifique aux hotes. Chaque fois qu'un client se connecte, le demon repond avec sa cle d'hote publique. Le client compare cette cle avec sa propre base de donnees pour verifier qu'elle n'a pas change. La securite des transmissions est mise en oeuvre au moyen d'un echange de cles Diffie-Hellman. Cet echange de cles resulte en une cle de session partagee. Le reste de la session est chiffre en utilisant un algorithme de chiffrement symetrique. Le client selectionne l'algorithme de chiffrement a utiliser parmi ceux que propose le serveur. En outre, l'integrite de la session est assuree a 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 basee sur la machine, une authentification par cle publique, une authentification par questions-reponses ou une authentification par mot de passe. Quel que soit le type d'authentification, le compte est verifie pour s'assurer qu'il est accessible. Un compte n'est pas accessible s'il est verrouille, s'il fait partie de la liste DenyUsers ou si son groupe fait partie de la liste DenyGroups . La definition d'un compte verrouille depend du systeme. Certaines plateformes possedent leur propre base de donnees 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 debut sur FreeBSD et un << ! >> au debut sur la plupart des Linux). S'il faut desactiver l'authentification par mot de passe pour un compte tout en autorisant l'authentification par cle publique, le champ mot de passe doit etre defini a une valeur differente de celles ci-dessus (par exemple << NP >> ou << *NP* >>). Si le client s'authentifie avec succes, un dialogue est entame pour preparer la session. A 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 securise. Ensuite, le client demandera un interpreteur de commande interactif ou l'execution d'une commande non interactive que sshd executera a l'aide de l'interpreteur de commande de l'utilisateur en utilisant son option -c. Les deux extremites entrent alors en mode session. Dans ce mode, les deux extremites peuvent envoyer des donnees a tout moment et ces donnees sont redirigees de/vers l'interpreteur de commande ou la commande cote serveur, et de/vers le terminal de l'utilisateur cote client. Lorsque le programme de l'utilisateur se termine et que toutes les connexions redirigees X11 ou autres ont ete fermees, le serveur envoie un code de fin de commande au client et les deux extremites quittent. PROCESSUS DE CONNEXION Lorsqu'un utilisateur se connecte avec succes, sshd effectue les operations suivantes : 1. Si la connexion s'appuie sur un terminal et si aucune commande n'a ete specifiee, il affiche la date et l'heure de derniere connexion et le message du jour /etc/motd (sauf si cet affichage est annule dans le fichier de configuration ou a 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 verifie la presence du fichier /etc/nologin ; s'il existe, il affiche son contenu et quitte (sauf pour le superutilisateur). 4. Il change ses privileges d'execution pour ceux d'un utilisateur normal. 5. Il definit 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 repertoire personnel de l'utilisateur. 8. Si le fichier ~/.ssh/rc existe et si l'option PermitUserRC de sshd_config(5) est definie, il l'execute ; sinon, si le fichier /etc/ssh/sshrc existe, il l'execute ; sinon, il execute xauth(1). Les fichiers << rc >> recoivent le protocole d'authentification et le cookie d'X11 sur l'entree standard. Voir SSHRC ci-dessous. 9. Il execute la commande ou l'interpreteur de commande de l'utilisateur. Toutes les commandes sont executees par l'interpreteur de commande de connexion de l'utilisateur specifie dans la base de donnees des mots de passe du systeme. SSHRC Si le fichier ~/.ssh/rc existe, sh(1) l'execute apres avoir lu les fichiers d'environnement, mais avant d'executer la commande ou l'interpreteur de commande de l'utilisateur. Toute sortie consecutive a l'execution de ce fichier doit etre envoyee sur la sortie d'erreur standard (stderr) a la place de la sortie standard (stdout). Si la redirection d'X11 est activee, ce fichier recevra la paire << proto cookie >> sur son entree 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'executer toute routine d'initialisation qui pouvait etre necessaire avant que le repertoire 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 a : 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 execute s'il existe, sinon le cookie est ajoute a l'aide de xauth. FORMAT DU FICHIER AUTHORIZED_KEYS L'option AuthorizedKeysFile permet de specifier les fichiers contenant les cles publiques pour l'authentification par cle publique ; si elle n'est pas definie, les fichiers par defaut sont ~/.ssh/authorized_keys et ~/.ssh/authorized_keys2. Chaque ligne de ces fichiers contient une cle (les lignes vides et les lignes commencant par << # >> sont considerees comme des commentaires et sont ignorees). Une cle publique se compose des champs suivants separes par des espaces : options, type de cle, cle codee en base64 et commentaire. Le champ options est facultatif. Les types de cle 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'utilite particuliere (mais il peut s'averer utile a l'utilisateur pour identifier la cle). Notez que les lignes de ces fichiers peuvent avoir une longueur de plusieurs centaines d'octets (a cause de la taille de l'encodage de la cle publique) avec une limite a 8 Ko, ce qui autorise des cles RSA d'une taille jusqu'a 16 kbit. Plutot que de les taper a la main, copiez le fichier id_ecdsa.pub, id_ecdsa_sk.pub, id_ed25519.pub, id_ed25519_sk.pub ou id_rsa.pub et editez-le. sshd impose une taille minimale de 1024 bits pour le modulo de la cle RSA. Les options (s'il y en a) consistent en une liste de specifications separees par des virgules. Aucune espace n'est permise si elle n'est pas entouree de guillemets droits doubles. Les specifications d'option prises en charge sont les suivantes (le nom de l'option est insensible a la casse) : agent-forwarding Cette option permet d'activer la redirection d'un agent d'authentification prealablement desactivee par l'option restrict. cert-authority Cette option permet d'indiquer que la cle en question correspond a une autorite de certification (CA) qui est digne de confiance pour valider des certificats signes pour l'authentification de l'utilisateur. Les certificats peuvent encoder des restrictions d'acces similaires a ces options de cle. Si les restrictions de certificat et les options de cle sont toutes deux presentes, c'est l'union des deux la plus restrictive qui s'applique. command="commande" Cette option permet de specifier une commande a executer chaque fois que la cle est utilisee pour l'authentification. La commande specifiee par l'utilisateur (si elle existe) est ignoree. La commande est executee sur un pseudo-terminal si le client en demande un ; sinon elle est executee en dehors de tout terminal. Si un canal apte a la transmission sur 8 bits (<< 8-bit clean channel >>) est requis, on ne doit pas demander de pseudo- terminal ou on peut specifier no-pty. La commande peut contenir des guillemets si ces derniers sont echappes par des barres obliques inversees. Cette option peut etre utile pour restreindre certaines cles publiques a des actions specifiques. Par exemple, une cle peut n'autoriser que les sauvegardes distantes, mais rien d'autre. Notez que le client peut specifier des redirections TCP et/ou d'X11, sauf si elles sont explicitement interdites a l'aide de l'option restrict, par exemple. La commande originelle fournie par le client est enregistree dans la variable d'environnement SSH_ORIGINAL_COMMAND. Notez que cette option s'applique a l'execution d'un interpreteur de commande, d'une commande ou d'un sous-systeme. Notez aussi que cette option peut etre outrepassee par une directive ForceCommand de sshd_config(5). Si une commande est specifiee et si une commande forcee est embarquee dans un certificat utilise pour l'authentification, le certificat ne sera accepte que si les deux commandes sont identiques. environment="NOM=valeur" Cette option indique que la chaine specifiee doit etre ajoutee a l'environnement lorsqu'on se connecte avec cette cle. Les variables d'environnement definies de cette maniere l'emportent sur les autres valeurs de l'environnement par defaut. Il est possible de specifier plusieurs options de ce type. L'option PermitUserEnvironment permet de controler le traitement de l'environnement, ce traitement etant desactive par defaut. expiry-time="spec_temps" Cette option permet de specifier une date apres laquelle la cle ne sera plus acceptee. La date peut etre specifiee sous la forme AAAAMMJJ[Z] ou AAAAMMJJHHMM[SS][Z]. Dates et heures seront interpretees selon la zone horaire du systeme, sauf s'ils sont suffixes par le caractere << Z >>, auquel cas elles seront interpretees dans la zone horaire UTC. from="liste_motifs" Cette option permet de specifier qu'en plus de l'authentification par cle publique, la liste de motifs separes 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 a propos des motifs. En plus de la correspondance avec caracteres generiques applicable aux noms des machines ou a 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'ameliorer la securite : l'authentification par cle publique en elle-meme ne fait confiance ni au reseau, ni aux serveurs de noms, ni a rien du tout (sauf a la cle) ; cependant, si quelqu'un de quelque maniere que ce soit vole la cle, cette derniere lui permettra de se connecter depuis n'importe ou dans le monde. L'ajout de cette option rend plus difficile l'utilisation d'une cle volee (en plus de la cle, les serveurs de noms et/ou les routeurs devraient aussi etre compromis). no-agent-forwarding Cette option permet d'interdire la redirection de l'agent d'authentification lorsque cette cle est utilisee pour l'authentification. no-port-forwarding Cette option permet d'interdire la redirection TCP lorsque cette cle est utilisee pour l'authentification. Toute demande de redirection de port de la part du client renverra une erreur. Cette option peut etre utilisee, par exemple, en combinaison avec l'option command. no-pty Cette option permet d'empecher l'allocation d'un terminal (toute demande pour allouer un pseudo-terminal echouera). no-user-rc Cette option permet de desactiver l'execution de ~/.ssh/rc. no-X11-forwarding Cette option permet d'interdire la redirection d'X11 lorsque cette cle est utilisee 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 facon a ce qu'il ne puisse ecouter que sur la machine (facultatif) et le port specifies. Il est possible de specifier des adresses IPv6 en les entourant de crochets. Plusieurs options permitlisten peuvent etre specifiees en les separant avec des virgules. Les noms de machine peuvent contenir des caracteres generiques comme decrit dans la section MOTIFS de ssh_config(5). Une valeur de port de * correspond a n'importe quelle valeur de port. Notez qu'une definition de GatewayPorts pourra restreindre encore plus les adresses d'ecoute. Notez aussi que ssh(1) enverra le nom de machine << localhost >> si aucune machine d'ecoute n'a ete specifiee lors de la demande de redirection, et que ce nom est traite differemment 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 facon a ce qu'il ne puisse ecouter que sur la machine et le port specifies. Il est possible de specifier des adresses IPv6 en les entourant de crochets. Plusieurs options permitopen peuvent etre specifiees en les separant avec des virgules. Aucune comparaison de motifs ou recherche de nom n'est effectuee sur les noms de machine specifies, ces derniers devant etre des noms de machine sous forme litterale et/ou des adresses. Si l'on specifie une valeur de port de *, toute valeur de port correspondra. port-forwarding Cette option permet d'activer une redirection de port prealablement desactivee a l'aide de l'option restrict. principals="principals" Sur une ligne cert-authority, cette option permet de specifier les << principals >> autorises pour l'authentification par certificat sous la forme d'une liste separee par des virgules (NDT : un << principal >> est une chaine arbitraire definie au niveau du serveur pour un utilisateur et devant etre presente dans le certificat du client pour que ce dernier puisse se connecter). Pour que le certificat soit accepte, au moins un nom de la liste doit apparaitre dans la liste de << principal >> du certificat. Cette option est ignoree pour les cles qui ne sont pas marquees comme signataires de certificat de confiance a l'aide de l'option cert-authority. pty Cette option permet d'activer une allocation de terminal prealablement desactivee a l'aide de l'option restrict. no-touch-required Avec cette option, demontrer la presence de l'utilisateur pour les signatures effectuees en utilisant cette cle n'est pas necessaire. 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 effectuees en utilisant cette cle doivent attester qu'elles identifient l'utilisateur, par exemple a 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, a savoir la desactivation de la redirection de port, d'agent et d'X11, ainsi que la desactivation de l'allocation de pseudo-terminal et l'execution de ~/.ssh/rc. Toute capacite de restriction ajoutee 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 definie, c'est le premier dispositif de tunnel disponible qui sera utilise. user-rc Cette option permet d'activer l'execution de ~/.ssh/rc prealablement desactivee a l'aide de l'option restrict. X11-forwarding Cette option permet d'activer la redirection d'X11 prealablement desactivee a l'aide de l'option restrict. Un exemple de fichier authorized_keys : # Les commentaires sont autorises en debut de ligne. Les lignes vides sont autorisees. # Cle complete, pas de restrictions ssh-rsa ... # Commande forcee, desactivation du pseudo-terminal et de toutes les redirections restrict,command="dump /home" ssh-rsa ... # Restriction des destinations de redirection a l'aide de ssh -L permitopen="192.0.2.1:80",permitopen="192.0.2.2:25" ssh-rsa ... # Restriction des ecouteurs de redirection a 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 cles FIDO sans necessiter la presence de l'utilisateur no-touch-required sk-ecdsa-sha2-nistp256@openssh.com ... # Necessite la verification de l'utilisateur (par exemple par PIN ou biometrie) # pour la cle FIDO verify-required sk-ecdsa-sha2-nistp256@openssh.com ... # Faire confiance a la cle de CA, autoriser FIDO sans presence de l'utilisateur # si demandee 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 cles publiques de tous les hotes connus. Le fichier global doit etre prepare par l'administrateur (facultatif), mais le fichier de l'utilisateur est mis a jour automatiquement : chaque fois que l'utilisateur se connecte a un hote inconnu, sa cle est ajoutee au fichier de l'utilisateur. Chaque ligne de ces fichiers contient les champs suivants : marqueur (facultatif), noms d'hote, type de cle, cle encodee en base64, commentaire. Les champs sont separes par des espaces. Le marqueur est facultatif mais s'il est present, il doit etre egal a << @cert-authority >> pour indiquer que la ligne contient une cle d'autorite de certification (CA), ou a << @revoked >> pour indiquer que la cle que la ligne contient est revoquee et ne doit plus etre acceptee. Un seul marqueur doit etre present dans une ligne de cle. Les noms d'hote constituent une liste de motifs separes par des virgules (<< * >> et << ? >> sont des caracteres generiques) ; chaque motif l'un apres l'autre est mis en correspondance avec le nom d'hote. 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'hote donne par l'utilisateur, de la valeur de l'option HostkeyAlias de ssh(1) si elle est specifiee ou du nom d'hote canonique du serveur si l'option CanonicalizeHostname est specifiee. Un motif peut aussi etre precede d'un point d'exclamation << ! >> pour indiquer une negation : si le nom d'hote correspond a un tel motif inverse, il ne sera pas accepte (par cette ligne), meme s'il correspond a un autre motif de cette meme ligne. Un nom d'hote ou une adresse peuvent eventuellement etre entoures de crochets << [ >> et << ] >> et suivis de << : >> et d'un numero de port non standard. Autrement, les noms d'hote peuvent etre stockes sous une forme hachee qui dissimule les adresses et noms d'hote au cas ou le contenu du fichier venait a etre divulgue. Les noms d'hote haches commencent par le caractere << | >>. Une ligne ne doit contenir qu'un seul nom d'hote hache et aucune negation comme ci-dessus et aucun caractere generique ne doit s'appliquer. Le type de cle et la cle encodee en base64 sont directement extraits de la cle d'hote qui peut etre obtenue a partir de /etc/ssh/ssh_host_rsa_key.pub par exemple. Le champ commentaire facultatif continue jusqu'a la fin de la ligne et n'est pas utilise. Les lignes vides ou debutant par le caractere << # >> sont ignorees et considerees comme des commentaires. Lors d'une authentification de machine, l'authentification est acceptee si une ligne comporte la cle appropriee : soit une cle qui correspond exactement, soit, si le serveur a presente un certificat pour l'authentification, la cle de l'autorite de certification qui a signe le certificat. Pour une cle qui possede la fiabilite d'une autorite de certification, elle doit utiliser le marqueur << @cert-authority >> decrit ci-dessus. Le fichier des hotes connus permet aussi de marquer des cles comme revoquees, par exemple lorsqu'on sait que la cle privee associee a ete volee. Les cles revoquees sont specifiees en ajoutant le marqueur << @revoked >> en debut de ligne de cle et ne sont jamais acceptees pour l'authentification ou en tant qu'autorite de certification, mais elles provoquent un avertissement de la part de ssh(1) lorsqu'on en rencontre une. Il est permis (mais deconseille) d'associer plusieurs lignes ou differentes cles d'hote a un seul nom d'hote. Cela arrive inevitablement quand des versions courtes de noms d'hote de differents domaines sont enregistrees dans le fichier. Les fichiers peuvent contenir des informations qui entrent en conflit ; l'authentification est cependant acceptee si l'on peut trouver des informations valables dans un des fichiers. Notez que les lignes dans ces fichiers contiennent generalement des centaines de caracteres, et il n'est pas tres interessant de les saisir manuellement. On peut plutot les generer a l'aide d'un script, par exemple /etc/ssh/ssh_host_rsa_key.pub, et ajouter les noms d'hote au debut. ssh-keygen(1) fournit aussi quelques possibilites d'edition automatique de ~/.ssh/known_hosts comme la suppression des hotes qui correspondent a un nom d'hote ou la conversion de tous les noms d'hote en leurs representations hachees. Un exemple de fichier ssh_known_hosts : # Les commentaires sont autorises en debut de ligne cvs.example.net,192.0.2.10 ssh-rsa AAAA1234.....= # Un nom d'hote hache |1|JfKTdBh7rNbXkVAQCRp4OQoPfmI=|USECr3SWf1JUPsms5AqfD5QfxkM= ssh-rsa AAAA1234.....= # Une cle revoquee @revoked * ssh-rsa AAAAB5W... # Une cle de CA acceptee pour tout hote 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 derniere connexion si PrintMotd et PrintLastLog, respectivement, sont activees. Il ne supprime pas l'affichage de la banniere specifiee par Banner. ~/.rhosts Ce fichier est utilise pour l'authentification basee sur la machine (voir ssh(1) pour plus d'informations). Sur certaines machines, ce fichier devra peut-etre etre accessible en lecture pour tout le monde si le repertoire personnel de l'utilisateur est sur une partition NFS, car sshd le lit en tant que superutilisateur. De plus, ce fichier doit etre la propriete de l'utilisateur et ne doit etre accessible en ecriture par personne d'autre. Les permissions recommandees pour la plupart des machines sont : acces en lecture/ecriture pour l'utilisateur et aucun acces pour les autres. ~/.shosts Ce fichier est utilise exactement de la meme facon que .rhosts, mais il permet l'authentification basee sur la machine sans autoriser les connexions avec rlogin/rsh. ~/.ssh/ Ce repertoire correspond a l'emplacement par defaut de toutes les informations de configuration et d'authentification specifiques a l'utilisateur. Il n'est globalement pas necessaire de garder secret l'ensemble du contenu de ce repertoire, mais les permissions recommandees sont lecture/ecriture/execution pour l'utilisateur et aucun acces pour les autres. ~/.ssh/authorized_keys Ce fichier liste les cles publiques (ECDSA, Ed25519, RSA) utilisables pour se connecter avec le compte de l'utilisateur. Son format est decrit plus haut. Son contenu n'est pas hautement sensible, mais les permissions recommandees sont : acces en lecture/ecriture pour l'utilisateur et aucun acces pour les autres Si ce fichier, le repertoire ~/.ssh ou le repertoire personnel de l'utilisateur etaient accessible en ecriture par les autres utilisateurs, ce fichier pourrait etre modifie ou remplace par des utilisateurs non autorises. Dans ce cas, sshd n'autorisera pas son utilisation, a moins que l'option StrictModes n'ait ete definie a << 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 caractere << # >>) et des lignes d'affectation de la forme nom=valeur. Le fichier ne doit etre accessible en ecriture que pour l'utilisateur ; il n'a pas besoin d'etre accessible en lecture pour les autres. Le traitement de l'environnement est desactive par defaut et controle a l'aide de l'option PermitUserEnvironment. ~/.ssh/known_hosts Ce fichier contient une liste des cles d'hote pour tous les hotes auxquels l'utilisateur s'est connecte et qui ne sont pas encore dans la liste globale des cles d'hote connues du systeme. Son format est decrit plus haut. Il ne doit etre accessible en ecriture que pour son proprietaire et le superutilisateur et peut, mais ce n'est pas necessaire, etre accessible en lecture pour les autres. ~/.ssh/rc Ce fichier contient des routines d'initialisation a executer avant que le repertoire personnel de l'utilisateur devienne accessible. Il ne doit etre accessible en ecriture que pour l'utilisateur et n'a pas besoin d'etre accessible en lecture pour les autres. /etc/hosts.equiv Ce fichier est utilise pour l'authentification basee sur la machine (voir ssh(1)). Il ne doit etre accessible en ecriture que pour le superutilisateur. /etc/ssh/moduli Ce fichier contient les groupes Diffie-Hellman utilises pour la methode d'echange de cles << Diffie-Hellman Group Exchange >>. Son format est decrit dans moduli(5). Si aucun groupe utilisable n'est trouve dans ce fichier, ce sont les groupes internes fixes qui seront utilises. /etc/motd Voir motd(5). /etc/nologin Si ce fichier existe, sshd empeche quiconque de se connecter, a l'exception du superutilisateur. Le contenu de ce fichier est communique a quiconque essayant de se connecter et les connexions non-superutilisateur sont refusees. Ce fichier doit etre accessible en lecture pour tout le monde. /etc/ssh/shosts.equiv Ce fichier est utilise exactement de la meme maniere que hosts.equiv, mais il permet l'authentification basee 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 privee des cles d'hote. Ils ne doivent etre la propriete que du superutilisateur, accessibles en lecture uniquement pour ce dernier et inaccessibles pour les autres. Notez que sshd ne demarrera 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 cles d'hote. Ils doivent etre accessibles en lecture pour tous, mais accessibles en ecriture uniquement pour le superutilisateur. Leurs contenus doivent correspondre a leurs parties privees respectives. Ils ne sont pas vraiment utilises pour pour une action quelconque ; ils sont fournis par commodite pour l'utilisateur qui peut les copier dans ses fichiers des hotes connus. Ces fichiers sont crees en utilisant ssh-keygen(1). /etc/ssh/ssh_known_hosts Ce fichier contient la liste globale du systeme des cles d'hote connues. Il doit etre prepare par l'administrateur systeme de maniere a contenir les cles d'hote publiques de toutes les machines de l'organisation. Son format est decrit plus haut. Il doit etre accessible en ecriture pour le superutilisateur et le proprietaire et en lecture pour les autres. /etc/ssh/sshd_config Ce fichier contient les donnees de configuration pour sshd. Son format et les options de configuration sont decrits dans sshd_config(5). /etc/ssh/sshrc Identique a ~/.ssh/rc, ce fichier permet de specifier globalement des initialisations pour la connexion machine par machine. Ce fichier ne doit etre accessible en ecriture que pour le superutilisateur et en lecture pour les autres. /usr/share/empty.sshd Il s'agit du repertoire de chroot(2) utilise par sshd lors de la separation de privileges dans la phase de pre-authentification. Le repertoire ne doit contenir aucun fichier, est la propriete du superutilisateur et ne doit pas etre accessible en ecriture pour le groupe ou les autres. /run/sshd.pid Ce fichier contient l'identifiant du processus (PID) du demon sshd en attente de connexions (si plusieurs demons sont en cours d'execution sur plusieurs ports, ce fichier contient l'identifiant du dernier demon demarre). Le contenu de ce fichier n'est pas sensible et il peut etre 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), login.conf(5), moduli(5), sshd_config(5), inetd(8), sftp-server(8) AUTEURS OpenSSH est derive 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 corrige de nombreux bogues, rajoute des nouvelles fonctionnalites et cree OpenSSH. Markus Friedl a contribue a la prise en charge des versions 1.5 et 2.0 du protocole SSH. Niels Provos et Markus Friedl ont contribue a la prise en charge de la separation des privileges. TRADUCTION La traduction francaise de cette page de manuel a ete creee par Laurent GAUTROT et Lucien Gentis Cette traduction est une documentation libre ; veuillez vous reporter a 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 RESPONSABILITE LEGALE. Si vous decouvrez un bogue dans la traduction de cette page de manuel, veuillez envoyer un message a debian-l10n-french@lists.debian.org Linux 6.12.8-arch1-1 September 15, 2024 Linux 6.12.8-arch1-1