Ubuntu Manpage: ssh — Client de connexion à distance d’OpenSSH

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 à propos 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.

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 .