Serveur SSH

Coque sécurisée ou SSH est un protocole permettant de se connecter en toute sécurité et de transférer des fichiers entre ordinateurs sur un réseau. Tout le trafic SSH est crypté afin que quiconque écoute sur le réseau ne puisse pas capturer les mots de passe, ce qui constitue une amélioration considérable par rapport aux protocoles non sécurisés telnet et FTP. D'une certaine manière, SSH peut être considéré comme un remplacement sécurisé de ces protocoles, bien qu'en fait il puisse être utilisé pour beaucoup plus.

Un serveur SSH est un processus démon qui s'exécute sur un système Unix en attente de connexions. Un client SSH est un programme exécuté par un utilisateur (ou à partir d'un script) qui se connecte à un serveur pour démarrer une session de connexion à distance ou transférer certains fichiers. Le client et le serveur s'authentifient l'un auprès de l'autre, afin que chacun puisse être sûr de l'identité de l'autre. L'authentification du client se fait soit avec un nom d'utilisateur et un mot de passe, soit avec un nom d'utilisateur et une clé privée, tandis que l'authentification du serveur utilise toujours une clé.

Il existe de nombreux clients et serveurs SSH différents, mais les deux packages client/serveur les plus courants sur les systèmes Unix sont OpenSSH open source disponible gratuitement et le SSH commercial original. De plus, il existe deux versions différentes du protocole qui ne sont pas compatibles, les versions 1 et 2. Heureusement, les dernières versions des deux packages prennent en charge les deux versions.

Le répertoire /etc/ssh contient tous les fichiers de configuration utilisés par les deux serveurs SSH, et même si les noms de fichiers sont identiques, leurs formats sont légèrement différents. Le fichier principal s'appelle sshd_config et se compose d'une série de directives, une par ligne. Comme d'habitude avec les fichiers de configuration du serveur Unix, chacun définit une option telle que la liste des utilisateurs refusés ou l'adresse IP à écouter. Le même répertoire contient également le fichier ssh_config, qui définit les options qui s'appliquent aux programmes clients SSH (tels que ssh et scp) exécutés sur votre système. Les deux fichiers sont directement édités par le module Webmin traité dans ce chapitre.

Contenu

Le module Serveur SSH

Ce chapitre traite de la configuration des serveurs commerciaux SSH et OpenSSH, et suppose que vous avez une connaissance de base des programmes clients en tant qu'utilisateur. Le module Webmin qui peut être utilisé pour effectuer cette configuration est nommé Serveur SSH se trouve dans la catégorie Serveurs. En cliquant sur son icône, vous accéderez à la page principale illustrée dans l'image ci-dessous, en supposant que le package SSH est installé.

Le module Serveur SSH

Si un message d'erreur tel que Le fichier de configuration du serveur SSH /etc/ssh/sshd_config est introuvable sur votre système apparaît à la place, il n'y a probablement pas de serveur SSH installé sur votre système. La plupart des distributions Linux modernes sont livrées avec un package OpenSSH, alors vérifiez votre CD de distribution ou votre site Web pour tous les packages dont les noms commencent par openssh ou ssh. Souvent, il y en aura plusieurs, comme openssh, openssh-client et openssh-server, qui doivent tous être installés. Vous devrez peut-être également installer la bibliothèque OpenSSL, qui devrait également être disponible sous forme de package. Utilisez le module Progiciels pour vérifier et installer tout ce qui est nécessaire.

Si aucun package SSH n'existe pour votre système d'exploitation, vous devrez télécharger, compiler et installer le code source OpenSSH ou SSH commercial. Comme vous vous en doutez, OpenSSH peut être trouvé sur http://www.openssh.org/, tandis que le SSH original peut être téléchargé sur http://www.ssh.com/. L'installation devrait être facile sur n'importe quel système d'exploitation Unix, en supposant qu'un compilateur soit installé. La seule dépendance est une bibliothèque SSL comme OpenSSL, qui peut être téléchargée depuis http://www.openssl.org/.

Après l'installation, vous devez vous assurer que le serveur SSH sera démarré au démarrage. Cela peut être fait en utilisant le module Bootup and Shutdown pour créer une action qui exécute la commande sshd au démarrage. S'il existe déjà une action nommée sshd ou ssh-server, il vous suffit de vous assurer qu'elle est activée.

