Scroll to navigation

SSH(1) General Commands Manual SSH(1)

NOM

ssh — Client de connexion à distance d’OpenSSH

SYNOPSIS

ssh [-46AaCfGgKkMNnqsTtVvXxYy] [-B interface_sortie] [-b adr_sortie] [-c algos_chiffrement] [-D [adr_sortie:]port] [-E fichier_journal] [-e caractère_échappement] [-F fichier_configuration] [-I pkcs11] [-i fichier_identité] [-J destination] [-L adresse] [-l nom_connexion] [-m algos_MAC] [-O commande_de_contrôle] [-o option] [-P symbole] [-p port] [-R adresse] [-S socket_contrôle] [-W machine:port] [-w tunnel_local[:tunnel_distant]] destination [commande [argument ...]]

ssh [-Q option_requête]

DESCRIPTION

ssh (le client SSH) est un programme permettant de se connecter à une machine distante et d’exécuter des commandes sur cette dernière. Il a pour but d’établir des communications chiffrées sécurisées entre deux machines non dignes de confiance sur un réseau non sécurisé. Les connexions X11, les ports TCP arbitraires et les sockets de domaine UNIX peuvent aussi transiter par le canal sécurisé.

ssh se connecte et s’identifie sur la machine destination qui peut être spécifiée à l’aide de [utilisateur@]nommachine ou d’un URI de la forme ssh://[utilisateur@]nommachine[:port]. L’utilisateur doit prouver son identité auprès de la machine distante en utilisant une méthode parmi plusieurs (voir ci-dessous).

Si une commande est spécifiée, elle sera exécutée sur la machine distante à la place d’un interpréteur de commande de connexion. commande peut correspondre à une ligne de commande complète ou posséder des arguments additionnels. S’ils sont présents, ces arguments seront ajoutés à la commande, séparés par des espaces, avant que cette dernière soit envoyée à la machine distante pour y être exécutée.

Les options sont les suivantes :

Forcer ssh à n’utiliser que des adresses IPv4.

Forcer ssh à n’utiliser que des adresses IPv6.

Active la redirection des connexions depuis un agent d'authentification comme ssh-agent(1). Cette option peut aussi être définie machine par machine dans un fichier de configuration.

La redirection d’agent doit être activée avec précaution. En effet, les utilisateurs capables de court-circuiter les permissions de fichier sur la machine distante (pour le socket de domaine UNIX de l’agent) peuvent accéder à l’agent local à travers la connexion transférée. Même si un attaquant ne pourra pas obtenir de clés depuis l’agent, il pourra tout de même effectuer des opérations sur les clés qui lui permettront de s’authentifier en utilisant les identités chargées dans l’agent. Une alternative plus sûre consiste à utiliser une machine de saut (voir -J).

Désactive la redirection de connexion de l’agent d’authentification.

interface_sortie
Préciser l’adresse de l’interface interface_sortie avant de tenter une connexion vers la machine distante. Cette option n’est utile que sur les systèmes qui possèdent plusieurs adresses.

adr_sortie
Utiliser l’adresse adr_sortie 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.

Requiert la compression de toutes les données (y compris stdin, stdout, stderr et les données pour les connexions redirigées X11, TCP et de domaine UNIX). L’algorithme de compression est le même que celui utilisé par gzip(1). La compression est souhaitable sur les lignes modem ou autres connexions lentes, mais elle ne fera que ralentir le trafic si elle est activée sur un réseau rapide. On peut aussi spécifier la valeur par défaut machine par machine dans les fichiers de configuration ; voir l’option Compression dans ssh_config(5).

algos_chiffrement
Spécifie les algorithmes de chiffrement à utiliser pour chiffrer la session. algos_chiffrement est une liste d’algorithmes de chiffrement séparés par des virgules et présentés par ordre de préférence. Voir le mot-clé Ciphers dans ssh_config(5) pour plus d’informations.

[adr_sortie:]port
Spécifie une redirection de port local « dynamique » au niveau applicatif. Le fonctionnement consiste à allouer un socket pour écouter le port côté local, optionnellement associé à l’adresse adr_sortie indiquée. Chaque fois qu’une connexion est effectuée vers ce port, elle est transférée par le canal sécurisé et le protocole applicatif est alors utilisé pour déterminer vers où se connecter depuis la machine distante. Actuellement, les protocoles SOCKS4 et SOCKS5 sont pris en charge et ssh se comporte comme un serveur SOCKS. Seul le superutilisateur peut rediriger des ports privilégiés. On peut aussi spécifier des redirections de port dynamiques dans le fichier de configuration.

On peut spécifier des adresses IPv6 en les entourant de crochets. Seul le superutilisateur peut rediriger des ports privilégiés. Par défaut, le port local est lié en accord avec la définition de GatewayPorts. On peut cependant utiliser une adresse adr_sortie explicite pour lier la connexion à une adresse spécifique. L’adresse adr_sortie de « localhost » indique que le port d’écoute ne pourra être lié que pour un usage local, alors qu’une adresse vide ou « * » indique que le port sera disponible depuis toutes les interfaces.

fichier_journal
Ajoute les informations de débogage au fichier_journal au lieu de les envoyer sur la sortie d’erreur standard.

caractère_échappement
Spécifie le caractère d’échappement pour les sessions avec un pseudo-terminal (pty). Le caractère par défaut est « ~ ». Le caractère d’échappement suivi d’un point « . » ferme la connexion ; suivi de Contrôle-Z, il la suspend et suivi de lui-même, il envoie le caractère d’échappement une fois. En définissant le caractère d’échappement à « none », on désactive tout échappement et on rend la session totalement transparente.

fichier_configuration
Spécifie un autre fichier de configuration par utilisateur. Si on fournit un fichier de configuration dans la ligne de commande, le fichier global (/etc/ssh/ssh_config) est ignoré. L’emplacement par défaut pour le fichier de configuration utilisateur est ~/.ssh/config. Si cette option est définie à « none », aucun fichier de configuration ne sera lu.

Demande à ssh de basculer en arrière-plan juste avant d’exécuter la commande. Cette option est particulièrement utile si ssh est appelé à demander des mots de passe ou des phrases de passe, alors que l’utilisateur souhaite que cela s’effectue en arrière-plan. Elle implique l’option -n. La méthode recommandée pour exécuter des programmes X11 sur une machine distante pourrait ressembler à : ssh -f machine xterm.

