Tout sur la commande Linux / Unix: sshd

prénom

sshd - Démon OpenSSH SSH

Synopsis

sshd -deiqtD46 -b morceaux -F config_file -g login_grace_time -h host_key_file -k key_gen_time -o option -p Port -vous len

La description

sshd (Démon SSH) est le programme de démon pour ssh (1). Ensemble, ces programmes remplacent rlogin et rsh, et fournissent des communications cryptées sécurisées entre deux hôtes non approuvés sur un réseau non sécurisé. Les programmes sont conçus pour être aussi faciles à installer et à utiliser que possible.

sshd est le démon qui écoute les connexions des clients. Il est normalement lancé au démarrage à partir de / etc / rc. Il crée un nouveau démon pour chaque connexion entrante. Les démons forkés gèrent l'échange de clés, le chiffrement, l'authentification, l'exécution de commandes et l'échange de données. Cette mise en œuvre desshd prend en charge les versions 1 et 2 du protocole SSH simultanément.

Protocole SSH version 1

Chaque hôte possède une clé RSA spécifique à l'hôte (normalement 1024 bits) utilisée pour identifier l'hôte. De plus, lorsque le démon démarre, il génère une clé RSA de serveur (normalement 768 bits). Cette clé est normalement régénérée toutes les heures si elle a été utilisée et n'est jamais stockée sur le disque.

Chaque fois qu'un client se connecte, le démon répond avec ses clés d'hôte public et de serveur. Le client compare la clé d'hôte RSA à sa propre base de données pour vérifier qu'elle n'a pas changé. Le client génère ensuite un nombre aléatoire de 256 bits. Il chiffre ce nombre aléatoire en utilisant à la fois la clé de l'hôte et la clé du serveur et envoie le numéro chiffré au serveur. Les deux parties utilisent ensuite ce nombre aléatoire en tant que clé de session utilisée pour chiffrer toutes les communications ultérieures de la session. Le reste de la session est crypté à l'aide d'un chiffrement conventionnel, actuellement Blowfish ou 3DES, 3DES étant utilisé par défaut. Le client sélectionne l'algorithme de chiffrement à utiliser parmi ceux proposés par le serveur.

Ensuite, le serveur et le client entrent dans une boîte de dialogue d'authentification. Le client tente de s'authentifier à l'aide de l'authentification .rhosts, de l'authentification .rhosts combinée à l'authentification de l'hôte RSA, de l'authentification réponse-réponse RSA ou de l'authentification par mot de passe.

L'authentification Rhosts est normalement désactivée car fondamentalement non sécurisée, elle peut être activée dans le fichier de configuration du serveur si vous le souhaitez. La sécurité du système n'est améliorée que sirshdrlogind et rexecd sont désactivés (ce qui désactive complètement rlogin et rsh dans la machine).

Protocole SSH version 2

La version 2 fonctionne de la même manière: chaque hôte possède une clé spécifique à l'hôte (RSA ou DSA) utilisée pour l'identifier. Cependant, lorsque le démon démarre, il ne génère pas de clé de serveur. La sécurité à terme est assurée par un accord de clé Diffie-Hellman. Cet accord de clé résulte en une clé de session partagée.

Le reste de la session est chiffré à l'aide d'un chiffrement symétrique, AES 128 bits, Blowfish, 3DES, CAST128, Arcfour, AES 192 bits ou AES 256 bits. Le client sélectionne l'algorithme de chiffrement à utiliser parmi ceux proposés par le serveur. De plus, 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 (PubkeyAuthentication) ou d'hôte client (HostbasedAuthentication) basée sur une clé publique, une authentification de mot de passe classique et des méthodes basées sur une interpellation / une réponse.

Exécution de commande et transfert de données

Si le client s’authentifie avec succès, une boîte de dialogue permettant de préparer la session est ouverte. À ce stade, le client peut demander des choses telles que l’allocation d’un pseudo-tty, le transfert de connexions X11, le transfert de connexions TCP / IP ou le transfert de la connexion de l’agent d’authentification sur le canal sécurisé.

Enfin, le client demande un shell ou l'exécution d'une commande. Les côtés entrent ensuite en mode session. Dans ce mode, chaque côté peut envoyer des données à tout moment, et ces données sont transférées vers / depuis le shell ou la commande côté serveur et le terminal utilisateur côté client.

Lorsque le programme utilisateur se termine et que toutes les connexions X11 et autres transférées ont été fermées, le serveur envoie l'état de sortie de la commande au client et les deux côtés se ferment.

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

sshd relit son fichier de configuration lorsqu'il reçoit un signal de raccrochage,SIGHUP en s’exécutant avec le nom sous lequel il a été lancé, c’est-à-dire / usr / sbin / sshd