Quelle que soit la manière dont vous installez le serveur SSH, il devrait permettre aux clients de se connecter et de transférer des fichiers immédiatement en utilisant la configuration par défaut, une fois le processus du serveur démarré. En fait, sur un système typique, très peu de configuration est nécessaire car les valeurs par défaut conviennent au serveur moyen.

Les deux implémentations SSH différentes et leurs nombreuses versions ont toutes des formats de fichier de configuration légèrement différents, auxquels le module doit s'adapter. Cela signifie que les formulaires et les champs qui composent son interface utilisateur ne sont pas toujours les mêmes, selon la version et le type de serveur que vous avez installé. Les instructions et les captures d'écran de ce chapitre ont été rédigées en pensant à la version 2.5 d'OpenSSH, mais toutes les différences ou fonctionnalités supplémentaires des autres versions de SSH seront également mentionnées.

Cependant, la page principale affichera toujours six icônes, sous chacune desquelles se trouve un formulaire contenant des champs permettant de définir des options liées à certaines catégories, telles que l'authentification ou la mise en réseau. En haut, l'implémentation et la version de SSH installée sont affichées, afin que vous puissiez voir lesquelles des instructions de ce chapitre s'appliquent à votre système. En bas se trouve un bouton intitulé Appliquer les modifications qui, lorsqu'il est cliqué, signale au serveur SSH de relire son fichier de configuration. Aucune modification apportée au module ne prendra effet tant que vous n'aurez pas cliqué sur ce bouton.

Authentification

Serveur SSH - Authentification ‎

Toutes les implémentations SSH ont des options liées à la façon dont les clients s'authentifient et aux messages qui leur sont affichés après la connexion. Plus précisément, vous pouvez autoriser ou refuser l'authentification par nom d'utilisateur et mot de passe ou nom d'utilisateur et certificat, empêcher l'utilisateur root de se connecter et contrôler si les fichiers .rhosts de style rlogin sont approuvés. Les options exactes diffèrent cependant beaucoup entre les versions de SSH, donc ce qui est possible avec OpenSSH peut ne pas l'être si vous utilisez le serveur SSH commercial.

Pour modifier les paramètres d'authentification, les étapes à suivre sont :