Si l’option de configuration ExitOnForwardFailure est définie à « yes », un client démarré avec l’option -f attendra que toutes les redirections de port distant soient effectuées avec succès avant de se placer lui-même en arrière-plan. Voir la description de ForkAfterAuthentication dans ssh_config(5) pour les détails.

Demande à ssh d’afficher sa configuration après évaluation des blocs Host et Match puis de quitter.

Permet à des machines distantes de se connecter à des ports redirigés locaux. Si elle est utilisée sur une connexion multiplexée, cette option doit être spécifiée sur le processus maître.

pkcs11
Spécifie la bibliothèque partagée PKCS#11 que ssh devra utiliser pour communiquer avec un jeton PKCS#11 fournissant des clés pour l’authentification utilisateur.

fichier_identité
Spécifie un fichier à partir duquel l’identité (la clé privée) pour l’authentification de la clé publique est lue. Vous pouvez aussi spécifier un fichier de clé publique pour utiliser la clé privée correspondante chargée dans ssh-agent(1) lorsque le fichier de la 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, et ~/.ssh/id_ed25519_sk. On peut aussi spécifier l’emplacement des fichiers d’identité pour une machine donnée dans le fichier de configuration. On peut spécifier plusieurs options -i (et plusieurs identités dans les fichiers de configuration). Si aucun certificat n’a été explicitement spécifié à l’aide de la directive CertificateFile, ssh va tenter de charger les informations de certificat à partir du fichier dont le nom sera obtenu en ajoutant -cert.pub aux noms des fichiers d’identité.

destination
Se connecter à la machine cible en établissant tout d’abord une connexion ssh vers la machine de saut indiquée par destination, puis en effectuant une redirection TCP vers la destination finale depuis la machine de saut. Il est possible de spécifier plusieurs sauts successifs en les séparant par des virgules. Il est possible de spécifier des adresses IPv6 en les entourant de crochets. Cette option est un raccourci pour définir une directive de configuration ProxyJump. Notez que les directives de configuration fournies sur la ligne de commande s’appliquent en général à la machine de destination et à aucune des machines de saut éventuellement indiquées. Pour définir des directives de configuration qui s’appliquent aux machines de saut, utilisez le fichier ~/.ssh/config.

Active l’authentification basée sur GSSAPI et les transferts (délégations) d’identifiants GSSAPI vers le serveur.

Désactive les transferts (délégations) d’identifiants GSSAPI vers le serveur.

[adr_sortie:]port:machine:port_machine
 
[adr_sortie:]port:socket_distant
 
socket_local:machine:port_machine
 
socket_local:socket_distant
Indique que les connexions vers le port TCP ou le socket Unix donné de la machine locale (client) seront transférées vers la machine et le port donnés ou le socket Unix sur la machine distante. Ce processus fonctionne grâce à l’allocation d’un socket qui écoute soit un port TCP de la machine locale éventuellement lié à l’adresse adr_sortie spécifiée, soit un socket Unix. Dès qu’une connexion est établie sur le port local ou le socket, elle est transférée à travers le canal sécurisé, et une connexion est établie vers le port_machine de la machine ou le socket Unix socket_distant depuis la machine distante.

Les redirections de port peuvent aussi être définies dans le fichier de configuration. Seul le superutilisateur peut transférer des ports privilégiés. Il est possible de spécifier des adresses IPv6 en les entourant de crochets.

Par défaut, le port local est lié en accord avec la définition de GatewayPorts. On peut cependant indiquer une adresse adr_sortie explicite pour lier la connexion à une adresse spécifique. L’adresse adr_sortie « localhost » indique que le port local ne peut être lié que pour un usage local, alors qu’une adresse vide ou « * » indique que le port sera disponible sur toutes les interfaces.

nom_connexion
Indique le nom d’utilisateur sous lequel se connecter à la machine distante. Il peut aussi être spécifié pour une machine donnée dans le fichier de configuration.

Place le client ssh en mode « master » pour le partage de connexion. Spécifier plusieurs options -M place le client ssh en mode « master », mais avec demande de confirmation en utilisant ssh-askpass(1) avant toute opération qui modifie l’état du multiplexage (par exemple ouvrir une nouvelle session). Voir la description de ControlMaster dans ssh_config(5) pour les détails.

algos_MAC
Une liste d’algorithmes MAC (message authentication code, code d’authentification de message) séparés par des virgules et classés par ordre de préférence. Voir le mot-clé MACs dans ssh_config(5) pour plus d’informations.

N’exécute aucune commande distante. Utilisé pour les redirections de ports. Voir la description de SessionType dans ssh_config(5) pour les détails.

Redirige l’entrée standard vers /dev/null (en fait, empêche la lecture depuis l’entrée standard). À utiliser lorsque ssh s’exécute en arrière-plan. Cette option peut s’avérer utile pour exécuter des programmes X11 sur une machine distante. Par exemple, ssh -n shadows.cs.hut.fi emacs & démarre emacs sur shadows.cs.hut.fi, et la connexion X11 est transférée automatiquement à travers un canal crypté. Le programme ssh est basculé en arrière-plan. Ne fonctionne cependant pas si ssh nécessite un mot de passe ou une phrase de passe ; voir aussi l’option -f. Consulter la description de StdinNull dans ssh_config(5) pour les détails.

commande_de_contrôle
Contrôler un processus actif maître de multiplexage de connexion. Lorsque l’option -O est spécifiée, l’argument commande_de_contrôle est interprété et transmis au processus maître. Les commandes valables sont : « check » (vérifie que le processus maître est en cours d’exécution), « forward » (redirection sans exécution de commande), « cancel » (annulation des redirections), « exit » (demande au processus maître de quitter) et « stop » (demande au processus maître de ne plus accepter de demandes de multiplexage ultérieures).

option
Cette option permet de spécifier des options dans le format du fichier de configuration et qui n’ont pas d’équivalent en ligne de commande. Pour plus de détails sur les options listées ci-après, ainsi que les valeurs autorisées, veuillez vous référer à ssh_config(5).

AddKeysToAgent
 
AddressFamily
 
BatchMode
 
BindAddress
 
CanonicalDomains
 
CanonicalizeFallbackLocal
 
CanonicalizeHostname
 
CanonicalizeMaxDots
 
CanonicalizePermittedCNAMEs
 
CASignatureAlgorithms
 
CertificateFile
 
CheckHostIP
 
