Linux Certif

Toute la documentation sur la certification Linux LPI

sshd

BSD mandoc

NOM

sshd - démon SSH d'OpenSSH

SYNOPSIS

sshd [-deiqtD46 ] [-b bits ] [-f config_file ] [-g login_grace_time ] [-h host_key_file ] [-k key_gen_time ] [-o option ] [-p port ] [-u len ]

DESCRIPTION

sshd (démon SSH) est un démon pour ssh(1). Ces programmes remplacent rlogin et rsh, et fournissent des communications sécurisées et cryptées entre deux machines qui ne sont pas sûres, et ce, sur un réseau non sécurisé. Ces programmes ont pour but d'être les plus simples possibles à installer et à utiliser.

sshd est le démon qui attend des connexions des clients. Il est normalement démarré à l'amorçage de la machine (boot) depuis /etc/rc Il crée un nouveau démon à chaque connexion entrante. Les démons créés prennent en charge l'échange de clef, le cryptage, l'authentification, l'exécution de commandes et l'échange de données. Cette implémentation de sshd supporte simultanément les versions 1 et 2 du protocole SSH. sshd fonctionne comme décrit ci-après.

Version 1 du protocole SSH

Chaque machine a une clef RSA spécifique (normalement 1024 bits), que l'on utilise pour identifier la machine. En outre, quand le démon démarre, il génère une clef RSA de serveur (normalement 768 bits). Cette clef est regénérée toutes les heures si elle a été utilisée, et n'est pas stockée sur disque.

Lorsqu'un client se connecte, le démon répond avec sa clef de machine et sa clef de serveur. Le client compare la clef RSA de la machine avec celle qu'il a stockée dans sa base de données pour vérifier si elle a changé. Le client génère ensuite un nombre aléatoire sur 256 bits. Il crypte ce nombre aléatoire avec la clef de la machine et la clef du serveur, puis envoie le nombre crypté au serveur. Les deux parties utilisent alors ce nombre aléatoire comme clef de session pour crypter toutes les communications ultérieures de la session. Le reste de la session est crypté avec un cryptage conventionnel, actuellement Blowfish ou 3DES, 3DES étant utilisé par défaut. Le client choisit l'algorithme de cryptage parmi ceux que propose le serveur.

Ensuite, le serveur et le client entrent dans la phase d'authentification. Le client essaie de s'authentifier à l'aide d'une authentification par .rhosts d'une authentification par .rhosts combinée avec une authentification RSA par machine, d'une authentification stimulation-réponse (challenge-response), ou d'une authentification par mot de passe.

Normalement, l'authentification Rhosts est désactivée, parce qu'elle n'est par définition pas sécurisée, mais peut être activée dans le fichier de configuration du serveur. On n'améliore pas la sécurité du système, tant que rshd rlogind et rexecd sont activés (et par conséquent que rlogin et rsh sont activés sur la machine).

Version 2 du protocole SSH

La version 2 fonctionne de manière similaire : Chaque machine a une clef spécifique de machine (RSA ou DSA), qui sert à identifier la machine. Toutefois, lorsque le démon démarre, il ne génère pas de clef de serveur. La sécurité ultérieure est assurée par un système de validation de clef Diffie-Hellman. Ce système de validation de clef aboutit à une clef de session partagée.

Le reste de la session est crypté à l'aide d'un cryptage symétrique, actuellement 128 bit AES, Blowfish, 3DES, CAST128, Arcfour, 192 bit AES, ou 256 bit AES. Le client choisit l'algorithme de cryptage à utiliser dans la liste proposée par le serveur. En outre, l'intégrité de la session est assurée par un code d'authentification de message cryptographique (hmac-sha1 ou hmac-md5).

La version 2 du protocole fournit une méthode d'authentification d'utilisateur par clef publique (PubkeyAuthentication) ou de machine cliente (HostbasedAuthentication), des méthodes d'authentification par mot de passe et stimulation-réponse (challenge-response).

Exécution de commandes et transfert de données

Si le client réussit à s'authentifier, on démarre un échange de préparation de la session. À ce moment, le client peut demander l'allocation d'un pseudo-terminal (pseudo-tty), des redirections de connexions X11, des redirections de connexions TCP/IP ou une redirection de la connexion à l'agent d'authentification par le tunnel sécurisé.