Cliquez sur Authentification sur la page principale du module pour faire apparaître un formulaire comme celui ci-dessous.
Pour que les utilisateurs soient informés s'il y a de nouveaux messages dans leurs fichiers de messagerie lorsqu'ils se connectent, sélectionnez Oui pour le Notifier l'utilisateur de l'arrivée d'un nouveau message ? domaine. Cela ne fonctionne que si vous utilisez l'emplacement standard du fichier de courrier sur votre système, et non si la livraison est effectuée dans la boîte aux lettres ou dans Maildir dans les répertoires personnels des utilisateurs.
Pour empêcher les utilisateurs de se connecter avec un mot de passe, modifiez l'option Autoriser l'authentification par mot de passe ? champ sur Non . Cela signifie que seule l'authentification par certificat sera acceptée, ce qui n'est pas très utile pour les utilisateurs qui ne se sont jamais connectés auparavant et ne peuvent donc pas créer de clé privée. Cela n'est utile que si votre système utilise des répertoires personnels montés NFS ou s'il existe un autre mécanisme permettant aux utilisateurs de définir leurs clés publiques. Ce champ n'est pas disponible si vous utilisez la version commerciale de SSH # ou supérieure.
Pour autoriser ou refuser les connexions avec un mot de passe vide (en supposant que cela soit réellement correct pour un utilisateur), modifiez le champ *Autoriser les connexions avec des mots de passe vides ?*. Vous pouvez bloquer cela jusqu'à ce que les utilisateurs aient défini leurs mots de passe par une autre méthode.
Même si une connexion root via SSH est beaucoup plus sécurisée qu'une connexion via telnet (qui n'est pas chiffrée), vous pouvez toujours l'empêcher. Pour cela, sélectionnez Non depuis le Autoriser la connexion par root ? menu. Vous pouvez également choisir Uniquement avec l'authentification RSA pour forcer les connexions root à utiliser un certificat pour l'authentification, ou Uniquement pour les commandes pour autoriser uniquement l'exécution d'une seule commande au lieu d'autoriser une connexion interactive complète. Cette dernière option n'est disponible que si votre système exécute OpenSSH version # ou supérieure.
Pour empêcher les utilisateurs d'utiliser des certificats pour s'authentifier (et donc forcer l'utilisateur de mots de passe à la place), sélectionnez Non depuis le Autoriser l'authentification RSA ? domaine. Vous voudrez peut-être le faire pour forcer les gens à saisir un mot de passe à chaque fois, au lieu de compter sur une clé privée éventuellement non chiffrée pour effectuer l'authentification à leur place.
Pour empêcher le serveur de vérifier strictement les autorisations sur les fichiers des utilisateurs dans leur répertoire ~/ssh, sélectionnez Non dans le Vérifier les autorisations sur les fichiers clés ? domaine. Même si l'activation de ces contrôles est une mauvaise idée du point de vue de la sécurité, ils peuvent être ennuyeux pour les utilisateurs qui ont défini les mauvaises autorisations et ne peuvent pas comprendre pourquoi ils ne peuvent pas être authentifiés avec un certificat.
Pour que le serveur affiche le contenu du fichier du message du jour aux utilisateurs une fois connectés, sélectionnez Oui car il Affiche /etc/motd à la connexion ? domaine. Ce fichier contient généralement des informations sur votre système ou des avis aux utilisateurs.
Si vous souhaitez qu'un message soit envoyé aux clients avant qu'ils ne se connectent, sélectionnez la deuxième option dans le champ Fichier de message de pré-connexion et entrez le chemin complet d'un fichier contenant le texte que vous souhaitez envoyer dans la zone de texte adjacente. Celui-ci contient souvent un avertissement sur l'utilisation non autorisée du système. Ce champ n'est disponible que si vous exécutez OpenSSH 2.3 ou SSH commercial version 2 ou supérieure.
Le reste des options de la page concerne l'authentification de type rlogin à l'aide des fichiers .rhosts et /etc/hosts.equiv. Parce qu'ils font confiance à l'hôte client pour avoir déjà authentifié l'utilisateur qui se connecte, ils sont plutôt peu sûrs en raison de la facilité avec laquelle une adresse IP source peut être truquée. Pour cette raison, je déconseille d'activer ce type d'authentification.
Pour enregistrer et activer vos nouveaux paramètres d'authentification, cliquez sur Enregistrer bouton en bas du formulaire suivi de Appliquer les modifications sur la page principale.

Contrôle d'accès

Serveur SSH - Contrôle d'accès ‎

Par défaut, tout utilisateur Unix sera autorisé à se connecter à distance au serveur SSH de votre système ou à l'utiliser pour télécharger et télécharger des fichiers. Sur un système de serveur de messagerie ou un système qui héberge des sites Web, cela peut ne pas être approprié - vous voudrez peut-être autoriser la plupart des utilisateurs à se connecter uniquement à vos serveurs POP3, FTP ou Usermin à la place. Bien qu'il soit possible d'y parvenir en leur donnant un shell comme /bin/false, cela pourrait causer d'autres problèmes avec les tâches utilisateur Cron ou At.

Heureusement, le serveur SSH peut être configuré pour restreindre qui peut se connecter. Suivez simplement ces étapes :

Sur la page principale du module, cliquez sur le Contrôle d'accès icône pour afficher un formulaire répertoriant les utilisateurs autorisés et refusés.
Pour bloquer tout le monde sauf quelques utilisateurs, saisissez une liste de noms d'utilisateur séparés par des espaces dans le champ Autoriser uniquement les utilisateurs domaine. Le * et ? des caractères génériques peuvent être utilisés, vous pouvez donc saisir foo* pour autoriser tout utilisateur dont le nom commence par foo . De même, pour refuser l'accès SSH à tout le monde sauf aux membres de certains groupes, remplissez le champ Autoriser uniquement les membres des groupes domaine. Les utilisateurs qui sont des membres secondaires de tout groupe correspondant seront également autorisés. Si les deux champs sont remplis, les utilisateurs spécifiés dans l'un ou l'autre seront autorisés.
Vous pouvez également bloquer uniquement quelques utilisateurs ou groupes spécifiques à l'aide de l'option Refuser les utilisateurs et Refuser les membres des groupes des champs. Encore une fois, des caractères génériques peuvent être utilisés, et si les deux champs sont remplis, les utilisateurs de l'un ou l'autre seront refusés.
Si vous utilisez un SSH commercial, les champs Autoriser uniquement les hôtes clients et Refuser les hôtes clients apparaîtra également sur le formulaire. Le premier, s'il est rempli, indique au serveur SSH de rejeter toutes les connexions à l'exception de celles provenant des adresses IP ou des noms d'hôte saisis, tandis que le second lui indique de refuser uniquement les hôtes et les adresses répertoriés dans le champ adjacent. Les deux champs acceptent les * et ? caractères génériques. Si OpenSSH est installé sur votre système, vous pouvez utiliser les fichiers de configuration TCP-wrappers /etc/hosts.allow et /etc/hosts.deny pour bloquer les clients non approuvés à la place. Malheureusement, il n'existe pas encore de module Webmin standard pour éditer ces fichiers.
Cliquez sur Enregistrer en bas de la page pour mettre à jour le fichier de configuration du serveur SSH et revenir à la page principale.
Cliquez sur Appliquer les modifications bouton pour activer les nouvelles restrictions.

Mise en réseau

Serveur SSH - Mise en réseau ‎

Le serveur SSH dispose de plusieurs options qui vous permettent de configurer l'adresse IP sur laquelle il écoute, le port qu'il utilise et divers paramètres liés au protocole. Pour les modifier, procédez comme suit :

Cliquez sur Réseau sur la page principale du module pour faire apparaître le formulaire illustré dans la capture d'écran ci-dessous.
Par défaut, le serveur acceptera les connexions établies à n'importe quelle adresse IP de votre système. Pour changer cela (peut-être parce que vous souhaitez qu'il ne soit accessible qu'à partir d'un réseau local interne), sélectionnez le deuxième bouton radio dans l'adresse d'écoute champ et entrez une adresse IP dans la zone de texte. Si vous exécutez OpenSSH version 3 ou supérieure, ce champ contiendra à la place un tableau dans lequel vous pourrez entrer plusieurs adresses et ports. Au-dessus se trouvent deux boutons radio - Toutes les adresses qui, s'il est sélectionné, indique au serveur d'accepter les connexions au port par défaut sur n'importe quelle adresse IP, et Entrée ci-dessous qui indique que les adresses et les ports du tableau doivent être utilisés. Comme d'habitude avec les tableaux dans Webmin, celui-ci aura toujours une seule ligne vide en bas pour ajouter une nouvelle adresse et un nouveau port. Si aucun n'a encore été défini, ce sera tout ce qu'il contiendra. La signification des champs dans les deux colonnes du tableau est :*Adresse *Dans ce champ, vous devez saisir une adresse IP ou un nom d'hôte unique pour le serveur à répertorier. Port *Si *Par défaut est sélectionné dans cette colonne, le port standard défini à l'étape 3 sera utilisé. Alternativement, si la deuxième option est sélectionnée, le serveur SSH écoutera sur le port entré dans la zone de texte de la colonne.
Pour modifier le port sur lequel le serveur SSH écoute les connexions, modifiez le Listen on port domaine. Si vous le modifiez, les clients devront spécifier le nouveau port lors de la connexion. Si votre système utilise OpenSSH 3 ou supérieur, ce champ définit uniquement le port par défaut qui peut être remplacé dans l'adresse d'écoute table.
Dans Accepter les protocoles cochez les cases des versions de protocole SSH que votre serveur doit accepter. Il est généralement judicieux d'autoriser les deux, afin que les clients plus anciens ou plus récents puissent se connecter sans difficulté. Ce champ n'apparaît que si vous exécutez OpenSSH - le SSH commercial n'accepte que la version 1 ou
selon la version de SSH que vous avez installée.
Si vous utilisez un SSH commercial, le délai d'inactivité peut être utilisé pour déconnecter les clients qui n'ont ni envoyé ni reçu de données pendant un certain temps. Sélectionnez le deuxième bouton radio, entrez une période de temps dans la zone de texte et sélectionnez les unités pour cette période dans le menu. Si par défaut est sélectionné, les clients ne seront jamais coupés, quelle que soit la durée d'inactivité. Sur un système occupé, cette fonctionnalité peut être utile pour empêcher les personnes de laisser des sessions SSH inactives ouvertes pendant des jours, chacun ayant un processus sshd et shell associé consommant de la mémoire.
Pour que le serveur SSH déconnecte les clients qui ont été arrêtés ou qui se bloquent sans se déconnecter correctement, sélectionnez Oui dans le Se déconnecter si le client a planté ? domaine. Le serveur enverra périodiquement des messages au client pour s'assurer qu'il est toujours en cours d'exécution et fermera la connexion s'il n'y a pas de réponse. La seule fois où vous voudriez choisir Non est si ce trafic supplémentaire cause des problèmes sur votre réseau, comme l'activation automatique d'une connexion RNIS ou commutée alors que ce n'est pas vraiment nécessaire.
Pour configurer le temps pendant lequel le serveur attendra qu'un client s'authentifie une fois qu'il s'est connecté, modifiez le Temps d'attente pour la connexion domaine. Si Pour toujours est choisi, le serveur ne déconnectera jamais un client, peu importe le temps que cela prendra, ce qui pourrait permettre à un attaquant de surcharger votre système en établissant de nombreuses connexions SSH qui ne font rien.
L'une des fonctionnalités les plus intéressantes du protocole SSH est sa prise en charge de la redirection de port, qui permet aux clients d'accéder à des ports sur le réseau du serveur auxquels ils ne pourraient normalement pas accéder. Même si cela est très utile pour les utilisateurs, vous pouvez le considérer comme un risque de sécurité car cela permet à quiconque peut créer un SSH de contourner efficacement les restrictions d'adresse IP sur les serveurs internes. Pour désactiver cette fonctionnalité, modifiez l'option Autoriser le transfert TCP ? champ sur Non . Ce champ n'apparaît que si vous exécutez SSH commercial version 2 ou supérieure, ou OpenSSH.
Un champ connexe est Autoriser la connexion aux ports transférés ? qui détermine si les hôtes autres que le serveur lui-même sont autorisés à se connecter aux ports renvoyés au client. Vous pouvez définir ceci sur Non pour protéger les utilisateurs du client contre les attaquants qui utilisent à mauvais escient des connexions transférées potentiellement non sécurisées vers le réseau du client. Cependant, il n'apparaît que si votre système exécute OpenSSH version 2 ou supérieure.
Pour que le serveur recherche les noms d'hôte pour les adresses client, puis l'adresse de ces noms d'hôte et bloque ceux qui ne correspondent pas, sélectionnez Oui dans le champ *Reverse-validate client IP address?*. Ceci est utile si vous avez mis en place des contrôles d'accès basés sur le nom d'hôte et que vous souhaitez détecter les attaquants utilisant des enregistrements DNS falsifiés. Ce champ n'est visible que si vous utilisez OpenSSH version 2.3 ou supérieure.
Pour enregistrer et activer vos modifications, cliquez sur Enregistrer bouton en bas de la page, puis Appliquer les modifications sur la page principale du module. Ils prendront effet pour toute nouvelle connexion client.

