OpenSSH : Installation et configuration
On a vu que le FTP est un moyen d'accéder à une machine et aux données qu'elle contient, mais de façon peu sécurisée. De plus le ftp reste limité à des opérations de fichiers. Si on veut pouvoir administrer un système de façon approfondie, il faut utiliser du SSH. Le SSH, pour Secure Shell, permet d'ouvrir une session comme si on était assis devant la machine, mais en passant par internet. Dans le cas d'un serveur, on restera en ligne de commande, mais il est même possible d'accéder de façon graphique à une session sur un ordinateur distant ( on verra peut-être ça dans un chapitre plus tard).
Comme le ssh permet de tout faire sur une machine, et par extension sur les machines qui constituent éventuellement son réseau local, il est important de bien sécuriser cet accès. C'est d'ailleurs l'un des ports le plus systématiquement attaqué.
Installation
Avec Webmin, il suffit de passer par l'installation automatique en sélectionnant le module "Serveur SSH" dans les modules inutilisés.
Identification par clé
L'authentification par défaut qui permet de se connecter est d'un niveau de sécurité faible et il est important de mettre en place un autre système d'authentification. Ce système utilise une clé pour encrypter le mot de passe de connexion dans un fichier stocké sur le serveur. Lors de la connexion, on enverra alors une clé de décryptage pour que le serveur puisse ouvrir ce fichier et autoriser la connexion. L'avantage de cette méthode, hormis son encryptage puissant, c'est qu'aucun bruteforce n'en viendra à bout, dans la mesure ou l'authentification ne se fait plus par association login/mot de passe. De plus, votre mot de passe n'est plus envoyé sur le réseau, mais seulement la clé publique.
Lors de la création de la clé, une passphrase vous sera demandé. Il est important de ne pas mettre le même mot de passe que pour votre session unix. Utilisez un générateur de mot de passe , ou composez-en un de 10 caractères au moins, avec minuscules, majuscules, signes de ponctuation et chiffres. Cette passphrase vous sera demandée à chaque connexion SSH ( à chaque ouverture de la clé en fait ). Tant que vous ne rentrez pas la bonne passphrase, rien n'est envoyé sur le réseau. Si vous avez la bonne, votre système autorise l'envoi de la clé publique au serveur et l'authentification se fait alors.
Une technique consiste à prendre la première lettre de chaque mot d'une phrase, en conservant la ponctuation et en jouant sur la casse et en ajoutant un peu de l33t . Un exemple ? Rien de plus simple...
| Phrase | Initiales | l33t | Casse | | Il était un petit navire, qui n'avait jamais navigué, ohé ohé | Ieupn,qnjn,oo | Ie1pn,qnjn,0o | Ie1Pn,qNjn,0o | Il a été évoqué récemment le fait que l'association de quatre ou cinq mots faciles à retenir, mais n'ayant aucun rapport les uns avec les autres, associés en une phrase surréaliste apporte une sécurité tout aussi importante qu'un mot de passe comme celui-ci, et au moins il est facile de s'en souvenir... source Rien ne vous interdit de le noter dans un coin, mais évitez de le mettre en évidence dans un fichier texte avec pour nom mot_de_passe.txt !
Mise en place de la clé
On va donc générer une clé sur le client ( l'ordinateur duquel on veut pouvoir se connecter au serveur en SSH ). Dans un terminal :
ssh-keygen -t dsa
Vous devrez alors à ce moment fournir la passphrase. Ne changez pas les emplacements et noms des fichiers, appuyez simplement sur entrée pour utiliser les valeurs par défaut. Une fois que la génération est terminée, il faut envoyer la clé au serveur. Pour cela, on utilise la commande ssh-copy :
ssh-copy-id -i /.ssh/id_dsa.pub nom_d_utilisateur@adresse_serveur
oĂą "nom_d_utilisateur" est votre login sur le serveur, et "adresse_serveur" est l'ip locale du serveur ( si vous ĂŞtes en local bien entendu ).
Pour cette fois-ci, il vous sera demandé votre mot de passe utilisateur mais lors de la prochaine connexion en SSH sur le serveur, c'est la passphrase de la clé qui vous sera demandée. Il est important de faire les réglages de la partie qui suit !
SĂ©curisation
Voici les différents réglages importants concernant la sécurité de ce serveur :
Dans "Authentification" :
- Autoriser l'authentification par mot de passe ? Non
- Permettre les noms de connexion avec des mots de passe vides ? Non
- Autoriser une connexion par root ? Non
- Autoriser l'authentification RSA ? Non
- Autoriser l'authentification DSA (SSH 2)? Oui
- Vérifier les droits d'accès sur les fichiers de clés ? Oui
- Maximum login attempts per connection 1
- Ignorer les fichiers .rhosts ? Oui
- Sauvegarder
Dans "Configuration réseau" :
- Écouter sur les adresses : ip locale du serveur
- Écouter sur le port : Il est conseillé de changer le port, afin que les scripts automatique ne trouve pas le serveur SSH. ( exemple : 300 ). Il faudra dans ce cas bien veiller à rediriger les bons ports dans le routeur.
- Accepter les protocoles: SSH v2 seulement
- DĂ©connecter en cas de panne du client ? Oui
- Temps Ă attendre pour se connecter : 120 secondes
- Autoriser la redirection TCP ? Non
- Autorise les connexions sur des ports redirigés ? Non
- Sauvegarder
Dans "Contrôle d'accès" :
- Autoriser seulement les utilisateurs : Ajoutez ici les noms d'utilisateur que vous souhaitez autoriser.
- Autoriser seulement les groupes : Ajoutez ici les noms des groupes que vous souhaitez autoriser.
- Pour toutes les autres options, cocher "Tous"
- Sauvegarder
Dans "Options diverses" :
- Autoriser le transfert de connexion X11 ? Non
- Utiliser un processus non privilégié séparé ? Oui
- Sauvegarder
Dans "Options des hĂ´tes client"/ "Tous les hĂ´tes" :
- Essayer les protocoles SSH : "2 only"
Dans "Édition des fichiers de configuration" :
- Vérifiez la présence de ces lignes dans sshd_config :
Protocol 2
AllowUsers vos_utilisateurs
ClientAliveInterval 300
ClientAliveCountMax 0
IgnoreRhosts yes
HostbasedAuthentication no
PermitRootLogin no
PermitEmptyPasswords no
Port 300 ##( port choisis plus haut )
ListenAddress 192.168.x.x ##( Ip locale de votre serveur )
UsePrivilegeSeparation yes
StrictModes yes
AllowTcpForwarding no
X11Forwarding no
PasswordAuthentication no
Un dernier réglage optionnel consiste à indiquer au système quels hôtes ont le droit de se connecter au serveur en ssh. Pour cela, éditez le fichier /etc/hosts.allow à l'aide du gestionnaire de fichiers de Webmin, et ajoutez y la ligne suivante
sshd : 192.168.x.x
Vous pouvez ajouter sur la même ligne en les séparant d'un espace les différentes ips externes des postes desquels vous autorisez la connexion.
Pour sécuriser encore un peu votre serveur et le protéger contre des attaques bruteforce, il est recommandé d'installer fail2ban. Son installation et sa configuration sont décrites dans l'appendice VIII.a