Provided by: manpages-fr_4.23.1-1_all 
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 :
-4 Force ssh à n’utiliser que des adresses IPv4.
-6 Force ssh à n’utiliser que des adresses IPv6.
-A 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).
-a Désactive la redirection de connexion de l’agent d’authentification.
-B 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.
-b 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.
-C 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).
-c 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.
-D [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.
-E fichier_journal
Ajoute les informations de débogage au fichier_journal au lieu de les envoyer sur la sortie
d’erreur standard.
-e 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.
-F 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.
-f 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.
-G Demande à ssh d’afficher sa configuration après évaluation des blocs Host et Match puis de
quitter.
-g 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.
-I 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.
-i 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, ~/.ssh/id_ed25519_sk et ~/.ssh/id_dsa. 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é.
-J 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. 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.
-K Active l’authentification basée sur GSSAPI et les transferts (délégations) d’identifiants GSSAPI
vers le serveur.
-k Désactive les transferts (délégations) d’identifiants GSSAPI vers le serveur.
-L [adr_sortie:]port:machine:port_machine
-L [adr_sortie:]port:socket_distant
-L socket_local:machine:port_machine
-L 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.
-l 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.
-M 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.
-m 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 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.
-n 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.
-O 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).
-o 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
-P 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.
-p 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.
-Q 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.
-q Mode silencieux. Supprime la plupart des messages d’avertissement et de diagnostic.
-R [adr_sortie:]port:machine:port_machine
-R [adr_sortie:]port:socket_local
-R socket_distant:machine:port_machine
-R socket_distant:socket_local
-R [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
-S 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.
-s 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.
-T Désactive l’allocation d’un pseudo-terminal.
-t 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.
-V Affiche le numéro de version et quitte.
-v 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.
-W 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.
-w 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.
-X 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).
-x Désactive la redirection X11.
-Y 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).
-y 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 doit
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 DSA, ECDSA, Ed25519 ou RSA. La section HISTORIQUE de ssl(8)
(sur les systèmes autres que OpenBSD, voir
http://www.openbsd.org/cgi-bin/man.cgi?query=ssl&sektion=8#HISTORY) contient une brève explication à pro‐
pos des algorithmes DSA et 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_dsa (DSA), ~/.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_dsa.pub (DSA),
~/.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.
~^Z 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.
~B Envoyer un BREAK au système distant (pertinent seulement si la machine distante le prend en
charge).
~C 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.
~R Demander une nouvelle saisie des informations de connexion (pertinent seulement si la machine
distante le prend en charge).
~V Diminue la prolixité (LogLevel) quand les erreurs sont affichées sur stderr.
~v 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 random art. 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 :
DISPLAY 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).
HOME Définie au chemin du répertoire personnel de l’utilisateur.
LOGNAME Synonyme de USER ; définie à des fins de compatibilité avec les systèmes qui
utilisent cette variable.
MAIL Définie au chemin de la boîte aux lettres de l’utilisateur.
PATH Définie à la valeur par défaut de PATH spécifiée lors de la compilation de .
SSH_ASKPASS 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).
SSH_ASKPASS_REQUIRE 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.
SSH_AUTH_SOCK Identifie le chemin du socket de domaine UNIX utilisé pour communiquer avec
l’agent.
SSH_CONNECTION 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.
SSH_ORIGINAL_COMMAND 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.
SSH_TTY 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.
SSH_TUNNEL Éventuellement définie par sshd(8) pour contenir les noms d’interface assignés si
le client a demandé une redirection de tunnel.
SSH_USER_AUTH É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.
TZ 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).
USER 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 (DSA, 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_dsa
~/.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_dsa.pub
~/.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_key
/etc/ssh/ssh_host_dsa_key
/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: https://www.gnu.org/licenses/gpl-3.0.html 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 .
Debian 11 octobre, 2023 SSH(1)