Options de l'hôte client

Même si ce module est principalement destiné à la configuration d'un serveur SSH, il vous permet également de définir des options qui s'appliquent à toutes les connexions client établies à partir de votre système à l'aide des commandes ssh et scp. Les options peuvent être définies pour les connexions à tous les hôtes, ou juste à un spécifique. Vous pouvez définir le port auquel se connecter, le protocole à utiliser et les ports locaux et distants à transférer.

Les paramètres définis dans ce module s'appliquent à tous les utilisateurs de votre système, mais peuvent être remplacés par des utilisateurs individuels qui modifient leurs fichiers ~/.ssh/config. Cela peut être fait manuellement ou à l'aide de Usermin, qui dispose d'un module client SSH avec une interface identique à celle documentée ici pour l'édition des paramètres clients globaux. De nombreux paramètres n'ont pas beaucoup de sens à définir pour tous les utilisateurs, même s'il est possible de le faire en utilisant Webmin. Pour cette raison, les instructions de cette section ne couvrent que les champs utiles au niveau global.

Options d'hôte client

Pour définir les paramètres des connexions à un hôte spécifique, procédez comme suit :

Sur la page principale du module, cliquez sur les Options de l'hôte client icône. Une page contenant une icône pour chacun des hôtes pour lesquels des options ont été définies s'affichera. À moins que vous n'ayez utilisé cette page auparavant uniquement pour le spécial Tous les hôtes apparaîtra, sur laquelle vous pourrez cliquer pour modifier les options de connexion à n'importe quel hôte.
Cliquez sur Ajouter des options pour l'hôte client lien en bas de page pour faire apparaître un formulaire permettant de spécifier un hébergeur et les options qui s'y appliquent. Tous les champs de ce formulaire ont une valeur Par défaut option qui, si elle est sélectionnée, indique que le paramètre pour tous les hôtes doit être utilisé à la place. Cela vous permet de définir des options globalement, puis de les remplacer pour chaque hôte.
Dans les Options pour l'hôte , saisissez le nom de l'hôte (tel qu'utilisé dans la commande ssh) auquel les options s'appliqueront. Des caractères génériques peuvent être utilisés, vous pouvez donc entrer *.webmin.com pour correspondre à n'importe quel hôte dans webmin.com domaine par exemple. N'oubliez pas que le nom doit correspondre à celui utilisé par les utilisateurs dans la commande ssh ou scp, donc si vous entrez foo et qu'un utilisateur exécute ssh foo.example.com, les options ne s'appliqueront pas, même si les deux noms correspondent à la même adresse IP. Pour cette raison, vous pouvez entrer le nom d'hôte sous la forme foo* saisir les deux possibilités.
Pour que les clients SSH se connectent à un autre nom d'hôte à la place, remplissez le Nom d'hôte réel auquel se connecter domaine. Cela pourrait être utile s'il est combiné avec le port auquel se connecter champ pour rediriger secrètement les connexions utilisateur vers un hôte vers un port sur une autre adresse qui est en fait un tunnel quelconque vers la destination réelle.
Pour forcer les clients à utiliser un port différent par défaut, remplissez le Port auquel se connecter domaine. Ceci est utile si le serveur SSH de certains hôtes s'exécute sur un port différent du 22 habituel et que vous souhaitez éviter d'avoir à spécifier explicitement le port dans chaque commande ssh et scp.
Normalement, le client SSH traite le caractère ~ (tilde) comme un échappement qui indique que le prochain caractère entré par l'utilisateur est en fait une commande au programme ssh lui-même. Par exemple, ~. ferme la connexion et ~^Z suspend le programme. Le caractère d'échappement peut être utilisé pour utiliser quelque chose de différent en sélectionnant le troisième bouton radio et en saisissant un seul caractère dans la zone de texte adjacente. Ou vous pouvez désactiver complètement la prise en charge de l'échappement en sélectionnant Aucun . Cette dernière option est utile si vous utilisez la commande ssh pour transférer des données binaires pouvant contenir un tilde.
Par défaut, le client et le serveur SSH compressent et décompressent les données échangées, ce qui peut accélérer les transferts importants de texte ou d'autres données compressibles. Cependant, cela peut parfois ralentir les choses ou constituer une perte de temps CPU inutile, par exemple si vous utilisez scp pour copier de nombreux fichiers GIF ou si vous vous connectez toujours à l'hôte via un réseau rapide. Pour désactiver la compression, modifiez le champ Compresser le trafic SSH ? champ sur Non . Si la compression est activée, le Niveau de compression Le menu contrôle le compromis entre l'utilisation du processeur et la quantité de bande passante utilisée. Si *1* est sélectionné, très peu de compression est effectuée, alors que si *9* est sélectionné, beaucoup plus de temps CPU sera consacré à la réduction de la quantité réelle de données transférées. Ces champs et ceux des deux étapes suivantes ne sont pas disponibles si votre système exécute la version 3 ou supérieure de SSH commercial.
Par défaut, les clients SSH utiliseront le port source privilégié 22 lors de la connexion, ce qui indique au serveur qu'il s'agit d'un programme de confiance et peut donc être invoqué pour fournir des informations correctes sur l'utilisateur qui l'exécute. Cela est nécessaire pour que l'authentification de type rlogin fonctionne, mais malheureusement, de nombreux réseaux ont leurs pare-feu configurés pour bloquer les connexions avec des ports source privilégiés, ce qui bloque complètement SSH. Pour que les clients utilisent un port normal à la place, sélectionnez Non pour le Utiliser des ports sources privilégiés ? domaine. À moins que vous n'utilisiez une authentification basée sur l'hôte, cela ne causera aucun dommage.
Pour définir les versions du protocole SSH que les clients essaieront lors de la connexion à ce serveur, choisissez Sélectionné dans le champ *Try SSH protocols* et cochez ceux à essayer. La valeur par défaut est d'essayer les deux.
Cliquez sur Créer en bas de la page pour enregistrer les nouveaux paramètres par hôte. Ils seront utilisés par toutes les nouvelles connexions client établies à partir de votre système à partir de maintenant.

Modifier les options de l'hôte

Une fois qu'un ensemble d'options d'hôte est créé, une icône pour l'hôte apparaît sur la page Options d'hôte client. Vous pouvez cliquer sur cette icône pour afficher son formulaire d'édition, apporter des modifications aux mêmes champs et appuyer sur Enregistrer bouton. Ou pour supprimer l'hôte et rétablir les connexions aux options par défaut, appuyez sur Supprimer sur le même formulaire. Il est également possible de modifier les valeurs par défaut qui s'appliquent à toutes les connexions en cliquant sur le spécial Tous les hôtes icône et apporter des modifications sur le formulaire qui apparaît. Bien sûr, certains champs n'ont pas vraiment de sens dans ce contexte, comme *Nom d'hôte réel auquel se connecter* et Port auquel se connecter , et ne doit donc pas être utilisé.

Configuration de la clé SSH utilisateur

Avant qu'un utilisateur Unix puisse utiliser l'authentification par certificat pour se connecter à un serveur SSH, il doit générer une clé privée avec la commande ssh-keygen. Ce module peut être configuré pour fonctionner avec le module Utilisateurs et groupes afin d'exécuter cette commande pour tous les utilisateurs nouvellement créés. Si votre réseau utilise des répertoires personnels montés sur NFS, cela permettra aux nouveaux utilisateurs de se connecter à d'autres hôtes sans avoir à fournir de mot de passe et aucune configuration supplémentaire n'est nécessaire. Pour configurer la configuration de SSH pour les nouveaux utilisateurs, suivez ces étapes :

Sur la page principale du module, cliquez sur Configuration de la clé SSH utilisateur icône.
Vérifiez la clé SSH de configuration pour les nouveaux utilisateurs Unix case à cocher, afin que ssh-keygen soit exécuté pour les nouveaux comptes.
Pour que la clé publique du nouvel utilisateur soit ajoutée à la liste des clés autorisées à utiliser son compte, cochez la case *Copier la nouvelle identification.pub dans les clés autorisées*. S'il n'est pas sélectionné, ils devront le faire manuellement avant que l'authentification avec leur nouveau certificat ne soit acceptée.
Pour définir une phrase secrète pour les clés privées des nouveaux utilisateurs, cochez la case Utiliser le mot de passe comme phrase secrète de clé boîte. Si elle n'est pas cochée, aucune phrase de passe ne sera définie (ce qui est plus convivial, mais moins sécurisé).
Cliquez sur Enregistrer pour que Webmin commence à utiliser vos nouveaux paramètres.

Options diverses

Serveur SSH - Options diverses ‎

Cette page contient des options qui ne rentrent dans aucune des autres catégories. Certaines des options les moins évidentes mais utiles sont :

Autoriser le transfert de connexion X11 ?: Si défini sur Oui, les utilisateurs qui établissent une connexion SSH à partir d'une machine Unix pourront exécuter des applications X sur le serveur et la connexion X sera tunnellisée via la connexion SSH vers leur écran local.
Installation de journal système: La fonction syslog utilisée pour consigner les messages d'erreur et d'information du serveur SSH. Cela peut être utilisé en conjonction avec le module System Logs pour contrôler dans quel fichier les messages SSH sont écrits.
Intervalle de régénération de la clé du serveur: La fréquence à laquelle le serveur SSH a régénéré la clé utilisée pour chiffrer les connexions. Si vous êtes paranoïaque à propos de la sécurité, réglez-le sur un nombre inférieur.

Clés SSH de l'hôte

Serveur SSH - Clés SSH hôtes ‎

voir aussi

Configurer une autorité de certification
Configuration SSH