Ciphers
 
ClearAllForwardings
 
Compression
 
ConnectionAttempts
 
ConnectTimeout
 
ControlMaster
 
ControlPath
 
ControlPersist
 
DynamicForward
 
EnableEscapeCommandline
 
EscapeChar
 
ExitOnForwardFailure
 
FingerprintHash
 
ForkAfterAuthentication
 
ForwardAgent
 
ForwardX11
 
ForwardX11Timeout
 
ForwardX11Trusted
 
GatewayPorts
 
GlobalKnownHostsFile
 
GSSAPIAuthentication
 
GSSAPIKeyExchange
 
GSSAPIClientIdentity
 
GSSAPIDelegateCredentials
 
GSSAPIKexAlgorithms
 
GSSAPIRenewalForcesRekey
 
GSSAPIServerIdentity
 
GSSAPITrustDns
 
HashKnownHosts
 
Host
 
HostbasedAcceptedAlgorithms
 
HostbasedAuthentication
 
HostKeyAlgorithms
 
HostKeyAlias
 
Hostname
 
IdentitiesOnly
 
IdentityAgent
 
IdentityFile
 
IPQoS
 
KbdInteractiveAuthentication
 
KbdInteractiveDevices
 
KexAlgorithms
 
KnownHostsCommand
 
LocalCommand
 
LocalForward
 
LogLevel
 
MACs
 
Match
 
NoHostAuthenticationForLocalhost
 
NumberOfPasswordPrompts
 
PasswordAuthentication
 
PermitLocalCommand
 
PermitRemoteOpen
 
PKCS11Provider
 
Port
 
PreferredAuthentications
 
ProxyCommand
 
ProxyJump
 
ProxyUseFdpass
 
PubkeyAcceptedAlgorithms
 
PubkeyAuthentication
 
RekeyLimit
 
RemoteCommand
 
RemoteForward
 
RequestTTY
 
RequiredRSASize
 
SendEnv
 
ServerAliveInterval
 
ServerAliveCountMax
 
SessionType
 
SetEnv
 
StdinNull
 
StreamLocalBindMask
 
StreamLocalBindUnlink
 
StrictHostKeyChecking
 
TCPKeepAlive
 
Tunnel
 
TunnelDevice
 
UpdateHostKeys
 
User
 
UserKnownHostsFile
 
VerifyHostKeyDNS
 
VisualHostKey
 
XAuthLocation
 

symbole
Spécifier un nom de symbole (tag) à utiliser pour sélectionner une configuration dans ssh_config(5). Voir les mots-clés Tag et Match dans ssh_config(5) pour plus d’informations.
port
Le port auquel se connecter sur la machine distante. On peut aussi le spécifier pour une machine donnée dans le fichier de configuration.

option_requête
Requérir les algorithmes de chiffrement pris en charge par une des fonctionnalités suivantes : cipher (algorithmes symétriques), cipher-auth (algorithmes symétriques qui prennent en charge le chiffrement authentifié), help (termes de requête pris en charge à utiliser avec l’option -Q), mac (codes d’intégrité de message pris en charge), kex (algorithmes d’échange de clés), kex-gss (algorithmes d’échange de clés GSSAPI), key (types de clé), key-ca-sign (algorithmes de signature d’Autorités de Certification (CA) valables pour les certificats), key-cert (types de clé de certificat), key-plain (types de clé hors certificats), key-sig (tous les types de clé et algorithmes de signature), protocol-version (versions du protocole SSH prises en charge) et sig (algorithmes de signature pris en charge). Autrement, tout mot-clé de ssh_config(5) ou sshd_config(5) qui prend une liste d’algorithmes peut être utilisé comme alias pour l’option de requête correspondante.

Mode silencieux. Supprime la plupart des messages d’avertissement et de diagnostic.

[adr_sortie:]port:machine:port_machine
 
[adr_sortie:]port:socket_local
 
socket_distant:machine:port_machine
 
socket_distant:socket_local
 
[adr_sortie:]port
Spécifie que les connexions vers le port TCP ou le socket Unix donné de la machine distante (serveur) seront transférées vers la machine locale.

À cet effet, un socket est alloué qui écoute un port TCP ou un socket Unix sur la machine distante. Dès qu’une connexion est établie sur ce port ou ce socket Unix, elle est transférée à travers le canal sécurisé, et une connexion est effectuée depuis la machine locale vers une destination explicite spécifiée par le port de la machine ou socket_local, ou, si aucune destination explicite n’a été spécifiée, ssh se comportera comme un mandataire SOCKS 4/5 et transférera les connexions vers les destinations requises par le client SOCKS distant.

On peut aussi spécifier des redirections de port (port forwardings) dans le fichier de configuration. On ne peut transférer des ports privilégiés que si on se connecte en tant que superutilisateur sur la machine distante. Il est possible de spécifier des adresses IPv6 en les entourant de crochets.

Par défaut, les sockets d’écoute TCP sur le serveur ne peuvent être liés qu’à l’interface loopback. Pour modifier ce comportement, on peut spécifier une adresse adr_sortie. Une adresse adr_sortie vide ou l’adresse « * » indique que le socket distant doit écouter toutes les interfaces. Spécifier une adresse adr_sortie distante ne réussira que si l’option GatewayPorts est activée sur le serveur (voir sshd_config(5)).

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 utilisé en combinaison avec -O forward, le port alloué sera envoyé sur la sortie standard

socket_contrôle
Indique l’emplacement d’un socket de contrôle pour le partage de connexion, ou la chaîne « none » pour désactiver le partage de connexion. Voir les descriptions de ControlPath et ControlMaster dans ssh_config(5) pour les détails.

Permet d’invoquer un sous-système sur la machine distante. Les sous-systèmes simplifient l’utilisation de SSH comme transport sécurisé pour d’autres applications (par exemple sftp(1)). Le sous-système est spécifié à l’aide de la commande distante. Voir la description de SessionType dans ssh_config(5) pour les détails.

Désactive l’allocation d’un pseudo-terminal.

Force l’allocation d’un pseudo-terminal. Utilisé pour exécuter des programmes en mode écran sur la machine distante, ce qui peut s’avérer fort utile, par exemple, pour les applications qui implémentent des services de menu. En ajoutant des options -t, on force l’allocation de terminaux, même si ssh n’a pas de terminal local.

Affiche le numéro de version et quitte.

