Scroll to navigation

SSH_CONFIG(5) File Formats Manual SSH_CONFIG(5)

NOM

ssh_config — Fichier de configuration du client OpenSSH

DESCRIPTION

ssh(1) obtient ses données de configuration à partir des sources suivantes et dans cet ordre :

  1. options de la ligne de commande
  2. fichier de configuration de l’utilisateur (~/.ssh/config)
  3. fichier de configuration globale du système (/etc/ssh/ssh_config)

Sauf indication contraire, pour chaque paramètre, c’est la première valeur obtenue qui sera utilisée. Les fichiers de configuration contiennent des sections séparées par des spécifications de machine Host, et chaque section ne s’applique qu’à la machine dont le nom correspond à un des motifs donnés dans la spécification de machine. Le nom de machine qui correspond aux motifs est en général celui qui a été spécifié sur la ligne de commande (voir l’option CanonicalizeHostname pour les exceptions).

Comme c'est la première valeur obtenue pour chaque paramètre qui est utilisée, les déclarations les plus spécifiques aux machines doivent être vers le début du fichier, et les valeurs générales par défaut vers la fin.

Notez que le paquet Debian openssh-client définit plusieurs options comme valeurs standard dans /etc/ssh/ssh_config qui ne correspondent pas aux valeurs par défaut dans ssh(1)  :

