Utilisation avancée de ssh
Présentation du protocole SSH
Le protocole SSH (Secure Shell) offre un service de connexion sécurisée à distance (port 22 en TCP/IP). Il est (souvent) basé sur un serveur (sshd) et un logiciel client (la commande ssh). Ce service remplace les anciens protocoles de connection à distance comme telnet, rsh ou rlogin. Avec ces derniers les informations transitent en clair sur le réseau ce qui permet leur interception.
L'authentification dans SSH peut se faire par mot de passe ou par l'utilisation de clefs asymétriques. A cause de l'utilisation de mot de passe le protocole est sensible aux attaques brutales (tentatives de connexions multiples basées sur des dictionnaires de mots de passe).
Conseil : Le protocole SSH ne doit pas être ouvert sur l'internet sans limitation d'accès. Pour le protéger, vous devez utiliser un logiciel comme DenyHosts (fermeture des accès après trois tentatives) ou mettre en place un service de Port Knocking (ouverture du port SSH à la demande sur la base d'une procédure définie à l'avance, c'est donc un secret partagé entre l'administrateur du serveur et son utilisateur).
Vérification du service SSH
- Vérifiez la présence des packages :
yum list "*openssh*"
- Démarrez le service sshd :
service sshd restart
- Vérifiez le :
service sshd status netstat -tap | grep ssh
- Testez le :
ssh -v localhost
Limiter l'accès à SSH
Le serveur sshd reconnait et utilise les fichiers /etc/hosts.allow et /etc/hosts.deny pour respectivement autoriser ou interdire l'accès au service SSH. Chaque ligne de ces fichiers a la forme suivante (consultez la page de manuel pour plus de précisions man 5 hosts_access) :
liste-de-démons : liste-de-machines-clientes [ : commande-shell ]
♦ Modifiez ces fichiers afin d'interdire l'accès à votre serveur SSH depuis les machines du réseau ISL (l'utilisation locale doit fonctionner).
♦ Même fonction, mais en autorisant l'accès depuis une machine particulière (choisie par vos soins).
♦ Faites en sorte de tracer les connexions refusées dans un fichier (par exemple /var/log/ssh-refusal).
Redirection du trafic X
Présentation : Un utilisateur connecté de manière distante a souvent besoin d'utiliser des logiciels graphiques. Pour ce faire, il va être amené à mettre en place une liaison client/serveur entre son serveur X (son écran graphique) et son logiciel (le client X). Malheureusement cette liaison n'est pas protégée et son travail peut donc être observé. Pour éviter ce problème, le protocole SSH permet d'encapsuler le trafic X dans le tunnel sécurisé.
♦ Commencez par lire les fichiers de configuration du serveur sshd (fichier /etc/ssh/sshd_config) et du client ssh (fichier /etc/ssh/ssh_config). Vérifiez que la redirection de X est acceptée par le serveur et le client.
♦ Connectez vous par ssh sur d'autres machines et testez le bon fonctionnement de la redirection du trafic X. Sur la machine distante, observez la valeur de la variable d'environnement DISPLAY. Elle indique le faux serveur X géré par ssh.
Port forwarding avec ssh
Soient trois machines (m1, m2, et m3) la votre étant la première. Faites en sorte que le service telnet soit ouvert sur m3. Connectez vous par ssh à partir de m1 vers m2 en demandant l'ouverture d'un tunnel IP du port 9000 de la machine m1 vers le port telnet (23) de la machine m3.
ssh machine-passerelle -L port-local:machine-destination:port-destination
Avec netstat vérifiez que le processus client ssh écoute bien le port 9000 sur la machine m1. Tentez ensuite de vous connecter sur m3 en utilisant le tunnel :
telnet localhost 9000
Authentification par clé publique/privée
Présentation : Malgré le mécanisme de cryptage, le protocole SSH est sensible à une attaque du type Man In the Middle. Dans cette situation, le client dialogue (sans le savoir) avec un faux serveur qui, lui-même, renvoie les données vers le serveur (qui pense les recevoir du vrai client). Lors de ces échanges le mot de passe envoyé par le client va être capté et enregistré par l'espion.
+- Espion ------------------------+
| |
client --------> faux-serveur --> faux-client --------> Serveur
| |
+---------------------------------+
Pour éviter que le mot de passe ne transite par le réseau, nous allons mettre en place une authentification basée sur un système de clef publique (installée sur le poste serveur) et de clef privée (installée sur le poste client).
Vous pouvez lire cette page ou chercher d'autres ressources pour comprendre la cryptographie à clé publique.
Authentification par clés
♦ Pour cet exercice, vous devez travailler avec un autre groupe ou un autre utilisateur de la même machine. Conseil : vous pouvez aussi utiliser votre compte sur le serveur du département (machine sol.dil.univ-mrs.fr). Commencez par générer une pair de clés avec la commande ssh-keygen. Donnez à l'autre groupe votre clé publique (fichier ~/.ssh/*pub) pour qu'il la place dans sa liste de clefs autorisées (fichier ~/.ssh/authorized_keys).
♦ Vérifiez ensuite que vous pouvez vous connecter sur le compte de l'autre groupe en donnant le mot de passe qui chiffre votre clé privée et non pas le mot de passe de l'autre groupe.
Très important : lors de la construction des clefs, vous devez absolument donner une passphrase pour chiffrer votre clef privée. Si cette clef n'est pas chiffrée, alors un pirate s'introduisant sur la machine cliente peut récupérer la clef et donc, se connecter sur les postes serveurs sans donner de mot de passe.
Utilisez l'agent d'authentification
Vérifiez que le démon ssh-agent est bien accessible par tous les processus de votre session en observant les variables d'environnement :
printenv | grep -i SSH
Ajoutez votre identité au cache géré par ssh-agent avec la commande ssh-add. Vérifiez ensuite cette ajout avec « ssh-add -l ». Vous devez maintenant être capable de vous connecter sur le compte de l'autre groupe sans avoir à donner le mot de passe de votre clé privée.
Synchronisation de répertoires par ssh
Utilisez la commande rsync pour copier un répertoire d'une machine à une autre :
rsync -av -e ssh répertoire-source \
utilisateur@machine-destination:répertoire-destination