Mode prolixe. Avec cette option, ssh affiche des messages de débogage sur les actions qu’il effectue. Fort utile pour déboguer les problèmes de connexion, d’authentification ou de configuration. Ajouter des options -v augmente la prolixité. Le maximum est de 3.

machine:port
Demande que les entrée et sortie standards sur le client soient transférées vers le port de machine par le canal sécurisé. Implique -N, -T, ExitOnForwardFailure et ClearAllForwardings, bien que ces options puissent être surchargées dans le fichier de configuration ou en utilisant l’option de ligne de commande -o.

tunnel_local[:tunnel_distant]
Demande la redirection par dispositif de tunnel avec les dispositifs tun(4) spécifiés entre le client (tunnel_local) et le serveur (tunnel_distant).

Les dispositifs peuvent être spécifiés par un ID numérique ou le mot-clé « any », auquel cas c’est le premier dispositif de tunnel disponible qui sera utilisé. La valeur par défaut de tunnel_distant est « any » au cas où il ne serait pas spécifié. Voir aussi les directives Tunnel et TunnelDevice dans ssh_config(5).

Si la directive Tunnel n’est pas définie, elle prendra pour valeur le mode de tunnel par défaut, à savoir « point-to-point ». Si un autre mode de redirection Tunnel est souhaité, il devra être spécifié avant -w.

Active la redirection X11. On peut aussi le spécifier pour une machine donnée dans le fichier de configuration.

La redirection X11 doit être activée avec précaution. En effet, les utilisateurs capables de contourner les permissions des fichiers sur la machine distante (pour accéder à la base de données d’accréditation de X) peuvent accéder au « display » X11 local par l’intermédiaire de la connexion transférée. Un attaquant pourrait alors effectuer des opérations telles que l’enregistrement de la frappe.

C’est pour cette raison que par défaut, la redirection X11 est assujettie aux restrictions de l’extension X11 SECURITY. Veuillez vous référer à l’option -Y de ssh et à la directive ForwardX11Trusted dans ssh_config(5) pour plus d’informations.

(Spécifique à Debian : par défaut, les redirections X11 ne sont pas soumises aux restrictions de l’extension SECURITY de X11, car actuellement de trop nombreux programmes plantent dans ce mode. Pour restaurer le comportement amont, vous pouvez définir l’option ForwardX11Trusted à « no ». Cette situation évoluera dans le futur si des améliorations sont apportées côté client).

Désactive la redirection X11.

Active une redirection X11 de confiance. Les redirections X11 de confiance ne sont pas assujetties aux contrôles de l’extension X11 SECURITY.

(Spécifique à Debian : dans la configuration par défaut, cette option est équivalente à -X puisque ForwardX11Trusted a pour valeur par défaut « yes », comme indiqué ci-dessus. Pour restaurer le comportement amont, vous pouvez définir l’option ForwardX11Trusted à « no ». Cette situation évoluera dans le futur si des améliorations sont apportées côté client).

Envoyer les informations de journalisation en utilisant le module système syslog(3). Par défaut, ces informations sont envoyées à stderr.

ssh peut aussi obtenir les données de configuration depuis un fichier de configuration d’utilisateur particulier et depuis un fichier de configuration global. Le format du fichier et les options de configuration sont décrits dans ssh_config(5).

AUTHENTIFICATION

Le client SSH OpenSSH prend en charge la version 2 du protocole SSH.

Pour l’authentification, les méthodes disponibles sont : l’authentification basée sur GSSAPI, l’authentification basée sur la machine, l’authentification par clé publique, l’authentification par interaction au clavier (keyboard-interactive) et l’authentification par mot de passe. Les méthodes d’authentification sont essayées selon l’ordre dans lequel elles sont indiquées ci-dessus, mais cet ordre par défaut peut être modifié à l’aide de la directive PreferredAuthentications.

L’authentification basée sur la machine fonctionne comme suit : si la machine sur laquelle l’utilisateur est connecté est enregistrée dans /etc/hosts.equiv ou /etc/ssh/shosts.equiv sur la machine distante, si l’utilisateur est autre que le superutilisateur et si les noms d’utilisateur sont les mêmes des deux côtés, ou si le fichier ~/.rhosts ou ~/.shosts existent dans le répertoire personnel de l’utilisateur sur la machine distante et comporte une ligne contenant le nom de la machine cliente et le nom de l’utilisateur sur cette machine, l’utilisateur est autorisé à se connecter. De plus, le serveur pouvoir vérifier la clé de la machine du client (voir la description de /etc/ssh/ssh_known_hosts et ~/.ssh/known_hosts ci-dessous) pour que la connexion soit autorisée. Cette méthode d’identification bouche les trous de sécurité dus aux usurpations d’adresse IP, de DNS et de routage. [Note à l’attention de l’administrateur : /etc/hosts.equiv, ~/.rhosts et le protocole rlogin/rsh dans sa globalité sont intrinsèquement non sécurisés et doivent être désactivés si vous attachez de l’importance à la sécurité.]

L’authentification par clé publique fonctionne comme suit : son principe est basé sur la cryptographie à clé publique et utilise des systèmes cryptographiques où le chiffrement et le déchiffrement utilisent des clés séparées et avec lesquels il est impossible de déterminer la clé de déchiffrement à partir de la clé de chiffrement. L’idée de base est la suivante : chaque utilisateur crée une paire de clés publique/privée à des fins d’authentification ; le serveur connaît la clé publique, mais seul l’utilisateur connaît la clé privée. ssh implémente automatiquement le protocole d’authentification par clé publique en utilisant un des algorithmes ECDSA, Ed25519 ou RSA.

Le fichier ~/.ssh/authorized_keys liste les clés publiques qui sont autorisées à se connecter. Lorsque l’utilisateur se connecte, le programme ssh indique au serveur quelle paire de clés il souhaiterait utiliser pour l’authentification. Le client prouve qu’il a accès à la clé privée et le serveur vérifie si la clé publique correspondante est autorisée à accepter le compte.

Le serveur pourra éventuellement indiquer au client les erreurs qui ont fait échouer l’authentification par clé publique lorsque l’authentification a réussi en utilisant une autre méthode. Ces erreurs peuvent être vues en augmentant le niveau de journalisation LogLevel à DEBUG ou plus (par exemple en utilisant l’option -v).