Enfin, le client demande soit un interpréteur de commandes (shell) ou l'exécution d'une commande. Les deux parties entrent alors dans un mode de session. Dans ce mode, chaque partie peut envoyer des données à tout moment, et ces données sont transférées depuis/vers l'interpréteur de commandes ou la commande sur le serveur, et le terminal de l'utilisateur du côté du client.

Quand le programme de l'utilisateur se termine, et que toutes les redirections X11 et autres connexions sont fermées , le serveur envoie le code de sortie de la commande au client, et les deux parties arrêtent leur exécution.

sshd peut être configuré à l'aide d'options sur la ligne de commande, ou dans un fichier de configuration. Les options de la ligne de commande outrepassent les valeurs spécifiées dans le fichier de configuration.

sshd relit son fichier de configuration quand il reçoit un signal de suspension, SIGHUP en s'exécutant lui-même avec le même nom que celui avec lequel il a été démarré, par exemple /usr/sbin/sshd

Les options sont les suivantes :

-b bits

Spécifie le nombre de bits de la clef éphémère du serveur pour la version 1 du protocole (par défaut 768).

-d

Mode de débogage. Le serveur envoie une sortie de débogage verbeuse dans le journal système, et ne passe pas à l'arrière-plan. Le serveur ne crée pas de processus fils et ne sert que pour une connexion. Cette option n'est utilisée que pour du débogage du serveur. En ajoutant des options -d, on augmente le niveau de débogage. Au maximum 3.

-e

Avec cette option, sshd envoie la sortie sur l'erreur standard au lieu du journal système.

-f configuration_file

Spécifie un nom de fichier de configuration. Par défaut /etc/ssh/sshd_config sshd ne démarre pas s'il n'y a pas de fichier de configuration.

-g login_grace_time

Donne un délai aux clients pour s'authentifier (par défaut 600 secondes). Si le client ne peut s'authentifier dans cet intervalle, se serveur se déconnecte et termine son exécution. Une valeur de 0 indique qu'il n'y a pas de limite.

-h host_key_file

Spécifie un fichier duquel on lit une clef de machine. On doit donner cette option si sshd n'est pas lancé avec le compte de root (comme les fichiers des clefs de machines ne sont normalement lisibles que par root). Par défaut /etc/ssh/ssh_host_key pour la version 1 du protocole, et /etc/ssh/ssh_host_rsa_key et /etc/ssh/ssh_host_dsa_key pour la version 2 du protocole. Il est possible d'avoir plusieurs fichiers de clef de machine pour les différentes versions du protocole et des algorithmes de clefs de machine.

-i

Spécifie que sshd est démarré par inetd. sshd n'est normalement pas démarré par inetd, parce qu'il doit générer la clef du serveur avant de pouvoir répondre au client, et ceci peut prendre des dizaines de secondes. Les clients attendraient trop longtemps si la clef était regénérée à chaque fois. Toutefois, avec des clefs de petite taille (par exemple 512), l'utilisation de sshd depuis inetd est envisageable.

-k key_gen_time

Spécifie la période de régénération, en secondes, de la clef de serveur éphémère pour la version 1 du protocole (par défaut 3 600 secondes, ou une heure). La motivation pour régénérer la clef est que cette clef n'est pas stockée, et qu'après une heure, il devient impossible de retrouver la clef pour décrypter des communications interceptées, même si la machine est piratée, ou arrêtée physiquement. Une valeur de zéro indique que la clef n'est jamais regénérée.

-o option

Sert à spécifier des options dans le format du fichier de configuration. Utile pour spécifier des options qui n'ont pas d'équivalence en ligne de commandes.

-p port

Spécifie le port sur lequel le serveur écoute les connexions entrantes (par défaut 22). On peut spécifier plusieurs options de port. Les ports spécifiés dans le fichier de configuration sont ignorés quand un port est passé en option sur la ligne de commande.

-q

Mode silencieux. On n'envoie rien au journal système. Normalement, on enregistre le début, l'authentification et la fin de chaque connexion.

-t

Mode de test. Vérifie uniquement la validité du fichier de configuration et des clefs. Utile pour mettre à jour sshd de manière fiable, car des options de configuration peuvent changer.