Les options sont les suivantes:

-b morceaux

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

-ré

Mode débogage. Le serveur envoie une sortie de débogage détaillée au journal système et ne se place pas en arrière-plan. Le serveur ne fonctionnera pas non plus et ne traitera qu'une seule connexion. Cette option est uniquement destinée au débogage du serveur. Les options -d multiples augmentent le niveau de débogage. Le maximum est 3.

-e

Lorsque cette option est spécifiée,sshd enverra la sortie à l'erreur standard au lieu du journal système.

-F fichier de configuration

Spécifie le nom du fichier de configuration. La valeur par défaut est / etc / ssh / sshd_configsshdrefuse de démarrer s'il n'y a pas de fichier de configuration.

-g login_grace_time

Donne aux clients le temps nécessaire pour s'authentifier (valeur par défaut de 120 secondes). Si le client ne parvient pas à authentifier l'utilisateur dans ce délai, le serveur se déconnecte et se ferme.Une valeur de zéro indique aucune limite.

-h host_key_file

Spécifie un fichier à partir duquel une clé d'hôte est lue. Cette option doit être donnée sisshd n’est pas exécuté en tant que root (car les fichiers de clé d’hôte normaux ne sont normalement lisibles que par root). La valeur par défaut est / 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 du protocole 2. Il est possible de disposer de plusieurs fichiers de clé d'hôte pour les différentes versions de protocole et la clé d'hôte. algorithmes.

-je

Spécifie quesshd est exécuté à partir de inetd.sshd n'est normalement pas lancé à partir d'inetd car il doit générer la clé du serveur avant de pouvoir répondre au client, ce qui peut prendre des dizaines de secondes. Les clients devraient attendre trop longtemps si la clé était régénérée à chaque fois. Cependant, avec de petites tailles de clé (par exemple 512) utilisantsshd inetd peut être réalisable.

-k key_gen_time

Spécifie la fréquence de régénération de la clé de serveur du protocole éphémère version 1 (par défaut, 3 600 secondes ou une heure). La motivation pour régénérer la clé assez souvent est que la clé n'est pas stockée nulle part et qu'après environ une heure, il devient impossible de récupérer la clé pour déchiffrer les communications interceptées même si la machine est fissurée ou physiquement saisie. Une valeur de zéro indique que la clé ne sera jamais régénérée.

-o option

Peut être utilisé pour donner des options dans le format utilisé dans le fichier de configuration. Ceci est utile pour spécifier des options pour lesquelles il n'y a pas d'indicateur de ligne de commande séparé.

-p Port

Spécifie le port sur lequel le serveur écoute les connexions (par défaut 22). Les options de ports multiples sont autorisées. Les ports spécifiés dans le fichier de configuration sont ignorés lorsqu'un port de ligne de commande est spécifié.

-q

Mode silencieux. Rien n'est envoyé au journal système. Normalement, le début, l’authentification et la fin de chaque connexion sont consignés.

-t

Mode d'essai. Seulement vérifier la validité du fichier de configuration et la santé des clés. Ceci est utile pour mettre à joursshd fiable car les options de configuration peuvent changer.

-u len

Cette option permet de spécifier la taille du champ dans leutmp structure qui contient le nom de l'hôte distant. Si le nom d'hôte résolu est plus long que len la valeur décimale en pointillés sera utilisée à la place. Cela permet aux hôtes avec des noms d'hôte très longs débordant de ce champ d'être encore identifiés de manière unique. En précisant -u0 indique que seules les adresses décimales en pointillés doivent être placées dans le fichier utmp. -u0 est également être utilisé pour prévenirsshd de faire des demandes DNS à moins que le mécanisme d’authentification ou la configuration ne l’exige. Les mécanismes d'authentification pouvant nécessiter DNS incluentRhostsAuthenticationRhostsRSAAuthentication Authentification d'hôte et en utilisant unfrom = liste de modèlesoption dans un fichier de clé. Les options de configuration nécessitant le DNS incluent l’utilisation de USER @ HOSTpattern dansAllowUsers ouDenyUsers

-RÉ

Quand cette option est spécifiéesshd ne se détachera pas et ne deviendra pas un démon. Cela permet de surveiller facilementsshd

-4

Les forcessshd utiliser uniquement les adresses IPv4.

-6

Les forcessshd utiliser uniquement les adresses IPv6.

Fichier de configuration

sshd lit les données de configuration depuis / etc / ssh / sshd_config (ou le fichier spécifié avec -F sur la ligne de commande). Le format de fichier et les options de configuration sont décrits dans sshd_config5.