L’utilisateur crée sa paire de clés à l’aide de ssh-keygen(1). Ce programme enregistre la clé privée dans ~/.ssh/id_ecdsa (ECDSA), ~/.ssh/id_ecdsa_sk (clé ECDSA hébergée par un authentificateur), ~/.ssh/id_ed25519 (Ed25519), ~/.ssh/id_ed25519_sk (clé Ed25519 hébergée par un authentificateur) ou ~/.ssh/id_rsa (RSA) et la clé publique dans ~/.ssh/id_ecdsa.pub (ECDSA), ~/.ssh/id_ecdsa_sk.pub (clé ECDSA hébergée par un authentificateur), ~/.ssh/id_ed25519.pub (Ed25519), ~/.ssh/id_ed25519_sk.pub (clé Ed25519 hébergée par un authentificateur) ou ~/.ssh/id_rsa.pub (RSA) dans le répertoire personnel de l’utilisateur. L’utilisateur doit alors copier la clé publique dans ~/.ssh/authorized_keys dans son répertoire personnel sur la machine distante. Le fichier authorized_keys est équivalent au fichier ~/.rhosts traditionnel et il comporte une clé par ligne, même si ces dernières peuvent être très longues. Cela fait, l’utilisateur peut se connecter sans avoir à présenter de mot de passe.

L’authentification par certificat est une variante de l’authentification par clé publique : à la place de la paire de clés publique/privée, elle utilise des certificats signés, ce qui a pour avantage de ne nécessiter qu’une seule autorité de certification de confiance au lieu de nombreuses paires de clés publiques/privées. Voir la section CERTIFICATS de ssh-keygen(1) pour plus d’informations.

La meilleure méthode pour mettre en œuvre l’authentification par clé publique ou par certificat consiste à utiliser un agent d’authentification. Voir ssh-agent(1) et éventuellement la directive AddKeysToAgent dans ssh_config(5) pour plus d’informations.

L’authentification par interaction au clavier (keyboard-interactive) fonctionne comme suit : le serveur envoie une "question" arbitraire sous forme de texte et attend une réponse, éventuellement plusieurs fois. On peut citer comme exemples d’authentification par interaction au clavier l’authentification BSD (voir login.conf(5)) et l’authentification PAM (certains systèmes non-OpenBSD).

En fin de compte, si les autres méthodes d’authentification échouent, ssh demandera un mot de passe à l’utilisateur. Ce mot de passe sera alors envoyé à la machine distante pour vérification, et comme toutes les communications sont chiffrées, un individu qui écouterait le réseau ne pourra pas le voir.

ssh entretient et vérifie automatiquement une base de données contenant l’identification pour toutes les machines avec lesquelles il a déjà été utilisé. Les clés d’hôte sont stockées dans ~/.ssh/known_hosts dans le répertoire personnel de l’utilisateur. De plus, une vérification des machines connues est automatiquement effectuée dans le fichier /etc/ssh/ssh_known_hosts. Toute nouvelle machine est ajoutée au fichier de l’utilisateur. Si l’identification d'une machine est modifiée, ssh émet un avertissement et désactive l’authentification par mot de passe pour empêcher toute usurpation de serveur ou attaque de type « homme du milieu » qui pourrait sans cela être utilisée pour contourner le chiffrement. L’option StrictHostKeyChecking permet de contrôler les connexions aux machines dont la clé d’hôte est inconnue ou a été modifiée.

Lorsque l’identité de l’utilisateur a été acceptée par le serveur, soit une commande a été spécifiée et le serveur l’exécute dans le cadre d'une session non interactive, soit aucune commande n’a été spécifiée et le serveur connecte l’utilisateur à la machine et lui ouvre un interpréteur de commande normal dans le cadre d’une session interactive. Toutes les communications avec la commande ou l’interpréteur distants sont automatiquement chiffrées.

Si une session interactive est requise, par défaut, ssh ne demandera qu’un pseudo-terminal (pty) pour les sessions interactives lorsque le client en possède un. Les options -T et -t permettent d’outrepasser ce comportement.

Si un pseudo-terminal a été alloué, l’utilisateur peut utiliser les caractères d’échappement notés ci-dessous.

Si aucun pseudo-terminal n’a été alloué, la session est transparente et permet de transmettre des données binaires de manière fiable. Sur la plupart des systèmes, définir le caractère d’échappement à « none » rendra aussi la session transparente, même si un tty est utilisé.

La session est fermée lorsque la commande ou l’interpréteur de commande sur la machine distante quitte et si toutes les connexions X11 et TCP ont été fermées.

CARACTÈRES D’ÉCHAPPEMENT

Lorsqu’un pseudo-terminal a été demandé, ssh prend en charge un certain nombre de fonctions à l’aide de caractères d’échappement.

Pour envoyer un simple caractère tilde, on peut utiliser ~~ ou faire suivre le tilde d’un caractère autre que ceux décrits ci-dessous. Le caractère d’échappement doit toujours être précédé d’un caractère nouvelle ligne pour être considéré comme spécial. Il peut être changé en ligne de commande à l’aide de l’option -e ou dans les fichiers de configuration à l’aide de la directive EscapeChar.

Les échappements pris en charge (en comptant l’échappement par défaut « ~ ») sont :

Déconnecter.
ssh en arrière-plan.
Lister les connexions transmises.
ssh en arrière-plan à la déconnexion lorsqu’on attend la fin d’une connexion redirigée ou d’une session X11.
Afficher une liste des caractères d’échappement.
Envoyer un BREAK au système distant (pertinent seulement si la machine distante le prend en charge).
Ouvrir une ligne de commande. Actuellement, cette action permet d’ajouter des redirections de port en utilisant les options -L, -R et -D (voir ci-dessus). Elle permet aussi d’annuler des redirections de port existants à l’aide de -KL[adr_sortie:]port pour la machine locale, -KR[adr_sortie:]port pour la machine distante et -KD[adr_sortie:]port pour les redirections de port dynamiques. !commande permet à l’utilisateur d’exécuter une commande locale si la directive PermitLocalCommand est définie dans ssh_config(5). L’option -h permet d’afficher une aide succincte.
Demander une nouvelle saisie des informations de connexion (pertinent seulement si la machine distante le prend en charge).
Diminue la prolixité (LogLevel) quand les erreurs sont affichées sur stderr.
Augmente la prolixité (LogLevel) quand les erreurs sont affichées sur la sortie d'erreur.

TRANSFERT TCP

