sshd | Début | Suivant | Sommaire | Préc.page.lue | Accueil |
NOM | Début | Précédent | Suivant | Sommaire | Préc.page.lue | Accueil |
SYNOPSIS | Début | Précédent | Suivant | Sommaire | Préc.page.lue | Accueil |
DESCRIPTION | Début | Précédent | Suivant | Sommaire | Préc.page.lue | Accueil |
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 | Début | Précédent | Suivant | Sommaire | Préc.page.lue | Accueil |
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 | Début | Précédent | Suivant | Sommaire | Préc.page.lue | Accueil |
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 | Début | Précédent | Suivant | Sommaire | Préc.page.lue | Accueil |
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 :
FICHIER DE CONFIGURATION | Début | Précédent | Suivant | Sommaire | Préc.page.lue | Accueil |
PROCESSUS DE CONNEXION | Début | Précédent | Suivant | Sommaire | Préc.page.lue | Accueil |
FORMAT DU FICHIER AUTHORIZED_KEYS | Début | Précédent | Suivant | Sommaire | Préc.page.lue | Accueil |
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.
Exemples | Début | Précédent | Suivant | Sommaire | Préc.page.lue | Accueil |
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 | Début | Précédent | Suivant | Sommaire | Préc.page.lue | Accueil |
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 | Début | Précédent | Suivant | Sommaire | Préc.page.lue | Accueil |
closenet,...,130.233.208.41 1024 37 159...93 closenet.hut.fi cvs.openbsd.org,199.185.137.3 ssh-rsa AAAA1234.....=
FICHIERS | Début | Précédent | Suivant | Sommaire | Préc.page.lue | Accueil |
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.
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.
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.
AUTEURS | Début | Précédent | Suivant | Sommaire | Préc.page.lue | Accueil |
TRADUCTION FRANÇAISE | Début | Précédent | Suivant | Sommaire | Préc.page.lue | Accueil |
AVERTISSEMENT SUR LA TRADUCTION | Début | Précédent | Suivant | Sommaire | Préc.page.lue | Accueil |
VOIR AUSSI | Début | Précédent | Suivant | Sommaire | Préc.page.lue | Accueil |
Sommaire | Début | Suivant | Sommaire | Préc.page.lue | Accueil |
Table des mots clés | Début | Suivant | Sommaire | Préc.page.lue | Accueil |
$HOME/.rhosts | FICHIERS |
$HOME/.shosts | FICHIERS |
$HOME/.ssh/authorized_keys | FICHIERS |
$HOME/.ssh/environment | FICHIERS |
$HOME/.ssh/rc | FICHIERS |
-4 | Exécution de commandes et transfert de données |
-6 | Exécution de commandes et transfert de données |
-b bits | Exécution de commandes et transfert de données |
-d | Exécution de commandes et transfert de données |
-e | Exécution de commandes et transfert de données |
-f configuration_file | Exécution de commandes et transfert de données |
-g login_grace_time | Exécution de commandes et transfert de données |
-h host_key_file | Exécution de commandes et transfert de données |
-i | Exécution de commandes et transfert de données |
-k key_gen_time | Exécution de commandes et transfert de données |
-o option | Exécution de commandes et transfert de données |
-p port | Exécution de commandes et transfert de données |
-q | Exécution de commandes et transfert de données |
-t | Exécution de commandes et transfert de données |
-u len | Exécution de commandes et transfert de données |
/etc/hosts.allow, /etc/hosts.deny | FICHIERS |
/etc/hosts.equiv | FICHIERS |
/etc/moduli | FICHIERS |
/etc/nologin | FICHIERS |
/etc/ssh/shosts.equiv | FICHIERS |
/etc/ssh/ssh_host_key, /etc/ssh/ssh_host_dsa_key, | FICHIERS |
/etc/ssh/ssh_host_key.pub, /etc/ssh/ssh_host_dsa_key.pub, | FICHIERS |
/etc/ssh/ssh_known_hosts et $HOME/.ssh/known_hosts | FICHIERS |
/etc/ssh/sshd_config | FICHIERS |
/etc/ssh/sshrc | FICHIERS |
/var/empty | FICHIERS |
/var/run/sshd.pid | FICHIERS |
command=commande | FORMAT DU FICHIER AUTHORIZED_KEYS |
environment=NAME=value | FORMAT DU FICHIER AUTHORIZED_KEYS |
from=pattern-list | FORMAT DU FICHIER AUTHORIZED_KEYS |
no-agent-forwarding | FORMAT DU FICHIER AUTHORIZED_KEYS |
no-port-forwarding | FORMAT DU FICHIER AUTHORIZED_KEYS |
no-pty | FORMAT DU FICHIER AUTHORIZED_KEYS |
no-X11-forwarding | FORMAT DU FICHIER AUTHORIZED_KEYS |
permitopen=host:port | FORMAT DU FICHIER AUTHORIZED_KEYS |