-u len

Sert à spécifier la taille du champ de la structure utmp qui contient le nom de la machine distante. Si le nom de la machine après résolution est plus long que len on utilise la notation décimale pointée à la place. Ceci permet de continuer à identifier de manière unique les machines avec des noms très longs, qui dépassent la capacité de ce champ. En spécifiant -u0 on impose de toujours utiliser la notation décimale pointée dans le fichier utmp On utilise aussi -u0 pour éviter à sshd de faire des requêtes DNS si le mécanisme d'authentification ne le nécessite pas. Les mécanismes d'authentification qui peuvent nécessiter un DNS comprennent RhostsAuthentication RhostsRSAAuthentication HostbasedAuthentication et l'utilisation d'une option from=pattern-list dans un fichier de clef. Les options de configuration qui nécessitent une DNS comprennent l'utilisation d'un motif USER@HOST dans les options AllowUsers ou DenyUsers

-D

En spécifiant cette option, sshd ne se détache pas du terminal et ne devient pas un démon. Ceci permet une surveillance facile de sshd

-4

Force sshd à n'utiliser que des adresses IPv4.

-6

Force sshd à n'utiliser que des adresses IPv6.

FICHIER DE CONFIGURATION

sshd lit les données de configuration depuis /etc/ssh/sshd_config (ou le fichier spécifié par l'option -f sur la ligne de commandes). Le format de ce fichier et les options de configuration sont décrits dans sshd_config5.

PROCESSUS DE CONNEXION

Lorsqu'un utilisateur se connecte avec succès, sshd procède comme suit :

1. Si la connexion est sur un terminal et qu'aucune commande n'a été spécifiée, affiche la date de dernière connexion et le contenu du fichier /etc/motd (si accepté dans le fichier de configuration ou en l'absence de $HOME/.hushlogin Voir la section Sx FICHIERS ) .
2. Si la connexion est sur un terminal, enregistre la date et l'heure de connexion.
3. Vérifie le fichier /etc/nologin ; s'il existe, en affiche le contenu et sort (sauf pour root).
4. Bascule pour s'exécuter avec les privilèges d'un utilisateur normal.
5. Paramètre un environnement de base.
6. Lit le contenu du fichier $HOME/.ssh/environment s'il existe.
7. Va dans le répertoire de base (home directory) de l'utilisateur.
8. Si le fichier $HOME/.ssh/rc existe, l'exécute ; sinon, si le fichier /etc/ssh/sshrc existe, l'exécute ; sinon, exécute xauth. Les fichiers « rc » reçoivent le protocole d'authentification et le cookie X11 en entrée standard.
9. Exécute l'interpréteur de commandes (shell) ou la commande.

FORMAT DU FICHIER AUTHORIZED_KEYS

$HOME/.ssh/authorized_keys est le fichier par défaut qui liste les clefs publiques autorisées pour l'authentification RSA pour la version 1 du protocole, et pour l'authentification par clef publique (PubkeyAuthentication) pour la version 2 du protocole. On peut utiliser l'option AuthorizedKeysFile pour spécifier un autre fichier de configuration.

Chaque ligne du fichier contient une clef (les lignes vides ou débutant par le caractère « # » sont ignorées et considérées comme des commentaires). Chaque clef publique RSA consiste en les champs suivants, séparés par des espaces : options, bits, exposant, modulo, commentaire. Chaque clef publique pour la version 2 du protocole consiste en : options, type de clef, clef encodée en base64, commentaire. Les champs d'option sont optionnels ; leur présence est déterminée par le fait que la ligne commence avec un nombre ou pas (le champ d'option ne commence jamais par un nombre). Les champs bits, exposant, modulo et commentaire déterminent la clef RSA pour la version 1 du protocole ; le champ commentaire n'est pas utilisé pour quoi que ce soit (mais peut servir à l'utilisateur pour identifier sa clef). Pour la version 2 du protocole, le type de clef est « ssh-dss » ou «ssh-rsa ».

Note : les lignes contenues dans ce fichier font en général quelques centaines de caractères (à cause de la taille du modulo de la clef RSA). Il n'est pas très judicieux de les saisir manuellement ; il est plus fiable de les copier dans les fichiers identity.pub id_dsa.pub ou id_rsa.pub puis de les coller.

sshd impose une taille minimale du modulo pour la clef RSA pour la version 1 du protocole et pour les clefs pour la version 2 du protocole de 768 bits.

Les options (s'il y en a) consistent en une liste d'entrées séparées par des virgules. Les espaces sont interdits, sauf entre des guillemets. Les spécifications d'options suivantes sont supportées. Note : les mots-clefs des options ne sont pas sensibles à la casse.

from=pattern-list

Spécifie qu'en plus de l'authentification RSA, le nom canonique de la machine distante doit figurer dans la liste des motifs séparés par des virgules (« * » et «? » sont des jokers). La liste peut aussi contenir des motifs précédés par l'opérateur de négation « ! » ; si le nom canonique de la machine correspond au motif nié, on n'accepte pas la clef. Le but de cette option est éventuellement d'améliorer la sécurité : l'authentification RSA en elle-même ne permet pas d'avoir confiance dans le réseau ou les serveurs de noms ou quoi que ce soit (à part la clef) ; par contre, si quelqu'un vole la clef, cette clef lui permet de se connecter depuis n'importe où dans le monde. Cette option supplémentaire rend encore plus difficile l'utilisation d'une clef volée (les serveurs de noms et/ou les routeurs peuvent avoir été compromis en plus de la clef elle-même).

command=commande

Spécifie que cette commande doit être exécutée si on utilise cette clef pour s'authentifier. La commande fournie par l'utilisateur (s'il y en a une) est ignorée. La commande est exécutée sur un pseudo-terminal (pty) si le client a demandé un pseudo-terminal ; sinon elle est exécutée sans terminal. Si on a besoin d'un canal 8-bits propre, on ne doit pas demander de pseudo-terminal, ou alors on spécifie no-pty On peut inclure une apostrophe (« ' ») dans la commande en la faisant précéder d'une anti-barre (« \ »). Cette option peut être utile pour restreindre à des actions spécifiques. Par exemple, une clef peut n'autoriser qu'à effectuer des sauvegardes distantes, mais rien d'autre. Note : le client doit spécifier des redirections TCP/IP ou X11 sauf s'ils sont explicitement interdits. Cette option s'applique à l'exécution d'un interpréteur de commandes (shell), d'une commande ou d'un sous-système.

environment=NAME=value

Spécifie que la chaîne de caractère doit être ajoutée à l'environnement lors de la connexion en utilisant cette clef. Les variables d'environnement définies de cette manière outrepassent les autres variables d'environnement par défaut. On peut spécifier plusieurs de ces options. Cette option est désactivée automatiquement si l'option UseLogin est activée.

no-port-forwarding

Interdit les redirections TCP/IP si on utilise cette clef pour l'authentification. Toute demande de redirection de port de la part de l'utilisateur retournera une erreur. Ceci peut être utilisé par exemple pour une connexion avec l'option command

no-X11-forwarding

Interdit les redirections X11 si on utilise cette clef pour l'authentification. Toute demande de redirection X11 de la part de l'utilisateur retournera une erreur.

no-agent-forwarding

Interdit les redirections de l'agent d'authentification si on utilise cette clef pour l'authentification.

no-pty

Empêche l'allocation de terminal (toute demande d'allocation d'un terminal virtuel échouera).

permitopen=host:port

Limite les redirections de port « ssh -L » locales de telle manière qu'il n'est possible de se connecter qu'à la machine et au port spécifiés. On peut spécifier des adresse IPv6 avec une autre syntaxe : host/port On peut spécifier plusieurs options permitopen en les séparant par des virgules. Aucune correspondance n'est effectuée sur les noms de machines, ils doivent être des adresses ou des domaines littéraux.

Exemples

1024 33 12121...312314325 ylo@foo.bar

from="*.niksula.hut.fi,!pc.niksula.hut.fi" 1024 35 23...2334 ylo@niksula

command="dump /home",no-pty,no-port-forwarding 1024 33 23...2323 backup.hut.fi

permitopen="10.2.1.55:80",permitopen="10.2.1.56:25" 1024 33 23...2323

FORMAT DU FICHIER SSH_KNOWN_HOSTS

Les fichiers /etc/ssh/ssh_known_hosts et $HOME/.ssh/known_hosts contiennent les clefs publiques de toutes les machines connues. Le fichier global doit être préparé par l'administrateur (éventuellement), mais le fichier de l'utilisateur est mis à jour automatiquement : dès que l'utilisateur se connecte depuis une machine inconnue, elle est ajoutée au fichier de l'utilisateur.

Chaque ligne de ces fichiers contient les champs suivants : noms de machine, bits, exposant, modulo, commentaire. Les champs sont séparés par des espaces.

Les noms de machines sont une liste de motifs séparés par des virgules (« * » et « ? » sont des jokers) ; chaque motif l'un après l'autre est mis en correspondance avec le nom canonique de la machine (authentification d'un client) ou avec le nom fourni par l'utilisateur (authentification d'un serveur). On peut précéder un motif du caractère « ! » pour indiquer une négation : si le nom de la machine correspond à un motif nié, il n'est pas accepté (de par cette ligne), même s'il correspond à un autre motif de la ligne.

Les bits, exposant, et modulo sont pris directement dans la clef de machine RSA ; on peut les récupérer par exemple, depuis /etc/ssh/ssh_host_key.pub Le champ de commentaire optionnel continue jusqu'à la fin de la ligne et n'est pas utilisé.

Les lignes vides ou débutant par le caractère « # » sont ignorées et considérées comme des commentaires.

Lors d'une authentification de machine, l'authentification est acceptée si une ligne a la clef appropriée. Il est donc autorisé (mais pas recommandé) d'avoir plusieurs lignes ou des clefs de machines différentes pour les mêmes noms. Cela se produit inévitablement quand on met dans le fichier les noms abrégés des noms de machines depuis des domaines différents. Il est possible que le fichier contienne des informations en conflit ; on peut s'authentifier si on trouve une information valide dans l'un des fichiers.

Note : les lignes dans ces fichiers contiennent typiquement des centaines de caractères, et il n'est pas très intéressant de les saisir manuellement. On peut plutôt les générer à l'aide d'un script, ou les récupérer dans /etc/ssh/ssh_host_key.pub et les ajouter en tête du fichier.

Exemples

 closenet,...,130.233.208.41 1024 37 159...93 closenet.hut.fi
 cvs.openbsd.org,199.185.137.3 ssh-rsa AAAA1234.....=
 

FICHIERS

/etc/ssh/sshd_config

Contient les données de configuration pour sshd Le format du fichier et les options de configuration sont décrites dans sshd_config5.

/etc/ssh/ssh_host_key, /etc/ssh/ssh_host_dsa_key,

/etc/ssh/ssh_host_rsa_key Ces trois fichiers contiennent les parties privées des clefs de la machine. Ces fichiers sont la propriété de root, sont lisibles par root, et non accessibles aux autres. Note : sshd ne démarre pas si ce fichier est accessible au groupe et/ou aux autres.

/etc/ssh/ssh_host_key.pub, /etc/ssh/ssh_host_dsa_key.pub,

/etc/ssh/ssh_host_rsa_key.pub Ces trois fichiers contiennent les parties publiques des clefs de la machine. Ces fichiers doivent être lisibles par tous, mais accessibles en écriture à root uniquement. Leur contenu doit correspondre à leur partie privée respective. Ces fichiers ne sont pas vraiment utilisés ; ils sont fournis par commodité pour l'utilisateur qui peut les copier dans ses fichiers des machines connues. Ces fichiers sont créés par ssh-keygen1.

/etc/moduli

Contient les groupes Diffie-Hellman utilisés pour le "Diffie-Hellman Group Exchange".

/var/empty

répertoire chroot(2) utilisé par sshd lors de la séparation de privilèges dans la phase de pré-authentification. Le répertoire ne doit contenir aucun fichier, est la propriété de root et n'est pas accessible en écriture au groupe ou aux autres.

/var/run/sshd.pid

Contient d'identifiant du processus (PID) du démon sshd en attente de connexions (si plusieurs démons sont en cours d'exécution en même temps sur plusieurs ports, ce fichier contient l'identifiant du dernier processus démarré). Le contenu de ce fichier n'est pas sensible ; il peut être lisible par tout le monde.

$HOME/.ssh/authorized_keys

Liste les clefs publiques (RSA ou DSA) utilisables pour se connecter avec le compte de l'utilisateur. Ce fichier doit être lisible par root (ce qui peut signifier lisible par tout le monde sur quelques machines si le répertoire de base de l'utilisateur est sur un montage NFS). Il est recommandé qu'il ne soit pas accessible aux autres. Le format de ce fichier est décrit ci-avant. Les utilisateurs y mettent le contenu de leurs fichiers identity.pub id_dsa.pub et/ou id_rsa.pub comme décrit dans ssh-keygen1.

/etc/ssh/ssh_known_hosts et $HOME/.ssh/known_hosts

Ces fichiers sont consultés si on utilise les rhosts avec une authentification par machine ou une authentification par machine pour la version 2 du protocole pour vérifier la clef publique de la machine. La clef doit être listée dans un de ces fichiers pour être acceptée. Le client utilise les mêmes fichiers pour vérifier qu'il se connecte à la bonne machine distante. Ces fichiers ne doivent être accessibles en écriture que par root et leur propriétaire. /etc/ssh/ssh_known_hosts doit être lisible par tout le monde, et $HOME/.ssh/known_hosts peut être accessible en lecture à tout le monde, mais ce n'est pas nécessaire.

/etc/nologin

Si ce fichier existe, sshd empêche quiconque de se connecter, à l'exception de root. Le contenu de ce fichier est affiché à quiconque essaie de se connecter, et les connexions non-root sont refusées. Le fichier doit être lisible par tout le monde.

/etc/hosts.allow, /etc/hosts.deny

Les contrôles d'accès qui peuvent être appliqués par tcp-wrappers sont définis dans ces fichiers. Pour plus d'informations, voir hosts_access5.

$HOME/.rhosts

Ce fichier contient les paires machine/nom d'utilisateur, séparées par un espace, une par ligne. L'utilisateur spécifié sur la machine correspondante est autorisé à se connecter sans mot de passe. le même fichier est utilisé par rlogind et rshd. le fichier doit être accessible en écriture seulement à l'utilisateur ; il est recommandé qu'il ne soit pas accessible aux autres.

Il est aussi possible d'utiliser des groupes réseau (netgroups) dans le fichier. Le nom de machine ou d'utilisateur peut être de la forme +@groupname pour spécifier toutes les machines ou tous les utilisateurs dans le groupe.

$HOME/.shosts

Pour ssh, ce fichier est exactement le même que .rhosts Cependant ce fichier n'est pas utilisé par rlogin et rshd, donc son utilisation ne permet que des accès par SSH.

/etc/hosts.equiv

Ce fichier est utilisé pendant l'authentification .rhosts Dans la forme la plus simple, ce fichier contient des noms de machine, un par ligne. Les utilisateurs sur ces machines sont autorisés à se connecter sans mot de passe, pour peu qu'ils aient le même nom d'utilisateur sur les deux machines. Le nom de machine peut aussi être suivi d'un nom d'utilisateur ; ces utilisateurs sont autorisés à se connecter sous n'importe quel nom d'utilisateur sur cette machine (à l'exception de root). En outre, la syntaxe « +@group » peut être utilisée pour spécifier des groupes réseau. Les entrées niées commencent avec « - ».

Si la machine/l'utilisateur client(e) est mis(e) en correspondance dans ce fichier, la connexion est automatiquement autorisée, pour peu que les noms d'utilisateur client et serveur soient identiques. En outre, une authentification de machine RSA réussie est normalement requise. Ce fichier ne doit être accessible en écriture qu'à root ; il est recommandé qu'il soit accessible en lecture par tout le monde.

Attention : Ce n'est presque jamais une bonne idée d'utiliser des noms d'utilisateurs dans" hosts.equiv Il faut bien être conscient du fait que cela signifie vraiment que le ou les utilisateur(s) peuvent se connecter en tant que n'importe qui et en particulier bin, daemon, adm, et les autres comptes propriétaires de binaires et de répertoires critiques pour le système. L'utilisation d'un nom d'utilisateur accorde pratiquement un accès de l'utilisateur root. La seule utilisation raisonnable des noms d'utilisateurs réside dans les entrées niées.

Note : Cet avertissement s'applique aussi à rsh/rlogin.

/etc/ssh/shosts.equiv

Ce fichier est traité exactement de la même manière que /etc/hosts.equiv Néanmoins, ce fichier peut être utile dans des environnements dans lesquels on souhaite utiliser rsh/rlogin et ssh.

$HOME/.ssh/environment

Ce fichier (s'il existe) est lu dans l'environnement lors de la connexion. Il peut ne contenir que des lignes vides, des lignes de commentaires (qui commencent par le caractère « # »), et des lignes d'affectations de la forme nom=valeur. Le fichier ne doit être accessible en écriture qu'à l'utilisateur ; il n'a pas besoin d'être accessible en lecture au groupe ou aux autres.

$HOME/.ssh/rc

Si ce fichier existe, il est exécuté avec /bin/sh après lecture des fichiers d'environnement, mais avant de démarrer l'interpréteur de commandes (shell) ou la commande de l'utilisateur. Il ne doit pas produire de sortie sur la sortie standard (stdout) ; on doit plutôt utiliser l'erreur standard (stderr). Si des redirections X11 sont en cours, il recevra la paire « proto cookie » en entrée standard (et DISPLAY dans son environnement). Le script doit appeler xauth(1) parce que sshd n'exécutera pas automatiquement xauth pour ajouter des cookies X11.

Le but premier de ce fichier est d'exécuter toutes les routines d'initialisation qui peuvent nécessaires avant que le répertoire de base (home directory) de l'utilisateur ne devienne accessible ; AFS fournit un exemple particulier d'un tel environnement.

Ce fichier contiendra probablement du code d'initialisation suivi par quelque chose comme :

 if read proto cookie && [ -n "$DISPLAY" ]; then
         if [ `echo $DISPLAY | cut -c1-10` = 'localhost:' ]; then
                 # X11UseLocalhost=yes
                 xauth add unix:`echo $DISPLAY |
                     cut -c11-` $proto $cookie
         else
                 # X11UseLocalhost=no
                 xauth add $DISPLAY $proto $cookie
         fi
 fi
 

Si ce fichier n'existe pas, /etc/ssh/sshrc est exécuté, et s'il n'existe pas non plus, xauth est utilisé pour ajouter le cookie.

Ce fichier ne doit être accessible en écriture qu'à l'utilisateur, et n'a pas besoin d'être lisible par le groupe ou les autres.

/etc/ssh/sshrc

Identique à $HOME/.ssh/rc Ce fichier peut être utilisé pour spécifier globalement des initialisations pour la connexion spécifiques à une machine. Ce fichier ne doit être accesible en écriture qu'à root et lisible par tous.

AUTEURS

OpenSSH est dérivé de la version originale et libre ssh 1.2.12 par Tatu Ylonen. Aaron Campbell, Bob Beck, Markus Friedl, Niels Provos, Theo de Raadt et Dug Song ont corrigé de nombreux bugs, ré-ajouté des nouvelles fonctionnalité et créé OpenSSH. Markus Friedl a contribué au support des versions 1.5 et 2.0 du protocole SSH. Niels Provos et Markus Friedl ont contribué au support de la séparation de privilèges.regénéré

TRADUCTION FRANÇAISE

Laurent GAUTROT <l dot gautrot at free dot fr> 05/12/2002

AVERTISSEMENT SUR LA TRADUCTION

Il est possible que cette traduction soit imparfaite ou périmée. En cas de doute, veuillez vous reporter au document original en langue anglaise fourni avec le programme.

VOIR AUSSI

scp(1), sftp(1), ssh(1), ssh-add1, ssh-agent1, ssh-keygen1, login.conf5, moduli(5), sshd_config5, sftp-server8

T. Ylonen T. Kivinen M. Saarinen T. Rinne S. Lehtinen "SSH Protocol Architecture" draft-ietf-secsh-architecture-12.txt January 2002 work in progress material

M. Friedl N. Provos W. A. Simpson "Diffie-Hellman Group Exchange for the SSH Transport Layer Protocol" draft-ietf-secsh-dh-group-exchange-02.txt January 2002 work in progress material