Il est possible de spécifier la redirection de connexions TCP arbitraires sur un canal sécurisé soit en ligne de commande, soit dans un fichier de configuration. La connexion sécurisée à un serveur de messagerie est un exemple d’application de la redirection TCP ; passer par des pare-feux en est un autre.

Dans l’exemple ci-dessous, on cherche à chiffrer les communications pour un client IRC, même si le serveur IRC auquel il se connecte ne prend pas directement en charge les communications chiffrées. Le fonctionnement est le suivant : l’utilisateur se connecte à la machine distante à l’aide de ssh en spécifiant le port à utiliser pour transférer la connexion. Cela fait, il est possible de démarrer le programme en local, et ssh chiffrera et transférera la connexion vers le serveur distant.

L’exemple suivant fait passer par un tunnel une session IRC depuis le client vers un serveur IRC à « server.example.com » en rejoignant le canal « #users », avec le pseudo « pinky », en utilisant le port IRC standard 6667 :

$ ssh -f -L 6667:localhost:6667 server.example.com sleep 10
$ irc -c '#users' pinky IRC/127.0.0.1

L’option -f fait passer ssh en arrière-plan et la commande distante « sleep 10 » est spécifiée pour accorder un certain temps (10 secondes dans l’exemple) avant de démarrer le programme qui est sur le point d’utiliser le tunnel. Si aucune connexion n’est effectuée dans ce laps de temps, ssh quittera.

TRANSFERT X11

Si la variable ForwardX11 est définie à « yes » (ou voir la description des options -X, -x et -Y ci-dessus) et si l’utilisateur utilise X11 (la variable d’environnement DISPLAY est définie), la connexion au « display » X11 est automatiquement transférée à la machine distante de façon que tout programme X11 démarré depuis l’interpréteur de commande (ou à l’aide d’une commande) passera par le canal chiffré, et la connexion au véritable serveur X sera établie depuis la machine locale. L’utilisateur ne doit pas définir manuellement DISPLAY. La redirection des connexions X11 peut être configurée en ligne de commande ou dans les fichiers de configuration.

Comme ssh crée un serveur X « mandataire » sur la machine serveur pour transférer les connexions sur le canal chiffré, il est normal que la valeur de DISPLAY définie par ssh pointe vers la machine serveur, mais avec un numéro de « display » supérieur à zéro.

ssh va aussi définir automatiquement les données Xauthority sur la machine serveur. À cet effet, il va générer un cookie d’autorisation aléatoire, le stocker dans Xauthority sur le serveur et vérifier que toute connexion transférée transporte bien ce cookie et le remplace par le véritable cookie lorsque la connexion est ouverte. Le véritable cookie d’authentification n’est jamais envoyé à la machine serveur (et aucun cookie n’est envoyé en clair).

Si la variable ForwardAgent est définie à « yes » (ou voir la description des options -A et -a ci-après) et si l’utilisateur utilise un agent d’authentification, la connexion à l’agent est transférée automatiquement vers la machine distante.

VÉRIFIER LES CLÉS D’HÔTE

Lorsqu’il se connecte à un serveur pour la première fois, une empreinte de la clé publique du serveur est présentée à l’utilisateur (à moins que l’option StrictHostKeyChecking n’ait été désactivée). Les empreintes peuvent être déterminées en utilisant ssh-keygen(1)  :

$ ssh-keygen -l -f /etc/ssh/ssh_host_rsa_key

Si l’empreinte est déjà connue, elle peut être vérifiée et la clé acceptée ou rejetée. Si les empreintes traditionnelles (MD5) sont les seules disponibles pour le serveur, l’option -E de ssh-keygen(1) permet de dégrader l’algorithme d’empreinte pour qu’il convienne.

Comme il est difficile de comparer les clés d’hôte en regardant simplement les chaînes d’empreinte, la comparaison visuelle des clés d’hôte est aussi prise en charge en utilisant . En définissant l’option VisualHostKey à « yes », un petit graphisme ASCII est affiché à chaque connexion à un serveur, et cela que la session elle-même soit interactive ou non. En mémorisant le motif que produit un serveur connu, un utilisateur peut aisément détecter que la clé d’hôte a changé si un motif totalement différent est affiché. Comme ces motifs ne sont pas dépourvus d’ambiguïté, un motif qui paraîtra identique au motif mémorisé ne constituera cependant qu’une bonne probabilité pour que la clé d’hôte soit la même, non une preuve irréfutable.

La ligne de commande suivante permet d’obtenir une liste des empreintes et de leurs motifs aléatoires pour toutes les machines connues :

$ ssh-keygen -lv -f ~/.ssh/known_hosts

Si l’empreinte n’est pas connue, il existe une autre méthode de vérification : les empreintes SSH vérifiées par DNS. Un enregistrement ressource (RR), SSHFP, est ajouté à un fichier de zone et le client qui se connecte est alors en mesure de comparer l’empreinte avec celle de la clé présentée.

Dans cet exemple, un client se connecte au serveur « host.example.com ». L’enregistrement ressource SSHFP doit avoir été ajouté au fichier de zone pour host.example.com :

$ ssh-keygen -r host.example.com.

Les lignes en sortie devront être ajoutées au fichier de zone. Pour vérifier si la zone répond aux demandes d’empreinte :

$ dig -t SSHFP host.example.com

Finalement, le client se connecte :

$ ssh -o "VerifyHostKeyDNS ask" host.example.com
[...]
Matching host key fingerprint found in DNS.
Are you sure you want to continue connecting (yes/no)?

Voir l’option VerifyHostKeyDNS dans ssh_config(5) pour plus d’informations.

VPN BASÉ SUR SSH

ssh prend en charge les tunnels par VPN (Réseau Privé Virtuel) à l’aide du pseudo-périphérique réseau tun(4) qui permet de relier deux réseaux de manière sécurisée. L’option de configuration PermitTunnel de sshd_config(5) permet de contrôler la prise en charge par le serveur de cette fonctionnalité et à quel niveau (trafic de couche 2 ou 3).

Dans l’exemple suivant, le réseau client 10.0.50.0/24 est relié au réseau distant 10.0.99.0/24 en utilisant une connexion point-à-point de 10.1.1.1 à 10.1.1.2, à condition que le serveur SSH qui s’exécute sur la passerelle (d’adresse 192.168.1.15) vers le réseau distant le permette.

Sur le client :

