ssh — Client d’ouverture de session à distance OpenSSH
SYNTAXE
ssh [-46AaCfGgKkMNnqsTtVvXxYy] [-B bind_interface] [-b bind_address] [-c cipher_spec]
[-D [bind_address:]port] [-E log_file] [-e escape_char] [-F configfile] [-I pkcs11]
[-i identity_file] [-J destination] [-L address] [-l login_name] [-m mac_spec] [-O ctl_cmd]
[-o option] [-P tag] [-p port] [-R address] [-S ctl_path] [-W host:port]
[-w local_tun[:remote_tun]] destination [command [argument ...]]
ssh [-Q query_option]
DESCRIPTION
ssh (client SSH) est un programme permettant de se connecter à une machine distante et d’exécuter des commandes sur une machine distante. Il est conçu pour fournir des communications chiffrées sécurisées entre deux hôtes non fiables sur un réseau non sécurisé. Les connexions X11, les ports TCP arbitraires et les sockets de domaine Unix peuvent également être transférés via le canal sécurisé.
ssh se connecte et se connecte à la destination spécifiée, qui peut être spécifiée sous la forme [utilisateur@]nom_hôte ou sous la forme d’une URI du type ssh://[utilisateur@]nom_hôte[:port]. L’utilisateur doit prouver son identité à la machine distante en utilisant l’une des méthodes suivantes (voir ci-dessous).
Si une commande est spécifiée, elle sera exécutée sur l’hôte distant au lieu d’un shell de connexion. Une ligne de commande complète peut être spécifiée sous la forme de commande, ou elle peut avoir des arguments supplémentaires. Si elle est fournie, les arguments seront ajoutés à la commande, séparés par des espaces, avant d’être envoyés au serveur pour être exécutés.
Les options sont les suivantes :
-4 Force ssh à utiliser uniquement les adresses IPv4.
-6 Force ssh à utiliser uniquement les adresses IPv6.
-A Active le transfert des connexions à partir d’un agent d’authentification tel que ssh-agent(1).
Cela peut également être spécifié sur une base par hôte dans un fichier de configuration.
Le transfert d’agent doit être activé avec prudence. Les utilisateurs qui sont en mesure de contourner les autorisations de fichier sur l’hôte distant (pour le socket de domaine Unix de l’agent) peuvent accéder à l’agent local via la connexion transférée. Un attaquant ne peut pas obtenir de matériel de clé à partir de l’agent, mais il peut effectuer des opérations sur les clés qui lui permettent de s’authentifier à l’aide des identités chargées dans l’agent. Une alternative plus sûre peut être d’utiliser un hôte de saut (voir -J).
-a Désactive le transfert de la connexion de l’agent d’authentification.
-B bind_interface
Liez-vous à l’adresse de bind_interface avant de tenter de vous connecter à la destination hôte. Ceci n’est utile que sur les systèmes dotés de plus d’une adresse.
-b bind_address
Utilisez bind_address sur la machine locale comme adresse source de la connexion. N’est utile que sur les systèmes dotés de plus d’une adresse.
-C Demande la compression de toutes les données (y compris stdin, stdout, stderr et les données pour les connexions X11, TCP et Unix-domain). L’algorithme de compression est le même que celui utilisé par [gzip]({filename}../../gzip)(1). La compression est souhaitable sur les lignes modem et autres connexions lentes, mais ne fera que ralentir les choses sur les réseaux rapides. La valeur par défaut peut être définie par hôte dans les fichiers de configuration ; voir l’option Compression dans ssh_config(5).
-c cipher_spec
Sélectionne la spécification de chiffrement pour le chiffrement de la session. cipher_spec est une liste d’éléments séparés par des virgules, listant les chiffrements par ordre de préférence. Voir le mot-clé Ciphers dans ssh_config(5) pour plus d’informations.
-D [bind_address:]port
Spécifie un port d’application « dynamique » local pour le transfert. Ceci fonctionne en allouant un socket pour écouter sur le port côté local, éventuellement lié à l’adresse spécifiée. Chaque fois qu’une connexion est établie vers ce port, la connexion est transmise via le canal sécurisé, et le protocole applicatif est ensuite utilisé pour déterminer où se connecter à partir de la machine distante. Actuellement, les protocoles SOCKS4 et SOCKS5 sont pris en charge, et ssh agira comme un serveur SOCKS. Seul l’utilisateur root peut transférer les ports privilégiés. Les transferts de ports dynamiques peuvent également être spécifiés dans le fichier de configuration.
Les adresses IPv6 peuvent être spécifiées en encadrant l’adresse entre crochets. Seul l’utilisateur root peut transférer les ports privilégiés. Par défaut, le port local est lié conformément au paramètre GatewayPorts. Cependant, une adresse de liaison explicite peut être utilisée pour lier la connexion à une adresse spécifique. L’adresse de liaison « localhost » indique que le port d’écoute doit être lié pour une utilisation locale uniquement, tandis qu’une adresse vide ou « * » indique que le port doit être disponible à partir de toutes les interfaces.
-E log_file
Ajoute les journaux de débogage au fichier log_file au lieu de la sortie standard d’erreur.
-e escape_char
Définit le caractère d’échappement pour les sessions avec un pseudo-terminal (par défaut : « \~ »). Le caractère d’échappement est reconnu uniquement au début d’une ligne. Le caractère d’échappement suivi d’un point (« . ») ferme la connexion ; suivi de Control-Z, suspend la connexion ; et suivi de lui-même, envoie le caractère d’échappement une fois. Définir le caractère sur « none » désactive tous les échappements et rend la session entièrement transparente.
-F configfile
Spécifie un fichier de configuration par utilisateur alternatif. Si un fichier de configuration est fourni en ligne de commande, le fichier de configuration système (/etc/ssh/ssh_config) sera ignoré. La valeur par défaut du fichier de configuration par utilisateur est ~/.ssh/config. S’il est défini sur « none », aucun fichier de configuration ne sera lu.
-f Demande à ssh de passer en arrière-plan juste avant l’exécution de la commande. Ceci est utile si ssh va demander des mots de passe ou des phrases secrètes, mais que l’utilisateur souhaite qu’il soit en arrière-plan. Ceci implique -n. Le moyen recommandé de démarrer les programmes X11 sur un site distant est avec quelque chose comme ssh -f host xterm.
Si l’option de configuration ExitOnForwardFailure est définie sur « oui », un client démarré avec l’option -f attendra que toutes les redirections de port distantes soient établies avec succès avant de se placer en arrière-plan. Reportez-vous à la description de ForkAfterAuthentication dans ssh_config(5) pour plus de détails.
-G Affiche la configuration de ssh après l’évaluation des blocs `Host` et `Match` et quitte.
-g Permet aux hôtes distants de se connecter aux ports locaux redirigés. Si cette option est utilisée sur une connexion multiplexée, elle doit être spécifiée sur le processus principal.
-I pkcs11
Spécifie la bibliothèque partagée PKCS#11 que ssh doit utiliser pour communiquer avec un jeton PKCS#11 fournissant des clés pour l’authentification de l’utilisateur.
-i identity_file
Sélectionne un fichier à partir duquel la clé privée pour l’authentification par clé publique est lue. Vous pouvez également spécifier un fichier de clé publique pour utiliser la clé privée correspondante qui est chargée dans `ssh-agent(1)` lorsque le fichier de clé privée n’est pas présent localement. La valeur par défaut est `~/.ssh/id_rsa`, `~/.ssh/id_ecdsa`, `~/.ssh/id_ecdsa_sk`, `~/.ssh/id_ed25519` et `~/.ssh/id_ed25519_sk`. Les fichiers d’identité peuvent également être spécifiés par hôte dans le fichier de configuration. Il est possible d’avoir plusieurs options `-i` (et plusieurs identités spécifiées dans les fichiers de configuration). Si aucun certificat n’a été explicitement spécifié par la directive `CertificateFile`, ssh tentera également de charger les informations de certificat à partir du nom de fichier obtenu en ajoutant `-cert.pub` aux noms de fichiers d’identité.
-J destination
Se connecte à l’hôte cible en effectuant d’abord une connexion ssh à l’hôte de saut décrit par `destination`, puis en établissant un transfert TCP vers la destination finale à partir de là. Plusieurs sauts peuvent être spécifiés, séparés par des virgules. Les adresses IPv6 peuvent être spécifiées en encadrant l’adresse entre crochets. Il s’agit d’un raccourci pour spécifier une directive `ProxyJump` dans le fichier de configuration. Notez que les directives de configuration fournies sur la ligne de commande s’appliquent généralement à l’hôte de destination et non aux hôtes de saut spécifiés. Utilisez `~/.ssh/config` pour spécifier la configuration des hôtes de saut.
-K Active l’authentification basée sur GSSAPI et le transfert (délégation) des informations d’identification GSSAPI au serveur.
-k Désactive le transfert (délégation) des informations d’identification GSSAPI au serveur.
-L [bind_address:]port:host:hostport
-L [bind_address:]port:remote_socket
-L local_socket:host:hostport
-L local_socket:remote_socket
Spécifie que les connexions au port TCP ou au socket Unix donné sur l’hôte local (client) doivent être redirigées vers l’hôte et le port, ou le socket Unix, donnés du côté distant. Cela fonctionne en allouant un socket pour écouter un port TCP sur le côté local, éventuellement lié à l’adresse `bind_address` spécifiée, ou à un socket Unix. Chaque fois qu’une connexion est établie au port ou au socket local, la connexion est transmise via le canal sécurisé, et une connexion est établie au port `hostport` ou au socket Unix `remote_socket` de la machine distante.
Les redirections de port peuvent également être spécifiées dans le fichier de configuration. Seul l’utilisateur root peut rediriger les ports privilégiés. Les adresses IPv6 peuvent être spécifiées en encadrant l’adresse entre crochets.
Par défaut, le port local est lié conformément au paramètre GatewayPorts. Cependant, une adresse de liaison explicite peut être utilisée pour lier la connexion à une adresse spécifique. L’adresse de liaison « localhost » indique que le port d’écoute doit être lié pour une utilisation locale uniquement, tandis qu’une adresse vide ou « * » indique que le port doit être accessible à partir de toutes les interfaces.
-l nom_utilisateur
Spécifie l’utilisateur sur lequel se connecter sur la machine distante. Ceci peut également être spécifié au niveau de l’hôte dans le fichier de configuration.
-M Place le client SSH en « mode maître » pour le partage de connexion. Plusieurs options -M
placent SSH en « mode maître », mais avec une confirmation requise à l’aide de ssh-askpass(1) avant
chaque opération qui modifie l’état du multiplexage (par exemple, l’ouverture d’une nouvelle session).
Reportez-vous à la description de ControlMaster dans ssh_config(5) pour plus de détails.
-m spécification_mac
Une liste d’algorithmes MAC (code d’authentification de message) séparés par des virgules, spécifiés par ordre de préférence. Voir le mot-clé MACs dans ssh_config(5) pour plus d’informations.
-N N’exécute pas de commande distante. Ceci est utile pour simplement transférer des ports. Reportez-vous
à la description de SessionType dans ssh_config(5) pour plus de détails.
-n Redirige l’entrée standard à partir de /dev/null (en réalité, empêche la lecture à partir de l’entrée standard).
Cela doit être utilisé lorsque SSH est exécuté en arrière-plan. Une astuce courante est de l’utiliser pour exécuter des programmes X11 sur une machine distante. Par exemple, ssh -n shadows.cs.hut.fi emacs & démarrera un
emacs sur shadows.cs.hut.fi, et la connexion X11 sera automatiquement transmise via
un canal chiffré. Le programme SSH sera placé en arrière-plan. (Cela ne fonctionne pas si SSH doit demander un mot de passe ou une phrase de passe ; voir également l’option -f). Reportez-vous
à la description de StdinNull dans ssh_config(5) pour plus de détails.
-O commande_ctl
Contrôle un processus maître de multiplexage de connexion actif. Lorsque l’option -O est spécifiée, l’argument commande_ctl est interprété et transmis au processus maître. Les commandes valides sont : « check » (vérifie si le processus maître est en cours d’exécution), « forward » (demande des transferts sans exécution de commande), « cancel » (annule les transferts), « proxy » (se connecte à
un processus maître de multiplexage en cours d’exécution en mode proxy), « exit » (demande au maître de se fermer) et
« stop » (demande au maître d’arrêter d’accepter d’autres demandes de multiplexage).
-o option
Peut être utilisé pour fournir des options dans le format utilisé dans le fichier de configuration. Ceci est utile
pour spécifier des options pour lesquelles il n’existe pas d’indicateur de ligne de commande distinct. Pour plus de détails sur les options énumérées ci-dessous et leurs valeurs possibles, voir ssh_config(5).
AddKeysToAgent
AddressFamily
BatchMode
BindAddress
BindInterface
CASignatureAlgorithms
CanonicalDomains
CanonicalizeFallbackLocal
CanonicalizeHostname
CanonicalizeMaxDots
CanonicalizePermittedCNAMEs
CertificateFile
ChannelTimeout
CheckHostIP
Ciphers
ClearAllForwardings
Compression
ConnectTimeout
ConnectionAttempts
ControlMaster
ControlPath
ControlPersist
DynamicForward
EnableEscapeCommandline
EnableSSHKeysign
EscapeChar
ExitOnForwardFailure
FingerprintHash
ForkAfterAuthentication
ForwardAgent
ForwardX11
ForwardX11Timeout
ForwardX11Trusted
GSSAPIAuthentication
GSSAPIKeyExchange
GSSAPIClientIdentity
GSSAPIDelegateCredentials
GSSAPIKexAlgorithms
GSSAPIRenewalForcesRekey
GSSAPIServerIdentity
GSSAPITrustDns
GatewayPorts
GlobalKnownHostsFile
HashKnownHosts
Host
HostKeyAlgorithms
HostKeyAlias
HostbasedAcceptedAlgorithms
HostbasedAuthentication
Hostname
IPQoS
IdentitiesOnly
IdentityAgent
IdentityFile
IgnoreUnknown
Include
KbdInteractiveAuthentication
KbdInteractiveDevices
KexAlgorithms
KnownHostsCommand
LocalCommand
LocalForward
LogLevel
LogVerbose
MACs
NoHostAuthenticationForLocalhost
NumberOfPasswordPrompts
ObscureKeystrokeTiming
PKCS11Provider
PasswordAuthentication
PermitLocalCommand
PermitRemoteOpen
Port
PreferredAuthentications
ProxyCommand
ProxyJump
ProxyUseFdpass
PubkeyAcceptedAlgorithms
PubkeyAuthentication
RekeyLimit
RemoteCommand
RemoteForward
RequestTTY
RequiredRSASize
RevokedHostKeys
SecurityKeyProvider
SendEnv
ServerAliveCountMax
ServerAliveInterval
SessionType
SetEnv
StdinNull
StreamLocalBindMask
StreamLocalBindUnlink
StrictHostKeyChecking
SyslogFacility
TCPKeepAlive
Tag
Tunnel
TunnelDevice
UpdateHostKeys
User
UserKnownHostsFile
VerifyHostKeyDNS
VisualHostKey
XAuthLocation
-P tag Spécifie un nom de balise qui peut être utilisé pour sélectionner une configuration dans ssh_config(5). Consultez les mots-clés Tag et Match dans ssh_config(5) pour plus d’informations.
-p port
Port sur lequel se connecter sur l’hôte distant. Cela peut être spécifié pour chaque hôte dans le fichier de configuration.
-Q query_option
Interroge les algorithmes pris en charge par l’une des fonctionnalités suivantes : cipher (algorithmes de chiffrement symétriques pris en charge), cipher-auth (algorithmes de chiffrement symétriques qui prennent en charge le chiffrement authentifié), help (termes de requête pris en charge pour l’utilisation avec l’indicateur -Q), mac (codes d’intégrité des messages pris en charge), kex (algorithmes d’échange de clés), kex-gss (algorithmes d’échange de clés GSSAPI), key (types de clés), key-ca-sign (algorithmes de signature de CA valides pour les certificats), key-cert (types de clés de certificat), key-plain (types de clés non-certificat), key-sig (tous les types de clés et algorithmes de signature), protocol-version (versions de protocole SSH prises en charge) et sig (algorithmes de signature pris en charge). Alternativement, tout mot-clé de ssh_config(5) ou sshd_config(5) qui prend une liste d’algorithmes peut être utilisé comme alias pour le query_option correspondant.
-q Mode silencieux. Supprime la plupart des messages d’avertissement et de diagnostic.
-R [bind_address:]port:host:hostport
-R [bind_address:]port:local_socket
-R remote_socket:host:hostport
-R remote_socket:local_socket
-R [bind_address:]port
Spécifie que les connexions au port TCP ou à la socket Unix donné sur l’hôte distant doivent être transférées vers le côté local.
Cela fonctionne en allouant une socket pour écouter un port TCP ou une socket Unix sur le côté distant. Chaque fois qu’une connexion est établie à ce port ou à cette socket Unix, la connexion est transférée via le canal sécurisé, et une connexion est établie à partir de la machine locale vers une destination explicite spécifiée par host:port, ou local_socket,
ou, si aucune destination explicite n’a été spécifiée, ssh agira comme un proxy SOCKS 4/5 et transférera les connexions vers les destinations demandées par le client SOCKS distant.
Les transferts de port peuvent également être spécifiés dans le fichier de configuration. Les ports privilégiés ne peuvent être transférés que lorsque l’utilisateur se connecte en tant que root sur la machine distante. Les adresses IPv6 peuvent être spécifiées en plaçant l’adresse entre crochets.
Par défaut, les sockets d’écoute TCP sur le serveur seront liées uniquement à l’interface de bouclage. Cela peut être remplacé en spécifiant une bind_address. Une bind_address vide, ou l’adresse ‘*’, indique que la socket distante doit écouter sur toutes les interfaces. La spécification d’une bind_address distante ne réussira que si l’option GatewayPorts du serveur est activée (voir sshd_config(5)).
Si l’argument port est « 0 », le port d’écoute sera alloué dynamiquement sur le serveur et signalé au client au moment de l’exécution. Lorsqu’il est utilisé avec -O forward, le port alloué sera affiché sur la sortie standard.
-S ctl_path
Spécifie l’emplacement d’une socket de contrôle pour le partage de connexion, ou la chaîne « none » pour désactiver le partage de connexion. Reportez-vous à la description de ControlPath et ControlMaster dans ssh_config(5) pour plus de détails.
-s Peut être utilisé pour demander l’invocation d’un sous-système sur le système distant. Les sous-systèmes facilitent l’utilisation de SSH en tant que transport sécurisé pour d’autres applications (par exemple, [sftp]({filename}../../sftp)(1)). Le sous-système est spécifié comme la commande distante. Reportez-vous à la description de SessionType dans ssh_config(5) pour plus de détails.
-T Désactive l’allocation de pseudo-terminal.
-t Force l’allocation de pseudo-terminal. Cela peut être utilisé pour exécuter des programmes basés sur écran arbitraires sur une machine distante, ce qui peut être très utile, par exemple, lors de la mise en œuvre de services de menu. Plusieurs options -t forcent l’allocation de tty, même si ssh n’a pas de tty local.
-V Affiche le numéro de version et quitte.
-v Mode verbeux. Cela amène ssh à afficher des messages de débogage sur sa progression. Ceci est utile pour déboguer les problèmes de connexion, d’authentification et de configuration. Plusieurs options -v augmentent la verbosité. Le maximum est 3.
-W host:port
Demande que les entrées et sorties standard du client soient transmises via le canal sécurisé vers l’hôte sur le port spécifié. Implique -N, -T, ExitOnForwardFailure et ClearAllForwardings, bien que ceux-ci puissent être remplacés dans le fichier de configuration ou à l’aide des options de ligne de commande -o.
-w local_tun[:remote_tun]
Demande la redirection du périphérique tunnel avec les périphériques tun(4) spécifiés entre le client (local_tun) et le serveur (remote_tun).
Les périphériques peuvent être spécifiés par ID numérique ou par le mot-clé « any », qui utilise le périphérique tunnel disponible suivant. Si remote_tun n’est pas spécifié, il prend par défaut la valeur « any ». Voir également les directives Tunnel et TunnelDevice dans ssh_config(5).
Si la directive Tunnel n’est pas définie, elle sera définie sur le mode tunnel par défaut, qui est « point-à-point ». Si un mode de redirection Tunnel différent est souhaité, il doit être spécifié avant -w.
-X Active la redirection X11. Cela peut également être spécifié par hôte dans un fichier de configuration.
La redirection X11 doit être activée avec prudence. Les utilisateurs capables de contourner les permissions des fichiers sur l’hôte distant (pour la base de données d’autorisation X de l’utilisateur) peuvent accéder à l’écran X11 local via la connexion transmise. Un attaquant peut alors être en mesure d’effectuer des activités telles que la surveillance des frappes au clavier.
Pour cette raison, la redirection X11 est soumise aux restrictions de l’extension X11 SECURITY par défaut. Voir l’option ssh -Y et la directive ForwardX11Trusted dans ssh_config(5) pour plus d’informations.
(Spécifique à Debian : la redirection X11 n’est pas soumise aux restrictions de l’extension X11 SECURITY par défaut, car trop de programmes plantent actuellement dans ce mode. Définissez l’option ForwardX11Trusted sur « no » pour restaurer le comportement en amont. Cela peut changer à l’avenir en fonction des améliorations côté client.)
-x Désactive la redirection X11.
-Y Active la redirection X11 de confiance. Les redirections X11 de confiance ne sont pas soumises aux contrôles de l’extension X11 SECURITY.
(Spécifique à Debian : dans la configuration par défaut, cette option est équivalente à -X, car ForwardX11Trusted a par défaut la valeur « yes » comme décrit ci-dessus. Définissez l’option ForwardX11Trusted sur « no » pour restaurer le comportement en amont. Cela peut changer à l’avenir en fonction des améliorations côté client.)
-y Envoie les informations de journal à l’aide du module système syslog(3). Par défaut, ces informations sont envoyées vers stderr.
ssh peut également obtenir des données de configuration à partir d’un fichier de configuration par utilisateur et d’un fichier de configuration à l’échelle du système. Le format du fichier et les options de configuration sont décrits dans ssh_config(5).
AUTHENTIFICATION
Le client OpenSSH SSH prend en charge le protocole SSH 2.
Les méthodes disponibles pour l’authentification sont : l’authentification basée sur GSSAPI, l’authentification basée sur l’hôte, l’authentification par clé publique, l’authentification interactive par clavier et l’authentification par mot de passe. Les méthodes d’authentification sont essayées dans l’ordre spécifié ci-dessus, bien que PreferredAuthentications puisse être utilisé pour modifier l’ordre par défaut.
L'authentification basée sur l'hôte fonctionne comme suit : si la machine à partir de laquelle l'utilisateur se connecte est répertoriée dans /etc/hosts.equiv ou /etc/ssh/shosts.equiv sur la machine distante, et que l'utilisateur n'est pas root et que les noms d'utilisateur sont identiques des deux côtés, ou si les fichiers ~/.rhosts ou ~/.shosts existent dans le répertoire personnel de l'utilisateur sur la machine distante et contiennent une ligne contenant le nom de la machine cliente et le nom de l'utilisateur sur cette machine, l'utilisateur est considéré comme autorisé à se connecter. De plus, le serveur doit être en mesure de vérifier la clé d'hôte 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'authentification élimine les failles de sécurité dues au spoofing d'adresse IP, au spoofing DNS et au spoofing de routage.
[Note pour l'administrateur : /etc/hosts.equiv, ~/.rhosts et le protocole rlogin/rsh en général sont intrinsèquement peu sûrs et doivent être désactivés si la sécurité est souhaitée.]
L'authentification par clé publique fonctionne comme suit : le schéma est basé sur la cryptographie à clé publique, en utilisant des systèmes de chiffrement où le chiffrement et le déchiffrement sont effectués à l'aide de clés distinctes, et il est impossible de dériver la clé de déchiffrement à partir de la clé de chiffrement. L'idée est que chaque utilisateur crée une paire de clés publique/privée à des fins d'authentification. Le serveur connaît la clé publique, et seul l'utilisateur connaît la clé privée. ssh implémente automatiquement le protocole d'authentification par clé publique, en utilisant l'un des algorithmes ECDSA, Ed25519 ou RSA.
Le fichier ~/.ssh/authorized_keys répertorie les clés publiques qui sont autorisées à se connecter. Lorsque l'utilisateur se connecte, le programme ssh indique au serveur la paire de clés qu'il souhaite utiliser pour l'authentification. Le client prouve qu'il a accès à la clé privée et le serveur vérifie que la clé publique correspondante est autorisée à accepter le compte.
Le serveur peut informer le client des erreurs qui ont empêché la réussite de l'authentification par clé publique après que l'authentification a été effectuée en utilisant une autre méthode. Celles-ci peuvent être consultées en augmentant le niveau de journalisation à DEBUG ou supérieur (par exemple, en utilisant l'indicateur -v).
L'utilisateur crée sa paire de clés en exécutant la commande ssh-keygen(1). Cela stocke la clé privée dans ~/.ssh/id_ecdsa (ECDSA), ~/.ssh/id_ecdsa_sk (ECDSA hébergé par l'authentificateur), ~/.ssh/id_ed25519 (Ed25519), ~/.ssh/id_ed25519_sk (Ed25519 hébergé par l'authentificateur) ou ~/.ssh/id_rsa (RSA) et stocke la clé publique dans ~/.ssh/id_ecdsa.pub (ECDSA), ~/.ssh/id_ecdsa_sk.pub (ECDSA hébergé par l'authentificateur), ~/.ssh/id_ed25519.pub (Ed25519), ~/.ssh/id_ed25519_sk.pub (Ed25519 hébergé par l'authentificateur) ou ~/.ssh/id_rsa.pub (RSA) dans le répertoire personnel de l'utilisateur. L'utilisateur doit ensuite copier la clé publique dans ~/.ssh/authorized_keys dans son répertoire personnel sur la machine distante. Le fichier authorized_keys correspond au fichier ~/.rhosts conventionnel et contient une clé par ligne, bien que les lignes puissent être très longues. Après cela, l'utilisateur peut se connecter sans fournir de mot de passe.
Une variante de l’authentification par clé publique est disponible sous la forme de l’authentification par certificat : au lieu d’un ensemble de clés publique/privée, des certificats signés sont utilisés. Cela présente l’avantage qu’une seule autorité de certification de confiance peut être utilisée à la place de nombreuses clés publique/privée. Consultez la section CERTIFICATS de la page de manuel ssh-keygen(1) pour plus d’informations.
La manière la plus pratique d’utiliser l’authentification par clé publique ou par certificat est d’utiliser un agent d’authentification. Consultez ssh-agent(1) et (facultativement) la directive AddKeysToAgent dans ssh_config(5) pour plus d’informations.
L’authentification interactive par clavier fonctionne comme suit : le serveur envoie un texte de « défi » arbitraire et demande une réponse, éventuellement plusieurs fois. Les exemples d’authentification interactive par clavier incluent l’authentification BSD (voir login.conf(5)) et PAM (sur certains systèmes non-OpenBSD).
Enfin, si les autres méthodes d’authentification échouent, ssh demande à l’utilisateur un mot de passe. Le mot de passe est envoyé à l’hôte distant pour vérification ; cependant, comme toutes les communications sont chiffrées, le mot de passe ne peut pas être vu par quelqu’un qui écoute sur le réseau.
ssh maintient et vérifie automatiquement une base de données contenant l’identification de tous les hôtes pour lesquels 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, le fichier /etc/ssh/ssh_known_hosts est automatiquement vérifié pour les hôtes connus. Tous les nouveaux hôtes sont automatiquement ajoutés au fichier de l’utilisateur. Si l’identification d’un hôte change, ssh avertit et désactive l’authentification par mot de passe pour empêcher l’usurpation de serveur ou les attaques de type « man-in-the-middle », qui pourraient autrement être utilisées pour contourner le chiffrement. L’option StrictHostKeyChecking peut être utilisée pour contrôler les connexions aux machines dont la clé d’hôte n’est pas connue ou a changé.
Une fois que l’identité de l’utilisateur a été acceptée par le serveur, le serveur exécute la commande donnée dans une session non interactive ou, si aucune commande n’a été spécifiée, se connecte à la machine et donne à l’utilisateur une session shell normale en mode interactif. Toutes les communications avec la commande ou le shell distant seront automatiquement chiffrées.
Si une session interactive est demandée, ssh demande par défaut un pseudo-terminal (pty) uniquement pour les sessions interactives lorsque le client en a un. Les options -T et -t peuvent être utilisées pour remplacer ce comportement.
Si un pseudo-terminal a été alloué, l’utilisateur peut utiliser les caractères d’échappement indiqués ci-dessous.
Si aucun pseudo-terminal n’a été alloué, la session est transparente et peut être utilisée pour transférer de manière fiable des données binaires. Sur la plupart des systèmes, définir le caractère d’échappement sur « none » rendra également la session transparente, même si un tty est utilisé.
La session se termine lorsque la commande ou le shell sur la machine distante se termine et que toutes les connexions X11 et TCP sont fermées.
CARACTÈRES D’ÉCHAPEMENT
Lorsqu’un pseudo-terminal a été demandé, ssh prend en charge un certain nombre de fonctions grâce à l’utilisation d’un caractère d’échappement.
Un simple caractère tilde peut être envoyé sous la forme de ~~ ou en faisant suivre le tilde d’un caractère autre que ceux décrits ci-dessous. Le caractère d’échappement doit toujours suivre une nouvelle ligne pour être interprété comme spécial. Le caractère d’échappement peut être modifié dans les fichiers de configuration à l’aide de la directive de configuration EscapeChar ou sur la ligne de commande à l’aide de l’option -e.
Les séquences d’échappement prises en charge (en supposant le tilde par défaut « \~ ») sont les suivantes :
~. Déconnexion.
~^Z Exécuter ssh en arrière-plan.
~# Afficher la liste des connexions transmises.
~& Exécuter ssh en arrière-plan lors de la déconnexion, en attendant que les connexions transmises ou les sessions X11 se terminent.
~? Afficher une liste des caractères d’échappement.
~B Envoyer une interruption (BREAK) au système distant (utile uniquement si le pair le prend en charge).
~C Ouvrir une ligne de commande. Actuellement, cela permet l’ajout de transferts de port à l’aide des options -L, -R et -D (voir ci-dessus). Cela permet également d’annuler les transferts de port existants avec -KL[bind_address:]port pour les transferts de port locaux, -KR[bind_address:]port pour les transferts de port distants et -KD[bind_address:]port pour les transferts de port dynamiques. !commande permet à l’utilisateur d’exécuter une commande locale si l’option PermitLocalCommand est activée dans ssh_config(5). Une aide de base est disponible à l’aide de l’option -h.
~R Demander un renouvellement du chiffrement de la connexion (utile uniquement si le pair le prend en charge).
~V Diminuer la verbosité (LogLevel) lorsque des erreurs sont écrites dans stderr.
~v Augmenter la verbosité (LogLevel) lorsque des erreurs sont écrites dans stderr.
TRANSFERT TCP
Le transfert de connexions TCP arbitraires sur un canal sécurisé peut être spécifié soit sur la ligne de commande, soit dans un fichier de configuration. Une application possible du transfert TCP est une connexion sécurisée à un serveur de messagerie ; une autre est le passage à travers des pare-feu.
Dans l’exemple ci-dessous, nous examinons le chiffrement des 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. Cela fonctionne comme suit : l’utilisateur se connecte à l’hôte distant à l’aide de ssh, en spécifiant les ports à utiliser pour transférer la connexion. Après cela, il est possible de démarrer le programme localement, et ssh chiffrera et transférera la connexion au serveur distant.
L’exemple suivant crée un tunnel pour une session IRC du client vers un serveur IRC à « server.example.com », en rejoignant le canal « #users », avec le pseudonyme « 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 exécute ssh en arrière-plan, et la commande distante « sleep 10 » est spécifiée pour permettre un certain temps (10 secondes, dans l’exemple) pour démarrer le programme qui va utiliser le tunnel. Si aucune connexion n’est établie dans le délai spécifié, ssh se terminera.
TRANSFERT X11
Si la variable ForwardX11 est définie sur « yes » (ou voir la description des options -X, -x et -Y ci-dessus) et que l’utilisateur utilise X11 (la variable d’environnement DISPLAY est définie), la connexion au serveur X11 est automatiquement transférée vers le côté distant de manière à ce que tous les programmes X11 lancés à partir du shell (ou de la commande) passent par le canal chiffré, et que la connexion au serveur X réel soit établie à partir de la machine locale. L’utilisateur ne doit pas définir manuellement la variable DISPLAY. Le transfert des connexions X11 peut être configuré sur la ligne de commande ou dans les fichiers de configuration.
La valeur de DISPLAY définie par ssh pointera vers la machine serveur, mais avec un numéro d’affichage supérieur à zéro. C’est normal, car ssh crée un serveur X « proxy » sur la machine serveur pour transférer les connexions via le canal chiffré.
ssh mettra également automatiquement en place les données Xauthority sur la machine serveur. À cette fin, il générera un cookie d’autorisation aléatoire, le stockera dans Xauthority sur le serveur et vérifiera que toutes les connexions transférées contiennent ce cookie et le remplacera par le cookie réel lorsque la connexion sera ouverte. Le cookie d’authentification réel n’est jamais envoyé à la machine serveur (et aucun cookie n’est envoyé en clair).
Si la variable ForwardAgent est définie sur « yes » (ou voir la description des options -A et -a ci-dessus) et que l’utilisateur utilise un agent d’authentification, la connexion à l’agent est automatiquement transférée vers le côté distant.
VÉRIFICATION DES CLÉS DE HÔTE
Lors de la connexion à un serveur pour la première fois, un empreinte de la clé publique du serveur est présentée à l’utilisateur (sauf si l’option StrictHostKeyChecking a été désactivée). Les empreintes peuvent être déterminées à l’aide de la commande ssh-keygen(1) :
$ ssh-keygen -l -f /etc/ssh/ssh_host_rsa_key
Si l’empreinte est déjà connue, elle peut être comparée et la clé peut être acceptée ou rejetée. Si seules les empreintes (MD5) héritées du serveur sont disponibles, l’option -E de la commande ssh-keygen(1) peut être utilisée pour rétrograder l’algorithme d’empreinte afin de faire correspondre.
En raison de la difficulté de comparer les clés d’hôte en se contentant de regarder les chaînes d’empreinte, il existe également une prise en charge pour comparer les clés d’hôte visuellement, à l’aide d’une représentation graphique. En définissant l’option VisualHostKey sur « yes », un petit graphique ASCII est affiché à chaque connexion à un serveur, que la session soit interactive ou non. En apprenant le motif qu’un serveur connu produit, un utilisateur peut facilement déterminer si la clé d’hôte a changé lorsqu’un motif complètement différent est affiché. Étant donné que ces motifs ne sont pas sans ambiguïté, un motif qui ressemble à celui mémorisé ne donne qu’une bonne probabilité que la clé d’hôte soit la même, et non une preuve garantie.
Pour obtenir une liste des empreintes digitales ainsi que leurs représentations graphiques pour tous les hôtes connus, la commande suivante peut être utilisée :
$ ssh-keygen -lv -f ~/.ssh/known_hosts
Si l’empreinte digitale est inconnue, une méthode de vérification alternative est disponible : les empreintes digitales SSH vérifiées par DNS. Un enregistrement de ressource supplémentaire (RR), SSHFP, est ajouté à un fichier de zone, et le client qui se connecte peut faire correspondre l’empreinte digitale avec celle de la clé présentée.
Dans cet exemple, nous connectons un client à un serveur, « host.example.com ». Les enregistrements de ressource SSHFP doivent d’abord être ajoutés au fichier de zone de host.example.com :
$ ssh-keygen -r host.example.com.
Les lignes de sortie devront être ajoutées au fichier de zone. Pour vérifier que la zone répond aux requêtes d’empreintes digitales :
$ dig -t SSHFP host.example.com
Enfin, le client se connecte :
$ ssh -o "VerifyHostKeyDNS ask" host.example.com
[...]
L’empreinte digitale de la clé d’hôte correspondante a été trouvée dans DNS. Êtes-vous sûr de vouloir continuer la connexion (oui/non) ?
Consultez l’option VerifyHostKeyDNS dans ssh_config(5) pour plus d’informations.
RÉSEAUX PRIVÉS VIRTUELS (VPN) BASÉS SUR SSH
ssh prend en charge le tunneling de réseau privé virtuel (VPN) à l’aide du périphérique réseau tun(4), ce qui permet de connecter deux réseaux de manière sécurisée. L’option de configuration sshd\_config(5), PermitTunnel, contrôle si le serveur prend en charge cette fonctionnalité, et à quel niveau (trafic de couche 2 ou 3).
L’exemple suivant connecterait le réseau client 10.0.50.0/24 au réseau distant 10.0.99.0/24 à l’aide d’une connexion point à point de 10.1.1.1 à 10.1.1.2, à condition que le serveur SSH en cours d’exécution sur la passerelle du réseau distant, à l’adresse 192.168.1.15, l’autorise.
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 client peut être affiné via le fichier /root/.ssh/authorized_keys (voir ci-dessous) et l’option de serveur PermitRootLogin. L’entrée suivante autoriserait les connexions sur le périphérique tun(4) 1 pour l’utilisateur « jane » et sur le périphérique tun 2 pour l’utilisateur « john », si PermitRootLogin est défini sur « forced-commands-only » :
tunnel="1",command="sh /etc/netstart tun1" ssh-rsa ... jane
tunnel="2",command="sh /etc/netstart tun2" ssh-rsa ... john
Étant donné qu’une configuration SSH implique une quantité importante de surcharge, elle peut être plus adaptée aux configurations temporaires, telles que pour les VPN sans fil. Les VPN plus permanents sont mieux fournis par des outils tels que ipsecctl(8) et isakmpd(8).
ENVIRONNEMENT
Normalement, ssh définit les variables d’environnement suivantes :
DISPLAY La variable DISPLAY indique l’emplacement du serveur X11. ssh la définit automatiquement pour qu’elle pointe vers une valeur du type « hostname:n », où « hostname » indique l’hôte où s’exécute le shell, et « n » est un entier ≥
ssh utilise cette valeur spéciale pour transférer les connexions X11 via le canal sécurisé. L’utilisateur ne doit normalement pas définir DISPLAY explicitement, car cela rendrait la connexion X11 non sécurisée (et nécessiterait que l’utilisateur copie manuellement tous les cookies d’autorisation nécessaires).
HOME Défini sur le chemin du répertoire personnel de l’utilisateur.
LOGNAME Synonyme de USER ; défini pour la compatibilité avec les systèmes qui utilisent cette variable.
MAIL Défini sur le chemin de la boîte aux lettres de l’utilisateur.
PATH Défini sur le PATH par défaut, tel que spécifié lors de la compilation de ssh.
SSH_ASKPASS Si ssh a besoin d’une phrase secrète, il la lira à partir du terminal actuel si celui-ci a été exécuté à partir d’un terminal. Si ssh n’a pas de terminal associé, mais que DISPLAY et SSH_ASKPASS sont définis, il exécutera le programme spécifié par SSH_ASKPASS et ouvrira une fenêtre X11 pour lire la phrase secrète. Ceci est particulièrement utile lors de l’appel de ssh à partir d’un fichier .xsession ou d’un script similaire. (Notez que sur certaines machines, il peut être nécessaire de rediriger l’entrée de /dev/null pour que cela fonctionne.)
SSH_ASKPASS_REQUIRE Permet de contrôler davantage l’utilisation d’un programme askpass. Si cette variable est définie sur « never », ssh n’essaiera jamais d’utiliser un programme askpass. Si elle est définie sur « prefer », ssh préférera utiliser le programme askpass plutôt que le TTY lors de la demande de mots de passe. Enfin, si la variable est définie sur « force », le programme askpass sera utilisé pour toute entrée de phrase secrète, quel que soit le fait que DISPLAY soit défini ou non.
SSH_AUTH_SOCK Identifie le chemin d’une socket de domaine Unix utilisée pour communiquer avec l’agent.
SSH_CONNECTION Identifie les extrémités client et serveur de la connexion. La variable contient quatre valeurs séparées par des espaces : adresse IP du client, numéro de port du client, adresse IP du serveur et numéro de port du serveur.
SSH_ORIGINAL_COMMAND Cette variable contient la ligne de commande d’origine si une commande forcée est exécutée. Elle peut être utilisée pour extraire les arguments d’origine.
SSH_TTY Ceci est défini sur le nom du tty (chemin d’accès au périphérique) associé au shell ou à la commande actuelle. Si la session actuelle n’a pas de tty, cette variable n’est pas définie.
SSH_TUNNEL Définie en option par [sshd]({filename}../../sshd)(8) pour contenir les noms d’interface attribués si le transfert de tunnel a été demandé par le client.
SSH_USER_AUTH Définie en option par [sshd]({filename}../../sshd)(8), cette variable peut contenir un chemin d’accès à un fichier qui répertorie les méthodes d’authentification utilisées avec succès lors de l’établissement de la session, y compris toutes les clés publiques qui ont été utilisées.
TZ Cette variable est définie pour indiquer le fuseau horaire actuel si elle a été définie lorsque le démon a été démarré (c’est-à-dire que le démon transmet la valeur aux nouvelles connexions).
USER Défini sur le nom de l’utilisateur qui se connecte.
De plus, ssh lit \~/.ssh/environment, et ajoute des lignes du format « VARNAME=value » à l’environnement si le fichier existe et que les utilisateurs sont autorisés à modifier leur environnement. Pour plus d’informations, consultez l’option PermitUserEnvironment dans sshd_config(5).
FICHIERS
~/.rhosts
Ce fichier est utilisé pour l’authentification basée sur l’hôte (voir ci-dessus). Sur certaines machines, ce fichier peut devoir être accessible en lecture à tous si le répertoire personnel de l’utilisateur se trouve sur une partition NFS, car sshd(8) le lit en tant que root. De plus, ce fichier doit appartenir à l’utilisateur et ne doit pas avoir de permissions d’écriture pour les autres. La permission recommandée pour la plupart des machines est la lecture/écriture pour l’utilisateur et non accessible aux autres.
~/.shosts
Ce fichier est utilisé exactement de la même manière que .rhosts, mais permet l’authentification basée sur l’hôte sans autoriser la connexion avec rlogin/rsh.
~/.ssh/
Ce répertoire est l’emplacement par défaut de toute la configuration et des informations d’authentification spécifiques à l’utilisateur. Il n’y a pas d’exigence générale de garder le contenu entier de ce répertoire secret, mais les permissions recommandées sont la lecture/écriture/exécution pour l’utilisateur, et non accessibles aux autres.
~/.ssh/authorized_keys
Contient la liste des clés publiques (ECDSA, Ed25519, RSA) qui peuvent être utilisées pour se connecter en tant que cet utilisateur. Le format de ce fichier est décrit dans la page de manuel sshd(8). Ce fichier n’est pas très sensible, mais les permissions recommandées sont la lecture/écriture pour l’utilisateur et non accessibles aux autres.
~/.ssh/config
Il s’agit du fichier de configuration spécifique à l’utilisateur. Le format du fichier et les options de configuration sont décrits dans ssh_config(5). En raison du potentiel d’abus, ce fichier doit avoir des permissions strictes : lecture/écriture pour l’utilisateur et non accessible en écriture par les autres. Il peut être accessible en écriture par le groupe, à condition que le groupe en question ne contienne que l’utilisateur.
~/.ssh/environment
Contient des définitions supplémentaires pour les variables d’environnement ; voir « ENVIRONNEMENT », ci-dessus.
~/.ssh/id_ecdsa
~/.ssh/id_ecdsa_sk
~/.ssh/id_ed25519
~/.ssh/id_ed25519_sk
~/.ssh/id_rsa
Contient la clé privée pour l’authentification. Ces fichiers contiennent des données sensibles et doivent être lisibles par l’utilisateur mais non accessibles aux autres (lecture/écriture/exécution). ssh ignorera simplement un fichier de clé privée s’il est accessible aux 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 ce fichier à l’aide d’AES-128.
~/.ssh/id_ecdsa.pub
~/.ssh/id_ecdsa_sk.pub
~/.ssh/id_ed25519.pub
~/.ssh/id_ed25519_sk.pub
~/.ssh/id_rsa.pub
Contient la clé publique pour l’authentification. Ces fichiers ne sont pas sensibles et peuvent (mais pas nécessairement) être lisibles par tous.
~/.ssh/known_hosts
Contient une liste des clés d’hôte pour tous les hôtes auxquels l’utilisateur s’est connecté et qui ne figurent pas déjà dans la liste globale des hôtes connus. Voir sshd(8) pour plus de détails sur le format de ce fichier.
~/.ssh/rc
Les commandes de ce fichier sont exécutées par ssh lorsque l’utilisateur se connecte, juste avant que le shell (ou la commande) de l’utilisateur ne soit démarré. Voir la page de manuel sshd(8) pour plus d’informations.
/etc/hosts.equiv
Ce fichier est destiné à l’authentification basée sur l’hôte (voir ci-dessus). Il ne doit être accessible en écriture qu’à l’utilisateur root.
/etc/ssh/shosts.equiv
Ce fichier est utilisé de la même manière que hosts.equiv, mais permet l’authentification basée sur l’hôte sans autoriser la connexion avec rlogin/rsh.
/etc/ssh/ssh_config
Fichier de configuration système. Le format du fichier et les options de configuration sont décrits dans ssh_config(5).
/etc/ssh/ssh_host_ecdsa_key
/etc/ssh/ssh_host_ed25519_key
/etc/ssh/ssh_host_rsa_key
Ces fichiers contiennent les parties privées des clés hôtes et sont utilisés pour l’authentification basée sur l’hôte.
/etc/ssh/ssh_known_hosts
Liste système des clés hôtes connues. Ce fichier doit être préparé par l’administrateur système pour contenir les clés publiques de tous les hôtes de l’organisation. Il doit être accessible en lecture par tous. Voir sshd(8) pour plus de détails sur le format de ce fichier.
/etc/ssh/sshrc
Les commandes de ce fichier sont exécutées par ssh lorsque l’utilisateur se connecte, juste avant le démarrage du shell (ou de la commande) de l’utilisateur. Voir la page de manuel sshd(8) pour plus d’informations.
STATUT DE SORTIE
ssh renvoie le statut de sortie de la commande distante ou 255 si une erreur s’est produite.
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)
NORMES
S. Lehtinen et C. Lonvick, Le protocole Secure Shell (SSH) Assigned Numbers, RFC 4250, janvier 200.
T. Ylonen et C. Lonvick, L’architecture du protocole Secure Shell (SSH), RFC 4251, janvier 2006.
T. Ylonen et C. Lonvick, Le protocole d’authentification Secure Shell (SSH), RFC 4252, janvier 2006.
T. Ylonen et C. Lonvick, Le protocole de couche de transport Secure Shell (SSH), RFC 4253, janvier 200.
T. Ylonen et C. Lonvick, Le protocole de connexion Secure Shell (SSH), RFC 4254, janvier 2006.
J. Schlyter et W. Griffin, Utilisation de DNS pour publier en toute sécurité les empreintes de clés Secure Shell (SSH), RFC 4255, janvier 2006.
F. Cusack et M. Forssen, Échange de messages génériques pour l’authentification du protocole Secure Shell (SSH), RFC 4256, janvier 2006.
J. Galbraith et P. Remaker, L’extension de rupture de canal de session Secure Shell (SSH), RFC 4335, janvier 2006.
M. Bellare, T. Kohno et C. Namprempre, Les modes de chiffrement de la couche de transport Secure Shell (SSH), RFC 4344, janvier 2006.
B. Harris, Modes Arcfour améliorés pour le protocole de couche de transport Secure Shell (SSH), RFC 4345, janvier 2006.
M. Friedl, N. Provos et W. Simpson, Échange de groupes Diffie-Hellman pour le protocole de couche de transport Secure Shell (SSH), RFC 4419, mars 2006.
J. Galbraith et R. Thayer, Le format de fichier de clé publique Secure Shell (SSH), RFC 4716, novembre 200.
D. Stebila et J. Green, Intégration d’algorithmes de courbe elliptique dans la couche de transport Secure Shell, RFC 5656, décembre 2009.
A. Perrig et D. Song, Visualisation de hachage : une nouvelle technique pour améliorer la sécurité dans le monde réel, 1999,
Atelier international sur les techniques cryptographiques et le commerce électronique (CrypTEC 99).
AUTEURS
OpenSSH est un dérivé de la version originale et gratuite de ssh 1.2.12 de Tatu Ylonen. Aaron Campbell, Bob Beck, Markus Friedl, Niels Provos, Theo de Raadt et Dug Song ont corrigé de nombreux bugs, ont réintégré des fonctionnalités plus récentes et ont créé OpenSSH. Markus Friedl a contribué au support des versions 1.5 et 2.0 du protocole SSH.