Les fichiers /etc/ssh/ssh_config.d/*.conf étant inclus au début du fichier de configuration globale du système, les options qu’ils contiennent vont outrepasser celles définies dans /etc/ssh/ssh_config.

Le fichier contient des paires mot-clé/argument à raison d’une paire par ligne. Les lignes commençant par « # » et les lignes vides sont interprétées comme des commentaires. Pour spécifier des arguments contenant des espaces, on peut les entourer de guillemets droits « " ». Les options de configuration peuvent être séparées par des blancs ou un blanc facultatif et exactement un signe égal « = » ; le deuxième format évite d’avoir à mettre les blancs entre guillemets lors de la spécification d’options de configuration en utilisant l’option -o de ssh, scp et sftp.

Les mots-clés valables et leurs significations sont les suivants (notez que les mots-clés ne sont pas sensibles à la casse, mais que les arguments le sont :

Cette option restreint l’application des déclarations suivantes (jusqu’au prochain mot-clé Host ou Match) aux seules machines dont le nom correspond à un des motifs indiqués après le mot-clé. Si plusieurs motifs sont indiqués, ils doivent être séparés par des blancs. Le motif « * » permet de définir des valeurs par défaut pour toutes les machines. La machine correspond en général à l’argument nom_machine de la ligne de commande (voir le mot-clé CanonicalizeHostname pour les exceptions).

On peut inverser une entrée de motif en la préfixant avec un point d’exclamation « ! ». Si une entrée inversée correspond, l’entrée Host correspondante est ignorée, qu’un autre motif de la ligne corresponde ou non. Les correspondances inversées permettent ainsi de définir des exceptions pour les correspondances avec caractères génériques.

Voir MOTIFS pour plus d’informations à propos des motifs.

Cette option assujettit l’application des déclarations suivantes (jusqu’au prochain mot-clé Host ou Match) au respect des conditions qui suivent le mot-clé Match. Les conditions de correspondance sont indiquées à l’aide d’un ou plusieurs critères ou du simple critère all qui implique une correspondance systématique. Les mots-clés valables pour les critères sont : canonical, final, exec, localnetwork, host, originalhost, tagged, user et localuser. Le critère all doit apparaître seul ou immédiatement après canonical ou final. Les autres critères peuvent être combinés arbitrairement. À l’exception de all, canonical et final, tous les critères nécessitent un argument. On peut inverser un critère en le préfixant avec un point d’exclamation « ! ».

Le mot-clé canonical n’implique une correspondance que lorsque le fichier de configuration est relu après que le nom de la machine a été mis sous forme canonique (voir l’option CanonicalizeHostname). Cela permet d’indiquer des options qui ne fonctionnent qu’avec les noms de machine canoniques.

Le mot-clé final demande une relecture de la configuration (que CanonicalizeHostname soit activée ou non), et n'effectue de comparaison que lors de cette passe finale. Si CanonicalizeHostname est activée, canonical et final effectuent une comparaison lors de la même passe.

Le mot-clé exec exécute la commande spécifiée sous l’interpréteur de commande de l’utilisateur. Si la commande renvoie zéro comme code de retour, la condition est considérée comme remplie. Les commandes contenant des caractères blancs doivent être entourées de guillemets. Les arguments de exec acceptent les symboles décrits dans la section SYMBOLES.

Le mot-clé localnetwork effectue une comparaison entre les adresses des interfaces réseau locales actives et la liste de réseaux fournie au format CIDR. Cette comparaison peut s’avérer utile pour adapter la configuration effective des périphériques qui changent de réseau. Notez que l’adresse réseau n’est pas un critère de confiance dans de nombreuses situations (par exemple lorsque le réseau est configuré automatiquement à l’aide de DHCP) et qu’il faut donc l’utiliser avec prudence pour contrôler une configuration particulièrement sensible à la sécurité.

Les autres critères des mots-clés doivent être des entrées simples ou des listes séparées par des virgules et peuvent contenir des caractères génériques et des opérateurs de négation comme décrit dans la section MOTIFS. Les critères pour le mot-clé host sont comparés avec le nom de machine cible après toute substitution à l’aide des options Hostname ou CanonicalizeHostname. Le mot-clé originalhost effectue une comparaison avec le nom de machine tel qu’il a été indiqué sur la ligne de commande. Le mot-clé tagged met en correspondance un nom de symbole spécifié par une directive Tag précédente ou sur la ligne de commande de ssh(1) à l’aide du drapeau -P. Le mot-clé user met en correspondance le nom d’utilisateur cible sur la machine distante. Le mot-clé localuser met en correspondance le nom de l’utilisateur local qui exécute ssh(1) (ce mot-clé peut s’avérer utile dans les fichiers de ssh_config globaux du système).

Cette option permet de spécifier si les clés doivent être ajoutées automatiquement à un ssh-agent(1) en cours d’exécution. Si cette option est définie à yes et si une clé est chargée depuis un fichier, la clé et sa phrase de passe sont ajoutées à l’agent avec une durée de vie par défaut, comme si on avait utilisé ssh-add(1). Si cette option est définie à ask, ssh(1) nécessite une confirmation à l’aide du programme SSH_ASKPASS avant d’ajouter une clé (voir ssh-add(1) pour les détails). Si cette option est définie à confirm, chaque utilisation de la clé doit être confirmée comme si l’option -c avait été spécifiée avec ssh-add(1). Si cette option est définie à no, aucune clé n’est ajoutée à l’agent. Cette option peut aussi prendre pour valeur un intervalle de temps en utilisant le format décrit dans la section FORMATS DE TEMPS de sshd_config(5) pour spécifier la durée de vie de la clé au sein du ssh-agent(1), durée après laquelle la clé sera automatiquement supprimée de l’agent. L’argument de cette option peut prendre pour valeur no (la valeur par défaut), yes, confirm (optionnellement suivie d’un intervalle de temps), ask ou un intervalle de temps.
Cette option permet de spécifier la famille d’adresses à utiliser lors de la connexion. Les arguments valables sont any (la valeur par défaut), inet (utiliser seulement IPv4) ou inet6 (utiliser seulement IPv6).
Si cette option est définie à yes, les interactions avec l’utilisateur comme les demandes de mot de passe et de confirmation de la clé d’hôte seront désactivées. En plus, l’option ServerAliveInterval sera définie par défaut à 300 secondes (spécifique à Debian). Cette option s’avère utile dans le cas des scripts et de toute tâche de traitement par lot où aucun utilisateur n’est présent pour interagir avec ssh(1), et quand il est souhaitable de détecter rapidement une coupure du réseau. L’argument doit être yes ou no (la valeur par défaut).
Utiliser l’adresse spécifiée sur la machine locale comme adresse source de la connexion. Cette option n’est utile que sur les systèmes qui possèdent plusieurs adresses.
Utiliser l’adresse de l’interface spécifiée sur la machine locale comme adresse source de la connexion.
Si CanonicalizeHostname est activée, cette option permet d’indiquer la liste des suffixes de domaine dans laquelle rechercher la machine de destination spécifiée.
Cette option indique s’il faut échouer avec une erreur lorsque la mise sous forme canonique du nom de machine échoue. Avec la valeur par défaut, yes, le nom de machine non qualifié sera recherché en utilisant les règles de recherche du résolveur du système. Avec la valeur no, ssh(1) échouera instantanément si CanonicalizeHostname est activé et si le nom de la machine cible n’a pu être trouvé dans aucun des domaines spécifiés à l’aide de CanonicalDomains.
Cette option indique si une mise sous forme canonique explicite du nom de machine doit être effectuée. Avec la valeur par défaut, no, aucune réécriture de nom n’est effectuée et le résolveur du système gère toutes les recherches de nom de machine. Avec la valeur yes et pour les connexions qui n’utilisent pas ProxyCommand ou ProxyJump, ssh(1) va tenter de mettre sous forme canonique le nom de machine spécifié sur la ligne de commande en utilisant les suffixes de CanonicalDomains et les règles de CanonicalizePermittedCNAMEs. Si CanonicalizeHostname est définie à always, la mise sous forme canonique s’applique aussi aux connexions mandatées.

Si cette option est activée, les fichiers de configuration sont relus pour prendre en compte le nouveau nom cible et ainsi détecter toute nouvelle configuration dans les sections Host et Match correspondantes. Une valeur none désactive l’utilisation de la machine ProxyJump.

Cette option permet de spécifier le nombre maximal de caractères point « . » dans un nom de machine au dessus duquel la mise sous forme canonique est désactivée. La valeur par défaut, 1, ne permet qu’un seul point, comme dans nom_machine.sous_domaine.
Cette option permet de spécifier des règles permettant de déterminer si les CNAME doivent être suivis lors de la mise sous forme canonique des noms de machine. Les règles consistent en un ou plusieurs arguments de la forme liste_domaines_source:liste_domaines_cible où liste_domaines_source est une liste de domaines sous forme de motifs qui peuvent suivre les CNAME pour la mise sous forme canonique, et liste_domaines_cible une liste de domaines sous forme de motifs vers lesquels ils peuvent être résolus

Par exemple, « *.a.example.com:*.b.example.com,*.c.example.com » permet aux noms de machine correspondant à « *.a.example.com » d’être mis sous forme canonique vers des noms dans les domaines « *.b.example.com » ou « *.c.example.com ».

Si « none » est le seul argument, aucun CNAME ne fera l’objet d’une mise sous forme canonique. Il s’agit du comportement par défaut.

Cette option permet de spécifier les algorithmes autorisés pour la signature des certificats par les autorités de certification (CA). Les algorithmes par défaut sont : 
ssh-ed25519,ecdsa-sha2-nistp256,
ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,
sk-ssh-ed25519@openssh.com,
sk-ecdsa-sha2-nistp256@openssh.com,
rsa-sha2-512,rsa-sha2-256

Si la liste fournie commence par un plus « + », les algorithmes qu’elle contient seront ajoutés à la liste des algorithmes par défaut au lieu de les remplacer. Si la liste fournie commence par un moins « - », les algorithmes qu’elle contient (pouvant comporter des caractères génériques) seront supprimés de la liste des algorithmes par défaut au lieu de les remplacer.

ssh(1) n’acceptera aucun certificat de machine signé en utilisant un algorithme autre que ceux spécifiés.

Cette option permet de spécifier un fichier à partir duquel le certificat de l’utilisateur sera lu. Pour utiliser ce certificat, une clé privée correspondante doit être fournie séparément à l’aide d’une directive IdentityFile ou du drapeau -i à ssh(1), de ssh-agent(1), ou d’une directive PKCS11Provider ou SecurityKeyProvider.

Les arguments de CertificateFile peuvent utiliser la syntaxe avec tilde « ~ » pour faire référence au répertoire personnel de l’utilisateur, ainsi que les symboles décrits dans la section SYMBOLES et les variables d’environnement comme décrit dans la section VARIABLES D’ENVIRONNEMENT.

Il est possible d’indiquer plusieurs fichiers de certificat dans les fichiers de configuration ; ces certificats seront essayés séquentiellement. Des directives CertificateFile multiples ajouteront les certificats contenus dans les fichiers qu’elles indiquent à la liste des certificats utilisés pour l’authentification.

Cette option permet de spécifier si ssh(1) doit fermer les canaux inactifs et au bout de combien de temps. Les délais sont indiqués sous forme d’une ou plusieurs paires « type=intervalle » séparées par des blancs, où « type » doit être le mot-clé spécial « global » ou un nom de type de canal dans la liste ci-dessous et pouvant contenir des caractères génériques.

La valeur du délai « intervalle » est indiquée en secondes ou toute unité décrite dans la section FORMATS DE TEMPS. Par exemple, « session=5m » signifierait la fermeture de la session interactive au bout de cinq minutes d’inactivité. Une valeur de délai de zéro désactive le délai d’inactivité.

Le délai spécial « global » s’applique à tous les canaux actifs pris dans leur ensemble. Tout trafic sur un canal actif va réinitialiser le délai, mais lorsque ce dernier arrivera à expiration, tous les canaux ouverts seront fermés. Notez que ce délai global ne peut pas être spécifié avec des caractères génériques et devra l’être explicitement.

Les noms de types de canal valables sont :

Les connexions ouvertes vers ssh-agent(1).
, direct-streamlocal@openssh.com
Les connexions ouvertes TCP ou de type socket Unix (respectivement) qui ont été établies à partir d’une redirection locale de ssh(1) comme LocalForward ou DynamicForward.
, forwarded-streamlocal@openssh.com
Les connexions ouvertes TCP ou de type socket Unix (respectivement) qui ont été établies vers un démon sshd(8) en écoute au nom d’une redirection distante de ssh(1), c’est-à-dire RemoteForward.
La session interactive principale, à savoir la session de l’interpréteur de commande, l’exécution de la commande, scp(1), sftp(1),  etc.
Connexions TunnelForward ouvertes.
Sessions de redirection X11 ouvertes.

Notez que dans chacun des cas ci-dessus, fermer une session inactive ne garantit pas la suppression de toutes les ressources associées à cette session ; en particulier, les processus de l’interpréteur de commande ou les clients X11 en rapport avec cette session peuvent continuer leur exécution.

En outre, fermer une session ou un canal inactifs ne ferme pas nécessairement la connexion SSH et n’empêche pas un client de demander un autre canal du même type. En particulier, l’expiration d’une session de redirection inactive n’empêche pas la création subséquente d’une autre redirection identique.

Le comportement par défaut consiste à ne fermer aucun canal de quelque type que ce soit pour inactivité.

Si l'argument est yes, ssh(1) vérifie en plus l'adresse IP de la machine dans le fichier known_hosts, ce qui lui permet de vérifier si une clé de machine a changé à cause d'une usurpation de DNS et ajoute les adresses des machines de destination à ~/.ssh/known_hosts dans le processus, quelle que soit la valeur de StrictHostKeyChecking. Si l'argument est no (la valeur par défaut), la vérification n'est pas effectuée.
Cette option permet de spécifier les algorithmes de chiffrement autorisés par ordre de préférence. Des algorithmes de chiffrement multiples doivent être séparés par des virgules. Si la liste fournie commence par un plus « + », les algorithmes qu’elle contient seront ajoutés à la liste des algorithmes par défaut au lieu de les remplacer. Si la liste fournie commence par un moins « - », les algorithmes qu’elle contient (pouvant comporter des caractères génériques) seront supprimés de la liste des algorithmes par défaut au lieu de les remplacer. Si la liste fournie commence par un caret « ^ », les algorithmes qu’elle contient seront placés en tête de la liste des algorithmes par défaut.

Les algorithmes de chiffrement pris en charge sont :

3des-cbc
aes128-cbc
aes192-cbc
aes256-cbc
aes128-ctr
aes192-ctr
aes256-ctr
aes128-gcm@openssh.com
aes256-gcm@openssh.com
chacha20-poly1305@openssh.com

La liste d’algorithmes par défaut est :

chacha20-poly1305@openssh.com,
aes128-ctr,aes192-ctr,aes256-ctr,
aes128-gcm@openssh.com,aes256-gcm@openssh.com

On peut aussi obtenir la liste des algorithmes de chiffrement disponibles en exécutant la commande « ssh -Q cipher ».

Cette option permet de spécifier que toutes les redirections de ports locaux, distants et dynamiques spécifiées dans les fichiers de configuration ou sur la ligne de commande doivent être supprimées. Cette option est utilisée principalement sur la ligne de commande de ssh(1) pour supprimer les redirections de ports définies dans les fichiers de configuration, et est définie automatiquement par scp(1) et sftp(1). Son argument est yes ou no, no étant la valeur par défaut.
Cette option permet de spécifier si on utilise la compression. L'argument est yes ou no, no étant la valeur par défaut.
Cette option permet de spécifier le nombre de tentatives (une par seconde) avant d'abandonner. L'argument doit être un entier. Cette option peut s’avérer utile dans les scripts s’il arrive que la connexion échoue. La valeur par défaut est 1.
Cette option permet de spécifier le délai (en secondes) utilisé à la place du délai TCP par défaut du système lors de la connexion au serveur SSH. Ce délai est appliqué pour établir la connexion et pour effectuer la négociation du protocole initiale et l’échange de clés.
Cette option active le partage de sessions multiples sur une seule connexion réseau. Lorsque cette option est définie à yes, ssh(1) va écouter les connexions sur un socket de contrôle spécifié à l’aide de l’argument de ControlPath. Si ControlMaster est définie à no (la valeur par défaut), des sessions additionnelles pourront se connecter à ce même socket. Ces sessions vont tenter de réutiliser la connexion réseau de l'instance principale au lieu d’en initier de nouvelles, mais reviendront à une connexion normale si le socket de contrôle n’existe pas ou n’est pas en écoute.

Si cette option est définie à ask, ssh(1) va écouter les connexions de contrôle mais demander confirmation à l’aide de ssh-askpass(1). Si le socket défini par ControlPath ne peut pas être ouvert, ssh(1) continuera sans se connecter à l’instance principale.

Les redirections X11 et les redirections de l’agent ssh-agent(1) sont prises en charge sur ces connexions multiplexées ; cependant, le « display » et l’agent redirigés seront ceux qui appartiennent à la connexion principale ; autrement dit, il n’est pas possible de rediriger plusieurs « display » ou agents.

Cette option accepte deux valeurs supplémentaires qui permettent le multiplexage opportuniste, c’est-à-dire essayer d’utiliser une connexion principale mais revenir à une connexion normale en en créant une nouvelle s’il n’en existe pas déjà une. Ces valeurs sont auto et autoask. La dernière nécessite une confirmation comme c’est le cas pour ask.

Cette option permet de spécifier le chemin du socket de contrôle utilisé pour le partage de connexion décrit dans la section ControlMaster ci-dessus ou la chaîne none pour désactiver le partage de connexion. Les arguments de ControlPath peuvent utiliser la syntaxe avec tilde « ~ » pour faire référence au répertoire personnel de l’utilisateur, ainsi que les symboles décrits dans la section SYMBOLES et les variables d’environnement comme décrit dans la section VARIABLES D’ENVIRONNEMENT. Il est recommandé d’inclure au moins %h, %p et %r (ou %C) dans tout ControlPath utilisé pour le partage de connexion opportuniste et de placer ce dernier dans un répertoire non accessible en écriture pour les autres utilisateurs. Cela permet de s’assurer que les connexions partagées sont identifiées de manière unique.
Lorsqu’elle est utilisée en conjonction avec ControlMaster, cette option indique que la connexion principale doit rester ouverte en arrière-plan (en attente de connexions clientes) après que la connexion cliente initiale a été fermée. Si elle est définie à no (la valeur par défaut), la connexion ne sera pas placée en arrière-plan et se fermera dès que la connexion cliente initiale sera elle-même fermée. Si elle est définie à yes ou 0, la connexion principale restera en arrière-plan indéfiniment (jusqu’à ce qu’elle soit tuée ou fermée à l’aide d’un mécanisme comme « ssh -O exit »). Si elle définie à une durée en secondes ou sous un des formats décrits dans sshd_config(5), la connexion principale en arrière-plan sera automatiquement fermée après un délai d’inactivité (sans connexions clientes) égal à la durée spécifiée.
Spécifie un port TCP sur la machine locale à rediriger par le tunnel sécurisé. Le protocole de l'application est alors utilisé pour déterminer vers où se connecter depuis la machine distante.

L’argument doit être [adr_sortie:]port. Les adresses IPv6 doivent être entourées de crochets. Par défaut, le port local est associé en accord avec la définition de GatewayPorts. Il est cependant possible d’utiliser une adresse adr_source explicite pour associer la connexion à une adresse spécifique. Une adresse adr_source égale à localhost indique que le port d’écoute est associé pour un usage local seulement, alors qu’une adresse vide ou « * » indique que le port sera disponible sur toutes les interfaces.

Les protocoles SOCKS4 et SOCKS5 sont actuellement pris en charge et ssh(1) agit en tant que serveur SOCKS. Plusieurs redirections peuvent être spécifiées et des redirections additionnelles peuvent être indiquées sur la ligne de commande. Seul le superutilisateur peut rediriger des ports privilégiés.

Cette option active la ligne de commande dans le menu du caractère d’échappement EscapeChar (par défaut « ~C ») pour les sessions interactives. Par défaut, la ligne de commande est désactivée
Définir cette option à yes dans le fichier de configuration globale du client /etc/ssh/ssh_config active le recours à l’utilitaire ssh-keysign(8) lors de l’authentification HostbasedAuthentication. L’argument doit être yes ou no (la valeur par défaut). Cette option doit être placée dans la section non spécifique à une machine. Voir ssh-keysign(8) pour plus d’informations.
Cette option permet de définir le caractère d’échappement (par défaut « ~ »). Le caractère d’échappement peut aussi être défini sur la ligne de commande. L’argument doit être un caractère seul, « ^ » suivi d’une lettre ou none pour désactiver totalement le caractère d’échappement, ce qui rend la connexion transparente pour les données binaires.
Cette option permet de spécifier si ssh(1) doit fermer la connexion s’il ne peut pas configurer toutes les redirections dynamiques, par tunnel, locales et distantes demandées (par exemple si une des deux extrémités est incapable de se lier et d’écouter sur un port donné). Notez que cette option ne s’applique pas aux connexions établies à l’aide de redirections de port ; par exemple, elle n’impliquera pas la terminaison de ssh(1) si les connexions TCP vers la destination de redirection finale échouent. L’argument doit être yes ou no (la valeur par défaut).
Cette option permet de spécifier l’algorithme de hachage utilisé lors de l’affichage des empreintes de clé. Les valeurs possibles sont md5 et sha256 (la valeur par défaut).
Cette option permet de demander à ssh de passer en arrière-plan juste avant l’exécution de la commande. Elle s’avère utile s’il est prévu que ssh demande des mots ou phrases de passe, et si l’utilisateur veut que cela se passe en arrière-plan. Cela implique que l’option de configuration StdinNull soit définie à yes. La méthode recommandée pour lancer des programmes X11 sur un site distant consiste à utiliser quelque chose du genre ssh -f machine xterm, ce qui est identique à ssh machine xterm si l’option de configuration ForkAfterAuthentication est définie à yes.

Si l’option de configuration ExitOnForwardFailure est définie à yes, un client démarré avec l’option de configuration ForkAfterAuthentication définie à yes attendra que toutes les redirections de port distantes soient établies avec succès avant de se placer de lui-même en arrière-plan. L’argument de cette option doit être yes (même effet que l’option de ligne de commande -f) ou no (la valeur par défaut).

Cette option permet de spécifier si la connexion à l'agent d'authentification (s'il existe) doit être redirigée vers la machine distante. L'argument peut être yes, no (la valeur par défaut), un chemin explicite vers un socket d’agent ou le nom d’une variable d’environnement (commençant par « $ ») contenant ce chemin.

La redirection d’agent doit être utilisée avec prudence. En effet, un utilisateur ayant la possibilité de court-circuiter les permissions de fichier sur la machine distante (pour le socket de domaine Unix de l’agent) pourra accéder à l’agent local à travers la connexion redirigée. Un attaquant ne pourra pas obtenir de données à propos des clés à partir de l’agent, mais il pourra cependant effectuer des opérations sur ces dernières qui lui permettront de s’authentifier en utilisant les identités chargées dans l’agent.

Cette option permet de spécifier si les connexions X11 doivent être redirigées automatiquement dans le canal sécurisé et la variable d'environnement DISPLAY définie. L'argument doit être yes ou no (la valeur par défaut).

La redirection X11 doit être utilisée avec prudence. En effet, un utilisateur ayant la possibilité de court-circuiter les permissions de fichier sur la machine distante (pour la base de données d’autorisations X11 de l’utilisateur) pourra accéder au « display » X11 local à travers la connexion redirigée. Un attaquant pourra alors effectuer des opérations comme l’interception des frappes de touches au clavier si l’option ForwardX11Trusted est elle aussi activée.

Cette option permet de spécifier un délai pour les redirections X11 non fiables en utilisant le format décrit dans la section FORMATS DE TEMPS de sshd_config(5). Les connexions X11 reçues par ssh(1) après ce délai seront rejetées. Définir ForwardX11Timeout à zéro désactive le délai et permet les redirections X11 pendant toute la durée de vie de la connexion. Par défaut, une redirection X11 non fiable sera désactivée après un délai de vingt minutes.
Si cette option est définie à yes, (la valeur par défaut spécifique à Debian), les clients X11 distants auront plein accès au « display » X11 originel.

Si cette option est définie à no (la valeur par défaut de l’amont), les clients X11 distants seront considérés comme non fiables et ne pourront pas voler ou altérer de données appartenant à des clients X11 fiables. En outre, le jeton de xauth(1) utilisé pour la session sera configuré pour expirer après 20 minutes. Les clients distants se verront refuser l’accès après ce délai.

Voir les spécifications de l’extension X11 SECURITY pour tous les détails des restrictions imposées aux clients non fiables.

Cette option permet de spécifier si les machines distantes sont autorisées à se connecter aux ports locaux redirigés. Par défaut ssh(1) associe les redirections de ports locaux à l’adresse de bouclage (loopback). Cela empêche les autres machines distantes de se connecter à des ports redirigés. GatewayPorts permet de spécifier que ssh(1) doit associer les redirections de ports locaux à l’adresse avec caractères génériques (wildcard), et par conséquent, autorise les machines distantes à se connecter aux ports redirigés. L'argument doit être yes ou no (la valeur par défaut).
Cette option permet de spécifier un ou plusieurs fichiers, séparés par des blancs, de base de données globale des clés d’hôte à utiliser à la place des fichiers par défaut /etc/ssh/ssh_known_hosts et /etc/ssh/ssh_known_hosts2
Cette option permet d’indiquer si l’authentification utilisateur basée sur GSSAPI est autorisée. La valeur par défaut est no.
Cette option permet de spécifier l’identité du client GSSAPI que ssh(1) doit utiliser pour se connecter au serveur. Si elle n’est pas définie (comportement par défaut), c’est l’identité par défaut qui sera utilisée.
Cette option permet de transférer (déléguer) les données de connexion au serveur. La valeur par défaut est no.
Cette option permet d’indiquer si l’échange de clé basé sur GSSAPI peut être utilisé. Lorsqu’on utilise l’échange de clé basé sur GSSAPI, le serveur n’a pas besoin de clé d’hôte. La valeur par défaut est no.
Si cette option est définie à yes, le renouvellement des données d’identification GSSAPI du client va forcer le renouvellement des clés de la connexion ssh(1). Avec un serveur compatible, les données d’identification renouvelées seront propagées vers la session sur le serveur.

Des vérifications sont effectuées pour s’assurer que les données d’identification ne sont propagées que lorsque les nouvelles données correspondent aux anciennes sur le client originel et si le serveur récepteur possède encore les anciennes données dans son cache.

La valeur par défaut est no.

Tout cela ne peut fonctionner que si l’option GSSAPIKeyExchange a été activée sur le serveur et si le client l’utilise aussi.

Cette option permet de spécifier l’identité GSSAPI du serveur à laquelle ssh(1) doit s’attendre en se connectant au serveur. Si elle n’est pas définie (comportement par défaut), l’identité GSSAPI du serveur attendue sera déterminée à partir du nom de machine de la cible.
Définissez cette option à yes pour indiquer que le DNS est suffisamment fiable pour mettre sous forme canonique de manière sécurisée le nom de la machine connectée. Si cette option est définie à no (la valeur par défaut), le nom de machine spécifié sur la ligne de commande sera transmis tel quel à la bibliothèque GSSAPI.
Cette option permet de spécifier la liste des algorithmes d’échange de clé disponibles pour l’échange de clé GSSAPI. Les valeurs possibles sont : 
gss-gex-sha1-,
gss-group1-sha1-,
gss-group14-sha1-,
gss-group14-sha256-,
gss-group16-sha512-,
gss-nistp256-sha256-,
gss-curve25519-sha256-

La liste par défaut est « gss-group14-sha256-,gss-group16-sha512-,gss-nistp256-sha256-,gss-curve25519-sha256-,gss-gex-sha1-,gss-group14-sha1- ». Cette option ne s’applique qu’aux connexions qui utilisent GSSAPI.

Cette option permet de spécifier que ssh(1) doit hacher les adresses et noms de machines lors de leur ajout à ~/.ssh/known_hosts. Ces noms hachés peuvent être utilisés normalement par ssh(1) et sshd(8), mais ils ne révèleront pas visuellement d’informations d’identification en cas de divulgation du contenu du fichier. La valeur par défaut est no. Notez que les adresses et noms préexistants dans le fichier des machines connues ne seront pas hachés automatiquement, mais pourront l’être manuellement à l’aide de ssh-keygen(1). L’utilisation de cette option peut rendre inopérants des outils comme la complétion par tabulation qui ne pourra fonctionner que si les noms de machine dans ~/.ssh/known_hosts ne sont pas hachés.
Cette option permet de spécifier les algorithmes de signature qui seront utilisés pour l’authentification basée sur la machine sous la forme d’une liste de motifs séparés par des virgules. Si la liste d’algorithmes spécifiée commence par le caractère « + », elle s’ajoutera à la liste par défaut au lieu de la remplacer. Si la liste d’algorithmes spécifiée commence par le caractère « - », elle sera supprimée (en tenant compte des caractères génériques) de la liste par défaut au lieu de la remplacer. Si la liste d’algorithmes spécifiée commence par un caret « ^ », elle sera placée à la tête de la liste par défaut. La liste d’algorithmes par défaut est : 
ssh-ed25519-cert-v01@openssh.com,
ecdsa-sha2-nistp256-cert-v01@openssh.com,
ecdsa-sha2-nistp384-cert-v01@openssh.com,
ecdsa-sha2-nistp521-cert-v01@openssh.com,
sk-ssh-ed25519-cert-v01@openssh.com,
sk-ecdsa-sha2-nistp256-cert-v01@openssh.com,
rsa-sha2-512-cert-v01@openssh.com,
rsa-sha2-256-cert-v01@openssh.com,
ssh-ed25519,
ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,
sk-ssh-ed25519@openssh.com,
sk-ecdsa-sha2-nistp256@openssh.com,
rsa-sha2-512,rsa-sha2-256

L’option -Q de ssh(1) permet d’afficher la liste des algorithmes de signature pris en charge. Elle se nommait auparavant HostbasedKeyTypes.

Cette option permet de spécifier si l’on tente d'utiliser l'authentification basée sur les rhosts avec l'authentification par clé publique. L'argument est yes ou no (la valeur par défaut).
Cette option permet de spécifier les algorithmes de signature de la clé d’hôte que le client souhaite utiliser par ordre de préférence. Si la liste d’algorithmes spécifiée commence par le caractère « + », elle s’ajoutera à la liste par défaut au lieu de la remplacer. Si la liste d’algorithmes spécifiée commence par le caractère « - », elle sera supprimée (en tenant compte des caractères génériques) de la liste par défaut au lieu de la remplacer. Si la liste d’algorithmes spécifiée commence par un caret « ^ », elle sera placée à la tête de la liste par défaut. La liste d’algorithmes par défaut est : 
ssh-ed25519-cert-v01@openssh.com,
ecdsa-sha2-nistp256-cert-v01@openssh.com,
ecdsa-sha2-nistp384-cert-v01@openssh.com,
ecdsa-sha2-nistp521-cert-v01@openssh.com,
sk-ssh-ed25519-cert-v01@openssh.com,
sk-ecdsa-sha2-nistp256-cert-v01@openssh.com,
rsa-sha2-512-cert-v01@openssh.com,
rsa-sha2-256-cert-v01@openssh.com,
ssh-ed25519,
ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,
sk-ecdsa-sha2-nistp256@openssh.com,
sk-ssh-ed25519@openssh.com,
rsa-sha2-512,rsa-sha2-256

Si les clés d’hôte sont connues pour la machine de destination, cette liste par défaut est modifiée

La liste des algorithmes de signature disponibles peut aussi être obtenue à l’aide de la commande « ssh -Q HostKeyAlgorithms ».

Cette option permet de spécifier un alias à utiliser à la place du vrai nom de machine lors des recherches et des sauvegardes de clé d’hôte dans les fichiers de base de données des clés d’hôte et lors de la validation de certificats de machines. Cette option s’avère utile pour faire passer des connexions SSH par un tunnel, ou si plusieurs serveurs tournent sur une seule machine.
Cette option permet de spécifier le vrai nom de la machine sur laquelle on se connecte. On peut l’utiliser pour spécifier des surnoms ou des diminutifs de machines. Les arguments de Hostname acceptent les symboles décrits dans la section SYMBOLES. Les adresses IP sont aussi autorisées, à la fois sur la ligne de commande et par les spécifications de cette option. La valeur par défaut est le nom donné sur la ligne de commande.
Cette option permet de spécifier que ssh(1) ne doit utiliser que les fichiers de certificats et d’identités d’authentification configurés (les fichiers par défaut ou ceux explicitement configurés dans les fichiers de ssh_config ou passés sur la ligne de commande de ssh(1)), même si ssh-agent(1), PKCS11Provider ou SecurityKeyProvider offrent davantage d’identités. L’argument doit être yes ou no (la valeur par défaut). Cette option est destinée aux situations où ssh-agent offre de nombreuses identités différentes.
Cette option permet de spécifier le socket de domaine Unix utilisé pour communiquer avec l’agent d’authentification.

Elle outrepasse la variable d’environnement SSH_AUTH_SOCK et permet de sélectionner un agent particulier. Définir le nom du socket à none a pour effet de désactiver l’utilisation d’un agent d’authentification. Si l’argument est « SSH_AUTH_SOCK », le chemin du socket sera extrait de la variable d’environnement SSH_AUTH_SOCK. Autrement, si l’argument commence par un caractère « $ », il sera traité en tant que variable d’environnement contenant le chemin du socket.

Les arguments de IdentityAgent peuvent utiliser la syntaxe avec tilde « ~ » pour faire référence au répertoire personnel d’un utilisateur, les symboles décrits dans la section SYMBOLES et les variables d’environnement décrites dans la section VARIABLES D’ENVIRONNEMENT.

Cette option permet de spécifier un fichier à partir duquel sera lue l’identité d’authentification DSA, ECDSA, ECDSA hébergée par un authentificateur, Ed25519, Ed25519 hébergée par un authentificateur ou RSA de l’utilisateur. Vous pouvez aussi spécifier un fichier de clé publique pour utiliser la clé privée correspondante chargée dans l’agent ssh-agent(1) lorsque le fichier de clé privée n’est pas présent en local. Les fichiers par défaut sont ~/.ssh/id_rsa, ~/.ssh/id_ecdsa, ~/.ssh/id_ecdsa_sk, ~/.ssh/id_ed25519, ~/.ssh/id_ed25519_sk et ~/.ssh/id_dsa. En outre, toute identité représentée par l’agent d’authentification pourra être utilisée pour l’authentification, sauf si IdentitiesOnly est définie. Si aucun certificat n’a été explicitement spécifié par CertificateFile, ssh(1) essaiera de charger les informations de certificat à partir du fichier dont le nom s’obtient en ajoutant -cert.pub au chemin du fichier spécifié à l’aide de IdentityFile.

Les arguments de IdentityFile peuvent utiliser la syntaxe avec tilde « ~ » pour faire référence au répertoire personnel d’un utilisateur ou les symboles décrits dans la section SYMBOLES. Sinon, un argument de valeur none permettra d’indiquer qu’aucun fichier d’identité ne doit être chargé.

Il est possible de spécifier plusieurs fichiers d’identité dans les fichiers de configuration ; toutes ces identités seront essayées séquentiellement. Les identités spécifiées par plusieurs directives IdentityFile s’ajouteront à la liste des identités essayées (ce comportement est différent de celui des autres directives de configuration).

IdentityFile peut être utilisée en combinaison avec IdentitiesOnly pour sélectionner les identités disponibles dans un agent lors de l’authentification. IdentityFile peut aussi être utilisée en combinaison avec CertificateFile pour fournir tout certificat nécessaire à l’authentification avec l’identité.

Cette option permet de spécifier une liste sous forme de motifs d’options inconnues qui devront être ignorées si elles sont rencontrées lors de l’interprétation de la configuration. Elle permet d’éviter la survenue d’erreurs au cas où ssh_config contiendrait des options non reconnues par ssh(1). Il est recommandé de placer la directive IgnoreUnknown au tout début du fichier de configuration, car elle ne s’applique qu’aux options qui apparaissent après elle.
Cette option permet d’inclure le(s) fichier(s) de configuration spécifié(s). Il est possible de spécifier plusieurs chemins de fichier, chacun d’entre eux pouvant contenir des caractères génériques de glob(7) et, pour les configurations utilisateur, des références au répertoire personnel de l’utilisateur sous forme d’un caractère tilde « ~ » (dans le style de l’interpréteur de commande). Les chemins avec caractères génériques seront évalués et les fichiers résultants traités par ordre lexical. Les fichiers dont le chemin est relatif sont supposés se trouver dans ~/.ssh s’ils sont inclus dans un fichier de configuration utilisateur, ou dans /etc/ssh s’ils sont inclus dans le fichier de configuration du système. La directive Include peut être placée dans un bloc Match ou Host afin d’effectuer une inclusion conditionnelle.
Cette option permet de spécifier le type de service (TOS) IPv4 ou la classe DSCP pour les connexions. Les valeurs possibles sont af11, af12, af13, af21, af22, af23, af31, af32, af33, af41, af42, af43, cs0, cs1, cs2, cs3, cs4, cs5, cs6, cs7, ef, le, lowdelay, throughput, reliability, une valeur numérique ou none qui est équivalent à la valeur par défaut du système d’exploitation. Cette option accepte un ou deux arguments séparés par un blanc. Si un seul argument est spécifié, il est utilisé comme classe de paquet sans condition. Si deux arguments sont spécifiés, le premier est automatiquement sélectionné pour les sessions interactives et le second pour les sessions non interactives. La valeur par défaut est lowdelay pour les sessions interactives et throughput pour les sessions non interactives.
Cette option permet d’indiquer l’utilisation de l’authentification interactive à l’aide du clavier. L’argument doit être yes (la valeur par défaut) ou no. ChallengeResponseAuthentication est un alias obsolète de cette option.
Cette option permet de spécifier une liste de méthodes pour utiliser l’authentification interactive à l’aide du clavier. Il est possible d’indiquer plusieurs noms de méthode, ces derniers devant être séparés par des virgules. Par défaut, c’est la liste spécifiée du serveur qui est utilisée. Les méthodes disponibles varient en fonction de ce que le serveur prend en charge. Pour un serveur OpenSSH par exemple, elles peuvent être égales à une ou plusieurs parmi bsdauth et pam.
Cette option permet de spécifier la liste des algorithmes d’échange de clés KEX (Key Exchange) disponibles. Les noms d’algorithme multiples doivent être séparés par des virgules. Si la liste d’algorithmes spécifiée commence par le caractère « + », elle s’ajoutera à la liste par défaut au lieu de la remplacer. Si la liste d’algorithmes spécifiée commence par le caractère « - », elle sera supprimée (en tenant compte des caractères génériques) de la liste par défaut au lieu de la remplacer. Si la liste d’algorithmes spécifiée commence par un caret « ^ », elle sera placée à la tête de la liste par défaut. La liste d’algorithmes par défaut est : 
sntrup761x25519-sha512@openssh.com,
curve25519-sha256,curve25519-sha256@libssh.org,
ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,
diffie-hellman-group-exchange-sha256,
diffie-hellman-group16-sha512,
diffie-hellman-group18-sha512,
diffie-hellman-group14-sha256

On peut aussi obtenir la liste des algorithmes d’échange de clés disponibles à l’aide de la commande « ssh -Q kex ».

Cette option permet de spécifier une commande permettant d’obtenir une liste de clés d’hôte venant s’ajouter à celles listées dans les fichiers UserKnownHostsFile et GlobalKnownHostsFile. Cette commande est exécutée une fois les fichiers lus. Elle peut afficher les lignes de clés de machine sur la sortie standard dans un format identique à celui des fichiers habituels (décrit dans la section VÉRIFIER LES CLÉS DE LA MACHINE de ssh(1)). Les arguments de KnownHostsCommand acceptent les symboles décrits dans la section SYMBOLES. La commande peut être invoquée plusieurs fois au cours d’une même connexion : une fois lors de la préparation de la liste des algorithmes de clés d’hôte préférés à utiliser, une autre fois pour obtenir la clé d’hôte pour le nom de machine demandé et une dernière fois, si CheckHostIP est activée, pour obtenir la clé d’hôte correspondant à l’adresse du serveur. Si la commande quitte anormalement ou renvoie un code de retour différent de zéro, la connexion est fermée.
Cette option permet de spécifier une commande à exécuter sur la machine locale après une connexion réussie au serveur. La commande s’étend jusqu’à la fin de la ligne et est exécutée avec l’interpréteur de commande de l’utilisateur. Les arguments de LocalCommand acceptent les symboles décrits dans la section SYMBOLES.

La commande est exécutée en mode synchrone et n’a pas accès à la session du ssh(1) qui l’a générée. Elle ne doit pas être utilisée pour les commandes interactives.

Cette directive est ignorée si PermitLocalCommand n’a pas été activée.

Cette option permet de spécifier qu'un port TCP sur la machine locale doit être redirigé par le tunnel sécurisé vers les machine et port spécifiés à partir de la machine distante. Le premier argument spécifie le point d’écoute et peut être [adr_sortie:]port ou le chemin d’un socket de domaine Unix. Le second argument spécifie la destination et peut être machine:port_machine ou le chemin d’un socket de domaine Unix si la machine distante le prend en charge.

On peut spécifier des adresses IPv6 en les entourant de crochets. Il est possible de spécifier plusieurs redirections et des redirections additionnelles peuvent être indiquées sur la ligne de commande. Seul le superutilisateur peut rediriger des ports privilégiés. Par défaut, le port local est lié en tenant compte de la définition de GatewayPorts. Il est cependant possible d’indiquer une adresse adr_sortie explicite pour lier la connexion à une adresse particulière. Une adresse adr_sortie égale à localhost indique que le port d’écoute ne doit être lié que pour un usage local, alors qu’une adresse vide ou « * » indique que le port sera disponible sur toutes les interfaces. Les chemins de socket de domaine Unix peuvent utiliser les symboles décrits dans la section SYMBOLES et les variables d’environnement comme décrit dans la section VARIABLES D’ENVIRONNEMENT.

Cette option permet de spécifier le niveau de prolixité qui sera utilisé lors de la journalisation des messages en provenance de ssh(1). Les valeurs possibles sont : QUIET, FATAL, ERROR, INFO, VERBOSE, DEBUG, DEBUG1, DEBUG2 et DEBUG3. La valeur par défaut est INFO. DEBUG et DEBUG1 sont équivalents. DEBUG2 et DEBUG3 correspondent à des niveaux supérieurs de prolixité pour la sortie.
Cette option permet de définir un ou plusieurs outrepassements de LogLevel. Un outrepassement consiste en une liste de motifs qui correspondent au fichier source, à la fonction et au numéro de ligne pour lesquels la journalisation sera plus détaillée. Par exemple, le motif d’outrepassement suivant : 
kex.c:*:1000,*:kex_exchange_identification():*,packet.c:*

activerait la journalisation détaillée pour la ligne 1000 de kex.c, tout ce qui concerne la fonction () et l’ensemble du code contenu dans le fichier packet.c. Cette option s’utilise à des fins de débogage et aucun outrepassement n’est activé par défaut.

Cette option permet de spécifier les algorithmes MAC (message authentication code) par ordre de préférence. L'algorithme MAC est utilisé pour la protection de l'intégrité des données. On peut spécifier plusieurs algorithmes en les séparant par des virgules. Si la liste d’algorithmes spécifiée commence par le caractère « + », elle s’ajoutera à la liste par défaut au lieu de la remplacer. Si la liste d’algorithmes spécifiée commence par le caractère « - », elle sera supprimée (en tenant compte des caractères génériques) de la liste par défaut au lieu de la remplacer. Si la liste d’algorithmes spécifiée commence par un caret « ^ », elle sera placée à la tête de la liste par défaut.

Les algorithmes dont le nom contient « -etm » calculent le MAC après chiffrement (encrypt-then-mac). Ils sont considérés comme plus sûrs et leur utilisation est recommandée.

La liste d’algorithmes par défaut est :

umac-64-etm@openssh.com,umac-128-etm@openssh.com,
hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,
hmac-sha1-etm@openssh.com,
umac-64@openssh.com,umac-128@openssh.com,
hmac-sha2-256,hmac-sha2-512,hmac-sha1

La liste des algorithmes MAC disponibles peut aussi être obtenue à l’aide de la commande « ssh -Q mac ».

Cette option permet de désactiver l’authentification de la machine pour localhost (les adresses loopback). L’argument doit être yes ou no (la valeur par défaut).
Cette option permet de spécifier le nombre de tentatives de saisie de mot de passe avant d'abandonner. L'argument doit être un entier et sa valeur par défaut est 3.
Cette option permet d’indiquer si ssh(1) doit essayer de dissimuler les délais entre frappes de touches aux observateurs passifs sur le réseau. Si elle est activée, pour les sessions interactives, ssh(1) va envoyer les frappes de touches à intervalles fixes de quelques dizaines de millisecondes et enverra des paquets de frappes de touches factices pendant un certain temps après que la frappe de touches a cessé. L’argument doit être yes, no ou un intervalle sous la forme interval:millisecondes (par exemple interval:80 pour 80 millisecondes). La valeur par défaut est de 20 millisecondes. Notez que des intervalles plus courts impliqueront des taux de paquets factices plus importants.
Cette option permet de spécifier si on utilise l'authentification par mot de passe. L'argument est yes (la valeur par défaut) ou no.
Cette option permet d’autoriser l’exécution de commandes locales à l’aide de l’option LocalCommand ou de la séquence d’échappement !commande dans ssh(1). L’argument doit être yes ou no (la valeur par défaut).
Cette option permet de spécifier les destinations vers lesquelles la redirection de port TCP distant est autorisée lorsque RemoteForward est utilisée comme mandataire SOCKS. La spécification de redirection doit être sous une des formes suivantes :

Il est possible de spécifier plusieurs redirections en les séparant par des blancs. Un argument de valeur any permet de lever toutes les restrictions et autorise toutes les requêtes de redirection. Un argument de valeur none permet d’interdire toute requête de redirection. Le caractère générique « * » à la place de machine ou port permet d’autoriser toute machine ou port, respectivement. Ces valeurs mises à part, aucune recherche d’adresse ou de correspondance de motif n’est effectuée sur les noms fournis.

Cette option permet de spécifier quel fournisseur PKCS#11 utiliser ou none pour indiquer qu’aucun fournisseur ne doit être utilisé (la valeur par défaut). L’argument doit contenir un chemin vers la bibliothèque partagée PKCS#11 que ssh(1) doit utiliser pour communiquer avec un jeton PKCS#11 fournissant des clés pour l’authentification de l’utilisateur.
Cette option permet de spécifier le numéro de port pour se connecter sur la machine distante. La valeur par défaut est 22.
Cette option permet d’indiquer l'ordre dans lequel le client doit essayer les méthodes d'authentification. Elle permet au client de choisir une méthode (par exemple keyboard-interactive) plutôt qu'une autre (par exemple password). L’ordre par défaut est : 
gssapi-with-mic,hostbased,publickey,
keyboard-interactive,password
Cette option permet de spécifier la commande à utiliser pour se connecter au serveur. La chaîne de caractères contenant la commande s’étend jusqu'à la fin de la ligne et est exécutée en utilisant la directive « exec » de l'interpréteur de commande de l’utilisateur pour éviter la persistance d’un processus d’interpréteur de commande.

Les arguments de ProxyCommand acceptent les symboles décrits dans la section SYMBOLES. La commande peut être quelconque, et doit lire depuis son entrée standard et écrire sur sa sortie standard. Elle doit en fin de compte se connecter sur un serveur sshd(8) tournant sur une machine quelconque, ou exécuter sshd -i sur une autre machine. La gestion des clés de machine est assurée en utilisant le nom de la machine (option Hostname) sur laquelle on se connecte (par défaut, le nom fourni par l'utilisateur). Un argument de valeur none désactive complètement cette option. Notez que CheckHostIP n'est pas disponible pour les connexions qui utilisent une commande mandataire (proxy command).

Cette directive s’avère particulièrement utile en combinaison avec nc(1) et sa prise en charge du mandatement. Par exemple, la directive suivante effectuerait une connexion par l’intermédiaire d’un mandataire HTTP à l’adresse 192.0.2.0 :

ProxyCommand /usr/bin/nc -X connect -x 192.0.2.0:8080 %h %p
Cette option permet de spécifier un ou plusieurs mandataires de saut soit sous la forme [utilisateur@]machine[:port], soit comme un URI ssh. Les mandataires multiples peuvent être séparés par des virgules et seront visités séquentiellement. Si cette option est définie, ssh(1) se connectera à la machine cible en établissant tout d’abord une connexion ssh(1) avec la machine ProxyJump spécifiée, puis en effectuant une redirection TCP vers la cible finale depuis le mandataire. Définir la machine à none désactive complètement cette option.

Notez que cette option entre en compétition avec l’option ProxyCommand selon la règle suivante : celle qui est définie en premier empêchera la prise en compte des instances ultérieures de l’autre.

Notez aussi que la configuration pour la machine de destination (fournie sur la ligne de commande ou dans le fichier de configuration) ne s’applique en général pas aux machines de saut. Une configuration spécifique pour les machines de saut nécessite l’utilisation de ~/.ssh/config.

Cette option permet d’indiquer que la commande définie par ProxyCommand va transmettre en retour un descripteur de fichier connecté à ssh(1) au lieu de continuer son exécution et de transmettre des données. Sa valeur par défaut est no.
Cette option permet de spécifier les algorithmes de signature qui seront utilisés pour l’authentification par clé publique sous la forme d’une liste de motifs séparés par des virgules. Si la liste d’algorithmes spécifiée commence par le caractère « + », elle s’ajoutera à la liste par défaut au lieu de la remplacer. Si la liste d’algorithmes spécifiée commence par le caractère « - », elle sera supprimée (en tenant compte des caractères génériques) de la liste par défaut au lieu de la remplacer. Si la liste d’algorithmes spécifiée commence par un caret « ^ », elle sera placée à la tête de la liste par défaut. La liste d’algorithmes par défaut est : 
ssh-ed25519-cert-v01@openssh.com,
ecdsa-sha2-nistp256-cert-v01@openssh.com,
ecdsa-sha2-nistp384-cert-v01@openssh.com,
ecdsa-sha2-nistp521-cert-v01@openssh.com,
sk-ssh-ed25519-cert-v01@openssh.com,
sk-ecdsa-sha2-nistp256-cert-v01@openssh.com,
rsa-sha2-512-cert-v01@openssh.com,
rsa-sha2-256-cert-v01@openssh.com,
ssh-ed25519,
ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,
sk-ssh-ed25519@openssh.com,
sk-ecdsa-sha2-nistp256@openssh.com,
rsa-sha2-512,rsa-sha2-256

La liste des algorithmes de signature disponibles peut aussi être obtenue à l’aide de la commande « ssh -Q PubkeyAcceptedAlgorithms ».

Cette option permet de spécifier si on utilise l'authentification par clé publique. L'argument est yes (la valeur par défaut), no, unbound ou host-bound. Les deux dernières options activent l’authentification par clé publique, tout en désactivant ou activant, respectivement, l’extension du protocole d’authentification d’OpenSSH « host-bound » requise pour les redirections ssh-agent(1) restreintes.
Cette option permet de spécifier la quantité maximale de données qui peuvent être envoyées ou reçues et optionnellement un temps maximal pouvant s’écouler au delà desquels la clé de session devra être renégociée. Le premier argument est spécifié en octets et peut comporter un suffixe parmi « K », « M » ou « G » pour indiquer respectivement des kilo-octets, des méga-octets et des giga-octets. La valeur par défaut est soit « 1G », soit « 4G » en fonction de l’algorithme de chiffrement. Le second argument optionnel est spécifié en secondes et peut utiliser toute unité documentée dans la section « FORMATS DE TEMPS » de sshd_config(5). La valeur par défaut de RekeyLimit est default none, ce qui signifie que la renégociation de la clé est effectuée après que la quantité de données par défaut de l’algorithme de chiffrement a été envoyée ou reçue et sans tenir compte du temps écoulé.
Cette option permet de spécifier une commande à exécuter sur la machine distante après une connexion réussie au serveur. La chaîne représentant la commande s’étend jusqu’à la fin de la ligne et est exécutée avec l’interpréteur de commande de l’utilisateur. Les arguments de RemoteCommand acceptent les symboles décrits dans la section SYMBOLES.
Cette option permet de spécifier qu'un port TCP sur la machine distante doit être redirigé par le tunnel sécurisé. Le port distant peut être redirigé vers une machine et un port spécifiques depuis la machine locale ou peut agir en tant que mandataire SOCKS 4/5 qui permet à un client distant de se connecter à des destinations arbitraires depuis la machine locale. Le premier argument représente les spécifications d’écoute et peut contenir [adr_sortie:]port ou, si la machine distante le prend en charge, le chemin d’un socket de domaine Unix. Si la redirection s’effectue vers une destination spécifique, le second argument doit contenir machine:port_machine ou le chemin d’un socket de domaine Unix ; si aucun argument destination n’est spécifié, la redirection distante sera établie en tant que mandataire SOCKS. Lorsqu’elle agit en tant que mandataire SOCKS, la destination de la connexion peut être restreinte à l’aide de PermitRemoteOpen.

Les adresses IPv6 doivent être entourées de crochets. Il est possible de spécifier plusieurs redirections et des redirections additionnelles peuvent être indiquées sur la ligne de commande. Les ports privilégiés ne peuvent être redirigés que si l’on se connecte en tant que superutilisateur sur la machine distante. Les chemins de sockets de domaine Unix peuvent utiliser les symboles décrits dans la section SYMBOLES et les variables d’environnement comme décrit dans la section VARIABLES D’ENVIRONNEMENT.

Si l’argument port est égal à 0, le port d’écoute sera alloué dynamiquement sur le serveur et indiqué au client à l’exécution.

Si l’adresse adr_sortie n’est pas spécifiée, le comportement par défaut consiste à ne se lier qu’aux adresses de bouclage (loopback). Si l’adresse adr_sortie est vide ou égale à « * », la redirection écoutera toutes les interfaces. Spécifier une adresse adr_sortie distante ne réussira que si l’option du serveur GatewayPorts est activée (voir sshd_config(5)).

Cette option permet d’indiquer si l’on demande un pseudo-terminal pour la session. L’argument peut avoir une des valeurs suivantes : no (ne jamais demander de terminal), yes (toujours demander un terminal lorsque l’entrée standard est un terminal), force (toujours demander un terminal) ou auto (demander un terminal lors de l’ouverture d’une session de connexion). Cette option est équivalente aux drapeaux -t et -T de ssh(1).
Cette option permet de spécifier une taille minimale (en bits) pour la clé RSA. Les clés d’authentification utilisateur d’une taille inférieure à cette valeur seront ignorées. De même, si un serveur présente une clé d’hôte d’une taille inférieure à cette valeur, le processus de connexion sera interrompu. La valeur par défaut est de 1024  bits. Notez que cette option ne peut être définie qu’à une valeur supérieure à la valeur par défaut.
Cette option permet de spécifier des clés publiques de machine révoquées. Les clés contenues dans le fichier indiqué seront rejetées lors d’une authentification de machine. Notez que si ce fichier n’existe pas ou est illisible, l’authentification sera refusée pour toutes les machines. Les clés peuvent être spécifiées sous la forme d’un fichier texte avec une clé par ligne ou d’une liste de révocations de clés (« Key Revocation List » — KRL) d’OpenSSH comme générée par ssh-keygen(1). Pour plus d’informations à propos des KRL, voir la section « LISTES DE RÉVOCATIONS DE CLÉS » de ssh-keygen(1). Les arguments peuvent utiliser la syntaxe avec tilde « ~ » pour faire référence au répertoire personnel d’un utilisateur, les symboles décrits dans la section SYMBOLES et les variables d’environnement comme décrit dans la section VARIABLES D’ENVIRONNEMENT.
Cette option permet de spécifier le chemin de la bibliothèque qui sera utilisée lors du chargement de toute clé FIDO (Fast Identity Online) hébergée par un authentificateur, ce qui outrepasse le comportement par défaut qui consiste à utiliser la prise en charge de USB HID (USB human interface device) incluse.

Si la valeur spécifiée commence par un caractère « $ », elle sera traitée comme une variable d’environnement contenant le chemin de la bibliothèque.

Cette option permet de spécifier les variables de l’environnement local environ(7) qui doivent être envoyées au serveur. Le serveur doit aussi le prendre en charge et être configuré pour accepter ces variables d’environnement. Notez que la variable d’environnement TERM est envoyée chaque fois qu'un pseudo-terminal est demandé, comme l'exige le protocole. Veuillez vous référer à l’option AcceptEnv dans sshd_config(5) pour savoir comment configurer le serveur. Les variables sont spécifiées par leur nom qui peut contenir des caractères génériques. Pour spécifier plusieurs variables d’environnement, vous pouvez les séparer par des blancs ou utiliser plusieurs fois l’option SendEnv.

Voir MOTIFS pour plus d’informations à propos des motifs.

Il est possible d’annuler une définition précédente de nom de variable avec SendEnv en préfixant le motif avec le caractère « - ». Par défaut, aucune variable d’environnement n’est envoyée.

Cette option permet de définir le nombre de messages de rappel au serveur (voir ci-dessous) qui peuvent être envoyés sans que ssh(1) reçoive de message en retour du serveur. Si cette limite est atteinte alors que des messages de rappel au serveur sont envoyés, ssh se déconnectera du serveur en fermant la session. Il est important de noter que l’utilisation de messages de rappel au serveur est très différente de TCPKeepAlive (voir ci-dessous). Les messages de rappel au serveur sont envoyés par le canal chiffré et ne peuvent donc pas être compromis. L’option « keepalive » de TCP activée par TCPKeepAlive peut être compromise. Le mécanisme de rappel au serveur s’avère utile lorsque le client ou le serveur ont besoin d’être informés quand une connexion ne répond plus.

La valeur par défaut est de 3. Si, par exemple, ServerAliveInterval (voir ci-dessous) est définie à 15 et si on laisse ServerAliveCountMax à sa valeur par défaut, ssh se déconnectera après approximativement 45 secondes si le serveur ne répond plus.

Cette option permet de définir un délai en secondes après lequel, si aucune donnée n’a été reçue du serveur, ssh(1) va envoyer un message par le canal chiffré pour demander une réponse au serveur. La valeur par défaut est 0 et indique qu’aucun message de ce type ne sera envoyé au serveur, ou 300 si l’option BatchMode est définie (spécifique à Debian). ProtocolKeepAlives et SetupTimeOut sont des alias de cette option à titre de compatibilité et sont spécifiques à Debian.
Cette option permet de demander l’invocation d’un sous-système sur le système distant ou d’empêcher l’exécution de toute commande distante. Cette dernière utilisation ne s’avère utile que pour rediriger des ports. L’argument doit être égal à none (même effet que l’option -N), subsystem (même effet que l’option -s) ou default (exécution d’une commande ou d’un interpréteur de commande).
Cette option permet de spécifier directement une ou plusieurs variables d’environnement à envoyer au serveur ainsi que leur contenu. Comme avec SendEnv, excepté pour la variable TERM, le serveur doit être préparé à accepter les variables d’environnement.
Cette option permet de rediriger l’entrée standard « stdin » vers /dev/null (ce qui revient à empêcher toute lecture à partir de l’entrée standard). Cette option doit être définie ou son équivalent -n spécifié lorsque ssh s’exécute en arrière-plan. L’argument doit être égal à yes (même effet que l’option -n) ou no (la valeur par défaut).
Cette option permet de définir le masque du mode de création de fichier en octal (umask) utilisé lors de la création d’un fichier socket de domaine Unix pour la redirection de port local ou distant. Cette option ne s’utilise que pour la redirection de port vers un fichier socket de domaine Unix.

La valeur par défaut est 0177, ce qui crée un fichier socket de domaine Unix qui n’est accessible en lecture et écriture que par son propriétaire. Notez que tous les systèmes d’exploitation ne prennent pas en charge le mode de fichier pour les fichiers socket de domaine Unix

Cette option permet de spécifier si le fichier socket de domaine Unix existant pour la redirection de port local ou distant doit être supprimé avant d’en créer un nouveau. Si le fichier socket existe déjà et si StreamLocalBindUnlink n’est pas activée, ssh ne pourra pas rediriger le port vers le fichier socket de domaine Unix. Cette option ne s’utilise que pour la redirection de port vers un fichier socket de domaine Unix.

L’argument doit être égal à yes ou no (la valeur par défaut).

Si cette option a pour argument yes, ssh(1) n'ajoutera jamais automatiquement de clés d’hôte au fichier ~/.ssh/known_hosts et refusera de se connecter aux machines dont la clé d’hôte a changé. Cette option fournit une protection maximale contre les attaques de type « Homme du milieu » (man-in-the-middle — MITM), mais peut néanmoins s’avérer gênante si le fichier /etc/ssh/ssh_known_hosts n'est pas très bien entretenu, ou si on se connecte fréquemment à de nouvelles machines. Cette option impose à l'utilisateur d'ajouter manuellement toutes les nouvelles machines.

Si cette option a pour argument accept-new, ssh(1) ajoutera automatiquement les nouvelles clés d’hôte au fichier known_hosts de l’utilisateur, mais n’autorisera pas les connexions vers les machines dont la clé a changé. Si cette option a pour argument no ou off, ssh(1) ajoutera automatiquement les nouvelles clés d’hôte aux fichiers des machines connues de l’utilisateur et autorisera les connexions vers les machines dont la clé a changé, avec certaines restrictions. Si cette option a pour argument ask (la valeur par défaut), les nouvelles clés d’hôte ne seront ajoutées aux fichiers des machines connues de l’utilisateur que si l'utilisateur confirme que c'est ce qu'il souhaite, et ssh(1) refusera de se connecter aux machines dont la clé a changé. Les clés d’hôte connues seront automatiquement vérifiées dans tous les cas.

Cette option permet de spécifier le code de catégorie (« facility ») utilisé lors de la journalisation des messages de ssh(1). Les valeurs possibles sont : DAEMON, USER, AUTH, LOCAL0, LOCAL1, LOCAL2, LOCAL3, LOCAL4, LOCAL5, LOCAL6 et LOCAL7. Le code par défaut est USER.
Cette option permet d’indiquer si le système doit envoyer des messages de rappel TCP à l’autre extrémité de la connexion. Si ces messages sont envoyés, la mort de la connexion ou le plantage d’une des machines seront notifiés de manière appropriée. Cela signifie cependant que la connexion mourra si la route est momentanément interrompue, et certains utilisateurs trouvent cela gênant. Cette option n’utilise que des rappels TCP (par opposition aux rappels de ssh(1))  ; il lui faut donc un temps assez long pour détecter la mort d’une connexion. À ce sujet, vous pouvez utiliser l’option ServerAliveInterval en combinaison avec cette option.

La valeur par défaut est yes (envoyer des messages de rappel TCP), et le client sera ainsi informé si le réseau tombe ou si la machine distante se plante. Être informé de ces problèmes s’avère important dans les scripts et de nombreux utilisateurs souhaitent aussi que cette information soit disponible.

Pour désactiver l’envoi de messages de rappel TCP, cette option doit être définie à no. Voir aussi ServerAliveInterval pour les signes de vie niveau protocole.

Cette option permet de spécifier un nom de symbole de configuration qui pourra être utilisé ensuite par la directive Match pour sélectionner un bloc de configuration.
Cette option permet de demander la redirection par dispositif de tunnel tun(4) entre le client et le serveur. L’argument doit être égal à yes, point-to-point (couche 3), ethernet (couche 2) ou no (la valeur par défaut). Spécifier yes demande le mode de tunnel par défaut, à savoir point-to-point.
Cette option permet de spécifier le dispositif tun(4) à ouvrir sur le client ( (tunnel_local)) et sur le serveur ( (tunnel_distant)).

L’argument doit être de la forme tunnel_local[:tunnel_distant]. Les dispositifs de tunnel peuvent être spécifiés par leur ID numérique ou le mot-clé any, ce dernier demandant l’utilisation du premier dispositif de tunnel disponible. Si tunnel_distant n’est pas spécifié, sa valeur par défaut est any. La valeur par défaut de cette option est any:any.

Cette option permet de spécifier si ssh(1) doit accepter d’ajouter au fichier UserKnownHostsFile des clés d’hôte additionnelles notifiées par le serveur et envoyées une fois l’authentification terminée. L’argument doit être égal à yes, no ou ask. Cette option permet d’enregistrer des clé d’hôte de remplacement pour un serveur et prend en charge une rotation des clés en douceur en ce sens qu’elle permet à un serveur d’envoyer des clés publiques de remplacement avant que les anciennes soient supprimées.

Les clés d’hôte additionnelles ne sont acceptées que si la clé ayant servi à authentifier la machine était fiable ou a été explicitement acceptée par l’utilisateur, si la machine a été authentifiée à l’aide du fichier UserKnownHostsFile (pas GlobalKnownHostsFile) et si la machine a été authentifiée en utilisant une clé explicite et non un certificat.

L’option UpdateHostKeys est activée par défaut si l’utilisateur n’a pas modifié la définition par défaut de UserKnownHostsFile et n’a pas activé VerifyHostKeyDNS  ; dans le cas contraire, UpdateHostKeys sera définie à no.

Si l’option UpdateHostKeys est définie à ask, l’utilisateur devra confirmer les modifications à apporter au fichier UserKnownHostsFile. Actuellement, cette confirmation est incompatible avec l’option ControlPersist et sera désactivée si cette dernière est activée.

Actuellement, seul sshd(8) d’OpenSSH versions 6.8 et supérieures prend en charge l’extension de protocole « hostkeys@openssh.com » utilisée pour informer le client de toutes les clés d’hôte du serveur.

Cette option permet de spécifier un nom d'utilisateur à utiliser pour se connecter. Cela peut s’avérer utile si on se connecte avec des noms d'utilisateurs différents sur les différentes machines, et évite le souci de devoir se rappeler de passer le nom d'utilisateur sur la ligne de commande.
Cette option permet de spécifier un ou plusieurs fichiers à utiliser pour la base de données des clés d’hôte de l'utilisateur, séparés par des blancs. Chaque nom de fichier peut utiliser la syntaxe avec tilde « ~ » pour faire référence au répertoire personnel d’un utilisateur, les symboles décrits dans la section SYMBOLES et les variables d’environnement comme décrit dans la section VARIABLES D’ENVIRONNEMENT. Si cette option est définie à none, ssh(1) ignorera tout fichier de machines connues spécifique à l’utilisateur. Les fichiers par défaut sont ~/.ssh/known_hosts et ~/.ssh/known_hosts2.
Cette option permet de spécifier si la clé distante doit être vérifiée en utilisant les enregistrements de ressource DNS et SSHFP. Si elle est définie à yes, le client va implicitement considérer comme fiables les clés qui correspondent à une empreinte sécurisée en provenance du DNS. Les empreintes non sécurisées seront traitées comme si cette option avait été définie à ask. Si elle est définie à ask, les informations de correspondance d’empreinte seront affichées, mais, en fonction de la définition de l’option StrictHostKeyChecking, l’utilisateur devra quand même confirmer les nouvelles clés d’hôte. La valeur par défaut est no.

Voir aussi VÉRIFIER LES CLÉS DE LA MACHINE dans ssh(1).

Si cette option est définie à yes, une représentation en art ASCII de l’empreinte de la clé d’hôte distante sera affichée en plus de la chaîne d’empreinte à la connexion et pour les clés d’hôte inconnues. Si elle est définie à no (la valeur par défaut), aucune chaîne d’empreinte ne sera affichée à la connexion et seule la chaîne d’empreinte sera affichée pour les clés d’hôte inconnues.
Cette option permet de spécifier le nom de chemin complet du programme xauth(1). Le chemin par défaut est /usr/bin/xauth.

MOTIFS

Un consiste en zéro ou plusieurs caractères non blancs, le caractère « * » (un caractère générique qui correspond à zéro ou plusieurs caractères) ou « ? » (un caractère générique qui correspond à exactement un caractère). Par exemple, pour spécifier un jeu de déclarations pour toute machine des domaines en « .co.uk », on pourrait utiliser le motif suivant :

Host *.co.uk

Le motif suivant correspondrait à toute machine dans l’intervalle d’adresses réseau 192.168.0.[0-9] :

Host 192.168.0.?

Une liste de motifs contient une liste de motifs séparés par des virgules. Dans une liste de motifs, chacun d’entre eux peut être nié en le faisant précéder d’un point d’exclamation « ! ». Par exemple, pour autoriser l’utilisation d’une clé depuis n’importe où dans une organisation sauf depuis l’ensemble « dialup », on pourrait utiliser l’entrée d’authorized_keys suivante :

from="!*.dialup.example.com,*.example.com"

Notez qu’une correspondance niée ne produira jamais de résultat positif d’elle-même. Par exemple, essayer de faire correspondre « host3 » à la liste de motifs suivante échouera toujours :

from="!host1,!host2"

La solution consiste ici à inclure un terme qui va produire une correspondance positive, comme un caractère générique :

from="!host1,!host2,*"

SYMBOLES

Les arguments de certaines options peuvent utiliser des symboles qui sont interprétés à l’exécution :

%%
Le caractère « % ».
%C
Le hachage de %l%h%p%r%j.
%d
Le répertoire personnel de l’utilisateur local.
%f
L’empreinte de la clé d’hôte du serveur.
%H
Le nom ou l’adresse de machine recherché dans le fichier known_hosts.
%h
Le nom de la machine distante.
%I
Une chaîne décrivant la raison pour laquelle une commande KnownHostsCommand est exécutée : ADDRESS lorsqu’on recherche une machine par son adresse (seulement si CheckHostIP est activée), HOSTNAME lorsqu’on recherche une machine par son nom ou ORDER lors de la préparation de la liste d’algorithmes de clé d’hôte préférés à utiliser pour la machine de destination.
%i
L’UID local.
%j
La valeur de l’option ProxyJump ou une chaîne vide si cette option n’est pas définie.
%K
La clé d’hôte codée en base64.
%k
L’alias de la clé d’hôte si elle a été spécifiée, ou le nom originel de la machine distante donné sur la ligne de commande dans le cas contraire.
%L
Le nom de la machine locale.
%l
Le nom complet de la machine locale, domaine inclus.
%n
Le nom originel de la machine distante tel qu’il a été spécifié sur la ligne de commande.
%p
Le port distant.
%r
Le nom de l’utilisateur distant.
%T
L’interface réseau locale tun(4) ou tap(4) assignée si la redirection par tunnel a été demandée, ou « NONE » dans le cas contraire.
%t
Le type de la clé d’hôte du serveur, par exemple ssh-ed25519.
%u
Le nom de l’utilisateur local.

Les options CertificateFile, ControlPath, IdentityAgent, IdentityFile, KnownHostsCommand, LocalForward, Match exec, RemoteCommand, RemoteForward, RevokedHostKeys et UserKnownHostsFile acceptent les symboles %%, %C, %d, %h, %i, %j, %k, %L, %l, %n, %p, %r et %u.

L’option KnownHostsCommand accepte en plus les symboles %f, %H, %I, %K et %t.

L’option Hostname accepte les symboles %% et %h.

L’option LocalCommand accepte tous les symboles.

Les options ProxyCommand et ProxyJump acceptent les symboles %%, %h, %n, %p et %r.

Notez que certaines de ces directives construisent des commandes destinées à être exécutées à l’aide de l’interpréteur de commande, et comme ssh(1) n’effectue aucun filtrage ou échappement des caractères qui ont une signification spéciale dans les commandes de l’interpréteur de commande (comme les guillemets), il est de la responsabilité de l’utilisateur de s’assurer que les arguments passés à ssh(1) ne contiennent pas de caractères de cette sorte et de faire en sorte que les symboles soient mis entre guillemets de manière appropriée lorsqu’ils sont utilisés.

VARIABLES D'ENVIRONNEMENT

Les arguments de certaines options peuvent être interprétés à l’exécution par l’évaluation des variables d’environnement du client en englobant ces dernières avec ${}  ; par exemple, ${HOME}/.ssh ferait référence au répertoire .ssh de l’utilisateur. Si une variable d’environnement spécifiée n’existe pas, une erreur sera renvoyée et la définition de l’option concernée sera ignorée.

Les options CertificateFile, ControlPath, IdentityAgent, IdentityFile, KnownHostsCommand et UserKnownHostsFile prennent en charge les variables d’environnement. Les options LocalForward et RemoteForward ne prennent en charge les variables d’environnement que pour les chemins de socket de domaine Unix.

FICHIERS

~/.ssh/config
C’est le fichier de configuration propre à l’utilisateur. Son format est décrit ci-dessus. Ce fichier est utilisé par le client SSH. En raison du risque de piratage, ce fichier doit avoir des permissions strictes : accessible en lecture/écriture pour l’utilisateur et non accessible en écriture pour les autres. Il peut être accessible en écriture pour le groupe, pourvu que le groupe en question ne contienne que l’utilisateur.
/etc/ssh/ssh_config
C’est le fichier de configuration globale du système. Il fournit les valeurs par défaut des options tant pour celles qui ne sont pas définies dans le fichier de configuration de l’utilisateur que pour les utilisateurs qui ne possèdent pas de fichier de configuration. Il doit être accessible en lecture par tout le monde.

VOIR AUSSI

ssh(1)

AUTEURS

OpenSSH est dérivé de la version originale et libre 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 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.

TRADUCTION

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

Cette traduction est une documentation libre ; veuillez vous reporter à la GNU General Public License version 3 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

$Mdocdate: 21 février 2024 $ Debian