# ssh -f -w 0:1 192.168.1.15 true
# ifconfig tun0 10.1.1.1 10.1.1.2 netmask 255.255.255.252
# route add 10.0.99.0/24 10.1.1.2

Sur le serveur :

# ifconfig tun1 10.1.1.2 10.1.1.1 netmask 255.255.255.252
# route add 10.0.50.0/24 10.1.1.1

L’accès du client peut être configuré plus finement à l’aide du fichier /root/.ssh/authorized_keys (voir plus loin) et de l’option de serveur PermitRootLogin. L’entrée suivante permet des connexions sur le dispositif tun(4) numéro 1 depuis l’utilisateur « jane » et sur le dispositif tun de numéro 2 depuis l’utilisateur « john » si PermitRootLogin est définie à « forced-commands-only » :

tunnel="1",command="sh /etc/netstart tun1" ssh-rsa ... jane
tunnel="2",command="sh /etc/netstart tun2" ssh-rsa ... john

Une configuration basée sur SSH impliquant une surcharge conséquente, elle est plus adaptée aux configurations temporaires comme les VPN sans fil. Pour des VPN plus persistants, il est préférable d’utiliser des outils comme ipsecctl(8) ou isakmpd(8).

ENVIRONNEMENT

Normalement, ssh va définir les variables d’environnement suivantes :