Processus de connexion

Lorsqu'un utilisateur se connecte avec succès,sshd fait ce qui suit:

1. Si la connexion est sur un terminal et qu'aucune commande n'a été spécifiée, affiche l'heure de la dernière connexion et / etc / motd (sauf indication contraire dans le fichier de configuration ou par $ HOME / .hushlogin, voir la section FILES Sx).
2. Si la connexion est sur un terminal, enregistre le temps de connexion.
3. Vérifie / etc / nologin s'il existe, imprime le contenu et se ferme (sauf si root).
4. Modifications à exécuter avec des privilèges d'utilisateur normaux.
5. Met en place l'environnement de base.
6. Lit $ HOME / .ssh / environment s'il existe et que les utilisateurs sont autorisés à modifier leur environnement. Voir lePermitUserEnvironment option dans sshd_config5.
7. Modifications apportées au répertoire de base de l'utilisateur.
8. Si $ HOME / .ssh / rc existe, l'exécute; sinon si / etc / ssh / sshrc existe, l'exécute; sinon, lance xauth. Les fichiers `` rc '' reçoivent le protocole d'authentification X11 et un cookie en entrée standard.
9. Exécute le shell ou la commande de l'utilisateur.

Format de fichier Authorized_Keys

$ HOME / .ssh / registered_keys est le fichier par défaut qui répertorie les clés publiques autorisées pour l'authentification RSA dans la version de protocole 1 et pour l'authentification par clé publique (PubkeyAuthentication) dans la version de protocole 2.AuthorizedKeysFile peut être utilisé pour spécifier un fichier alternatif.

Chaque ligne du fichier contient une clé (les lignes vides et les lignes commençant par «#» sont ignorées en tant que commentaires). Chaque clé publique RSA comprend les champs suivants, séparés par des espaces: options, bits, exposant, module, commentaire. Chaque clé publique de protocole version 2 comprend: options, type de clé, clé codée en base64, commentaire. Le champ options est facultatif. sa présence est déterminée par le fait que la ligne commence par un nombre ou non (le champ des options ne commence jamais par un nombre). Les champs bits, exposant, module et commentaire donnent la clé RSA pour la version de protocole 1; le champ de commentaire n'est utilisé pour rien (mais peut être pratique pour l'utilisateur d'identifier la clé). Pour la version 2 du protocole, le type de clé est "ssh-dss" ou "ssh-rsa"

Notez que les lignes de ce fichier ont généralement plusieurs centaines d'octets (en raison de la taille du codage de la clé publique). Vous ne voulez pas les taper dedans; copiez plutôt le fichier identity.pub id_dsa.pub ou le fichier id_rsa.pub et modifiez-le.

sshd applique une taille de module de clé RSA minimale pour les clés de protocole 1 et 2 de 768 bits.

Les options (si présentes) consistent en des spécifications d'options séparées par des virgules. Aucun espace n'est autorisé, sauf entre guillemets. Les spécifications d'option suivantes sont prises en charge (notez que les mots clés d'option ne sont pas sensibles à la casse):

from = liste de modèles

Spécifie qu'en plus de l'authentification par clé publique, le nom canonique de l'hôte distant doit être présent dans la liste de modèles séparés par des virgules («*» et «?» Servent de caractères génériques). La liste peut également contenir des modèles inversés en les préfixant par «! ; Si le nom d'hôte canonique correspond à un modèle inversé, la clé n'est pas acceptée. Le but de cette option est d’augmenter facultativement la sécurité: l’authentification par clé publique ne fait pas confiance en soi au réseau, aux serveurs de noms ou à quoi que ce soit (sauf la clé); Cependant, si quelqu'un vole la clé, celle-ci permet à un intrus de se connecter depuis n'importe où dans le monde. Cette option supplémentaire rend plus difficile l'utilisation d'une clé volée (les serveurs de noms et / ou les routeurs devraient être compromis en plus de la clé).

commande = commande

Spécifie que la commande est exécutée chaque fois que cette clé est utilisée pour l'authentification. La commande fournie par l'utilisateur (le cas échéant) est ignorée. La commande est exécutée sur un pty si le client demande un pty; sinon, il est exécuté sans tty. Si un canal propre 8 bits est requis, il ne faut pas demander de pty ou devrait spécifiernon-pty Une citation peut être incluse dans la commande en la citant avec une barre oblique inverse. Cette option peut être utile pour restreindre certaines clés publiques à une opération spécifique. Un exemple pourrait être une clé permettant des sauvegardes à distance, mais rien d’autre. Notez que le client peut spécifier le transfert TCP / IP et / ou X11 à moins que cela ne soit explicitement interdit. Notez que cette option s'applique à l'exécution du shell, de la commande ou du sous-système.