La variable DISPLAY indique l’emplacement du serveur X11. Elle est automatiquement définie par ssh à une valeur de la forme « nom_machine:n » où « nom_machine » indique la machine sur laquelle l’interpréteur de commande s’exécute, et où « n » est un entier ≥ 1. ssh utilise cette valeur spéciale pour transférer les connexions X11 sur le canal sécurisé. Normalement, l’utilisateur ne doit pas définir explicitement DISPLAY, car la connexion ne serait alors plus sécurisée (et l’utilisateur devrait copier manuellement tout cookie d’autorisation requis).
Définie au chemin du répertoire personnel de l’utilisateur.
Synonyme de USER  ; définie à des fins de compatibilité avec les systèmes qui utilisent cette variable.
Définie au chemin de la boîte aux lettres de l’utilisateur.
Définie à la valeur par défaut de PATH spécifiée lors de la compilation de ssh.
Si ssh nécessite une phrase de passe, il la lit depuis le terminal en cours s’il est exécuté depuis un terminal. Si ssh n’est pas associé à un terminal, alors que les variables d'environnement DISPLAY et SSH_ASKPASS sont définies, il exécute le programme spécifié dans SSH_ASKPASS et ouvre une fenêtre X11 pour lire la phrase de passe, ce qui s’avère particulièrement utile lors d'un appel de ssh depuis .xsession ou un script équivalent (notez que sur certaines machines, il peut être nécessaire de rediriger l’entrée depuis /dev/null pour que cela fonctionne).
Permet un contrôle plus fin de l’utilisation d’un programme de demande de mot de passe. Si cette variable est définie à « never », ssh n’essaiera jamais d’en utiliser un. Si elle est définie à « prefer », ssh préférera l’utilisation du programme de demande de mot de passe à celle du TTY si un mot de passe est requis. Enfin, si elle est définie à « force », le programme de demande de mot de passe sera utilisé pour toute saisie de phrase de passe, et cela que la variable DISPLAY soit définie ou non.
Identifie le chemin du socket de domaine UNIX utilisé pour communiquer avec l’agent.
Identifie les deux bouts de la connexion (le client et le serveur). La variable contient quatre valeurs séparées par des espaces : l’adresse IP du client, le numéro de port du client, l’adresse IP du serveur et le numéro de port du serveur.
Cette variable contient la ligne de commande originelle si une commande forcée est exécutée. On peut l’utiliser pour extraire les arguments originels.
Définie au nom du terminal tty (chemin du fichier de périphérique) associé à l'interpréteur de commande ou à la commande en cours. Si la session en cours n'a pas de terminal, la variable n’est pas définie.
Éventuellement définie par sshd(8) pour contenir les noms d’interface assignés si le client a demandé une redirection de tunnel.
Éventuellement définie par sshd(8), cette variable peut contenir le chemin d’un fichier qui contient la liste des méthodes d’authentification qui ont été utilisées avec succès lors de l’établissement de la connexion, ainsi que toute clé publique qui a été utilisée.
Cette variable indique le fuseau horaire actuel si elle était définie au démarrage du démon. (c'est-à-dire que le démon transmet la valeur aux nouvelles connexions).
Définie au nom de l’utilisateur qui se connecte.

En outre, ssh lit le fichier ~/.ssh/environment et ajoute des lignes au format « NOM_VAR=valeur » à l'environnement, si le fichier existe, et si les utilisateurs sont autorisés à modifier leur environnement. Pour plus d'informations, voir l'option PermitUserEnvironment dans sshd_config(5).

FICHIERS

~/.rhosts
Ce fichier est utilisé dans le cadre de l’authentification basée sur la machine (voir plus haut). Sur certaines machines, ce fichier devra éventuellement être lisible par tout le monde si le répertoire personnel de l’utilisateur est sur une partition NFS, car sshd(8) le lit en tant que superutilisateur. En outre, ce fichier doit être la propriété de l’utilisateur et ne doit être accessible en écriture pour personne d’autre. Les permissions recommandées sur la plupart des machines sont lecture/écriture pour l’utilisateur et aucun accès pour les autres.

~/.shosts
Ce fichier est utilisé exactement de la même façon que .rhosts, mais il permet l’authentification basée sur la machine sans autoriser les connexions avec rlogin/rsh.

~/.ssh/
Ce répertoire correspond à l’emplacement par défaut de toutes les informations de configuration et d’authentification spécifiques à l’utilisateur. Il n’est globalement pas nécessaire de garder secret l’ensemble du contenu de ce répertoire, mais les permissions recommandées sont lecture/écriture/exécution pour l’utilisateur et aucun accès pour les autres.

~/.ssh/authorized_keys
Ce fichier énumère les clés publiques (ECDSA, Ed25519, RSA) qui peuvent être utilisées pour se connecter sous l’identité de cet utilisateur. Le format de ce fichier est décrit dans la page de manuel de sshd(8). Le contenu de ce fichier n’est pas hautement sensible, mais les permissions recommandées sont lecture/écriture pour l’utilisateur et aucun accès pour les autres.

~/.ssh/config
C’est le fichier de configuration spécifique à l’utilisateur. Le format du fichier et les options de configuration sont décrits dans ssh_config(5). Comme il y a risque d’intrusion, ce fichier doit avoir des permissions strictes : lecture/écriture pour l’utilisateur et pas d’accès en écriture pour les autres. Il peut être accessible en écriture pour le groupe si ce dernier ne contient que l’utilisateur.

~/.ssh/environment
Ce fichier contient des définitions de variables d’environnement additionnelles ; voir ENVIRONNEMENT ci-dessus.

~/.ssh/id_ecdsa
 
~/.ssh/id_ecdsa_sk
 
~/.ssh/id_ed25519
 
~/.ssh/id_ed25519_sk
 
~/.ssh/id_rsa
Ces fichiers contiennent la clé privée pour l’authentification. Ils contiennent des données sensibles et doivent être lisibles par l’utilisateur mais inaccessibles pour les autres (lecture/écriture/exécution). ssh ignorera tout simplement un fichier de clé privée s’il est accessible pour les autres. Il est possible de spécifier une phrase de passe lors de la génération de la clé qui sera utilisée pour chiffrer la partie sensible de ces fichiers en utilisant AES-128.

~/.ssh/id_ecdsa.pub
 
~/.ssh/id_ecdsa_sk.pub
 
~/.ssh/id_ed25519.pub
 
~/.ssh/id_ed25519_sk.pub
 
~/.ssh/id_rsa.pub
Ces fichiers contiennent la clé publique pour l’authentification. Ils ne contiennent pas de données sensibles et peuvent (mais cela n’est pas nécessaire) être lisibles par tout le monde.

~/.ssh/known_hosts
Ce fichier contient une liste des clés d’hôte pour toutes les machines auxquelles l’utilisateur s’est connecté et qui ne sont pas déjà présentes dans la liste des clés d’hôte connues de tout le système. Voir sshd(8) pour plus de détails à propos du format de ce fichier.

~/.ssh/rc
Les commandes que contient ce fichier sont exécutées par ssh lorsque l’utilisateur se connecte, juste avant le lancement de l’interpréteur de commande (ou la commande) de l’utilisateur. Voir la page de manuel de sshd(8) pour plus d’informations.

/etc/hosts.equiv
Ce fichier est utilisé dans le cadre de l’authentification basée sur la machine (voir plus haut). Il ne doit être accessible en écriture que pour le superutilisateur.

/etc/ssh/shosts.equiv
Ce fichier est utilisé exactement de la même manière que hosts.equiv, mais il permet l’authentification basée sur la machine sans autoriser les connexions avec rlogin/rsh.

/etc/ssh/ssh_config
C’est le fichier de configuration global du système. Le format du fichier et les options de configuration sont décrits dans ssh_config(5).

/etc/ssh/ssh_host_ecdsa_key
 
/etc/ssh/ssh_host_ed25519_key
 
/etc/ssh/ssh_host_rsa_key
Ces fichiers contiennent les parties privées des clés d’hôte et sont utilisés dans le cadre de l’authentification basée sur la machine.

/etc/ssh/ssh_known_hosts
Ce fichier contient la liste des clés d’hôte connues globale à tout le système. Il doit être préparé par l’administrateur système de façon à contenir les clés d’hôte publiques de toutes les machines de l’organisation. Il doit être accessible pour tout le monde. Voir sshd(8) pour plus de détails à propos du format de ce fichier.

/etc/ssh/sshrc
Les commandes que contient ce fichier sont exécutées par ssh lorsque l’utilisateur se connecte, juste avant le lancement de l’interpréteur de commande (ou la commande) de l’utilisateur. Voir la page de manuel de sshd(8) pour plus d’informations.

CODE DE RETOUR

ssh quitte avec le code de retour de la commande distante ou 255 si une erreur est survenue

VOIR AUSSI

scp(1), sftp(1), ssh-add(1), ssh-agent(1), ssh-argv0(1), ssh-keygen(1), ssh-keyscan(1), tun(4), ssh_config(5), ssh-keysign(8), sshd(8)

STANDARDS

S. Lehtinen et C. Lonvick, The Secure Shell (SSH) Protocol Assigned Numbers, RFC 4250, janvier 2006.

T. Ylonen et C. Lonvick, The Secure Shell (SSH) Protocol Architecture, RFC 4251, janvier 2006.

T. Ylonen et C. Lonvick, The Secure Shell (SSH) Authentication Protocol, RFC 4252, janvier 2006.

T. Ylonen et C. Lonvick, The Secure Shell (SSH) Transport Layer Protocol, RFC 4253, janvier 2006.

T. Ylonen et C. Lonvick, The Secure Shell (SSH) Connection Protocol, RFC 4254, janvier 2006.

J. Schlyter et W. Griffin, Using DNS to Securely Publish Secure Shell (SSH) Key Fingerprints, RFC 4255, janvier 2006.

F. Cusack et M. Forssen, Generic Message Exchange Authentication for the Secure Shell Protocol (SSH), RFC 4256, janvier 2006.

J. Galbraith et P. Remaker, The Secure Shell (SSH) Session Channel Break Extension, RFC 4335, janvier 2006.

M. Bellare, T. Kohno et C. Namprempre, The Secure Shell (SSH) Transport Layer Encryption Modes, RFC 4344, janvier 2006.

B. Harris, Improved Arcfour Modes for the Secure Shell (SSH) Transport Layer Protocol, RFC 4345, janvier 2006.

M. Friedl, N. Provos et W. Simpson, Diffie-Hellman Group Exchange for the Secure Shell (SSH) Transport Layer Protocol, RFC 4419, mars 2006.

J. Galbraith et R. Thayer, The Secure Shell (SSH) Public Key File Format, RFC 4716, novembre 2006.

D. Stebila et J. Green, Elliptic Curve Algorithm Integration in the Secure Shell Transport Layer, RFC 5656, décembre 2009.

A. Perrig et D. Song, Hash Visualization: a New Technique to improve Real-World Security, 1999, International Workshop on Cryptographic Techniques and E-Commerce (CrypTEC '99).

AUTEURS

OpenSSH est un dérivé de la version originale et libre 1.2.12 de ssh par Tatu Ylonen. Aaron Campbell, Bob Beck, Markus Friedl, Niels Provos, Theo de Raadt et Dug Song ont corrigé de nombreux bogues, rajouté de 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>, Éric Piel <eric.piel@tremplin-utc.net> 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: 28 juin 2024 $ Debian