environnement = NOM = valeur

Spécifie que la chaîne doit être ajoutée à l'environnement lors de la connexion à l'aide de cette clé. Les variables d’environnement définies de cette manière remplacent les autres valeurs d’environnement par défaut. Plusieurs options de ce type sont autorisées. Le traitement de l’environnement est désactivé par défaut et est contrôlé via lePermitUserEnvironment option. Cette option est automatiquement désactivée siUtiliserLogin est autorisé.

no-port-forwarding

Interdit le transfert TCP / IP lorsque cette clé est utilisée pour l'authentification. Toute demande de transfert de port par le client renverra une erreur. Cela pourrait être utilisé, par exemple, en relation avec lecommander option.

no-X11-forwarding

Interdit le transfert X11 lorsque cette clé est utilisée pour l'authentification. Toute demande de transfert X11 du client renverra une erreur.

pas de transfert d'agent

Interdit le transfert de l'agent d'authentification lorsque cette clé est utilisée pour l'authentification.

non-pty

Empêche l'attribution de tty (une demande d'allocation d'un pty échouera).

permitopen = hôte: port

Limite locale`` ssh -L '' le transfert de port de sorte qu'il ne puisse se connecter qu'à l'hôte et au port spécifiés. Les adresses IPv6 peuvent être spécifiées avec une syntaxe alternative: port hôte Plusieurs permisouverture les options peuvent être appliquées séparées par des virgules. Aucune correspondance de modèle n'est effectuée sur les noms d'hôte spécifiés. Ils doivent être des domaines ou des adresses littéraux.

Exemples

1024 33 12121 … 312314325 [email protected]

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 de fichier Ssh_Known_Hosts

Les fichiers / etc / ssh / ssh_known_hosts et $ HOME / .ssh / known_hosts contiennent des clés publiques d'hôte pour tous les hôtes connus. Le fichier global doit être préparé par l'administrateur (facultatif), et le fichier par utilisateur est automatiquement géré: chaque fois que l'utilisateur se connecte à partir d'un hôte inconnu, sa clé est ajoutée au fichier par utilisateur.

Chaque ligne de ces fichiers contient les champs suivants: noms d’hôte, bits, exposant, module, commentaire. Les champs sont séparés par des espaces.

Les noms d'hôte sont une liste de modèles séparés par des virgules ('*' et '?' Sont des caractères génériques); chaque modèle correspond à son tour au nom d'hôte canonique (lors de l'authentification d'un client) ou au nom fourni par l'utilisateur (lors de l'authentification d'un serveur). Un motif peut aussi être précédé de `! ' pour indiquer la négation: si le nom d'hôte correspond à un modèle inversé, il n'est pas accepté (par cette ligne), même s'il correspond à un autre modèle de la ligne.

Les bits, exposant et module sont extraits directement de la clé d’hôte RSA; ils peuvent être obtenus, par exemple, dans /etc/ssh/ssh_host_key.pub Le champ de commentaire facultatif continue jusqu'à la fin de la ligne et n'est pas utilisé.

Les lignes commençant par «#» et les lignes vides sont ignorées en tant que commentaires.

Lors de l'authentification de l'hôte, l'authentification est acceptée si l'une des lignes correspondantes possède la clé appropriée. Il est donc possible (mais non recommandé) d’avoir plusieurs lignes ou différentes clés d’hôte pour les mêmes noms. Cela se produira inévitablement lorsque des formes abrégées de noms d'hôtes de différents domaines sont placées dans le fichier. Il est possible que les fichiers contiennent des informations contradictoires. l'authentification est acceptée si des informations valides peuvent être trouvées dans l'un ou l'autre fichier.

Notez que les lignes de ces fichiers comportent généralement des centaines de caractères et vous ne souhaitez certainement pas taper les clés de l'hôte à la main. Générez-les plutôt avec un script ou en prenant /etc/ssh/ssh_host_key.pub et en ajoutant les noms d’hôte au premier plan.

Exemples

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

Voir également

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

T. Ylonen T. Kivinen M. Saarinen T. Rinne S. Lehtinen "Architecture du protocole SSH" draft-ietf-secsh-architecture-12.txt janvier 2002 matériel en cours

M. Friedl N. Provos et A. Simpson "Échange de groupe Diffie-Hellman pour le protocole de couche de transport SSH" draft-ietf-secsh-dh-group-exchange-02.txt janvier 2002 matériel en cours

Important: Utilisez le homme commande ( % homme ) pour voir comment une commande est utilisée sur votre ordinateur.