04 - Accès à distance: telnet et ssh

Introduction

Telnet est un client et un serveur.

Cette application permet de se connecter à un serveur et de pouvoir exécuter toutes les commandes comme si vous étiez connecter directement au serveur.

Il s’agit d’une prise en main à distance mais uniquement en ligne de commande.

Telnet existe sur Linux et Windows.

Le problème de telnet est la sécurité qui est grandement amélioré avec ssh.

Installation de telnet

Pour installer le client:

$ dnf install telnet

Pour installer le serveur:

$ dnf install telnet-server

Pour activer le service telnet:

$ systemctl enable telnet.socket

Pour démarrer le service telnet:

$ systemctl start telnet.socket

Fonctionnement de telnet

Pour se connecter à un serveur telnet il faut utiliser le client telnet:

$ telnet <ip ou nom du serveur telnet>

Vous devrez fournir les informations d’authentification: login et mot de passe.

Une fois connecté, toutes les commandes que vous entrez s’exécuteront sur la machine distante.

Telnet fonctionne par défaut sur le port TCP 23.

Telnet peut aussi être utilisé pour tester la connectivité d’un port tcp entre 2 machines.

Pour tester la connectivité entre deux machines, il existe ping qui utilise le protocole ICMP (Internet Control Management Protocol).

Le problème de ping est qu’il est souvent bloqué par les firewall pour éviter de donner trop d’information sur le réseau.

Comment tester la connectivité entre votre machine et un serveur installé dans un autre réseau dont vous êtes séparé par un firewall?

telnet vous permettra de valider la connectivité et de tester si le port est ouvert sur le firewall.

Exemple: vous souhaitez tester si vous arrivez à joindre votre serveur sur un port en particulier:

$ telnet [ip serveur] [port]

De cette façon vous tester non seulement la connectivité mais aussi si le port est ouvert.

Exemple:

• telnet www.google.com 80

• telnet www.google.com 443

• telnet localhost 80

Arrêtez votre serveur Apache (systemctl stop httpd) et essayez à nouveau. Que se passe-t-il?

ATTENTION: telnet ne fonctionne qu’en tcp, vous ne pourrez pas tester la connectivité avec un port UDP.

Sécurité de telnet

Le gros problème de telnet est la sécurité.

Lorsque vous vous authentifiez dans la session telnet, le mot de passe est échangé en clair sur le réseau.

En fait toutes les informations sont échangées en clair pendant une session telnet.

Pour cette raison, telnet n’est presque plus utilisé pour la prise en main à distance mais seulement pour du diagnostic.

Il n’est plus installé par défaut sur Windows.

Laboratoire 1

Vous devez avoir 2 machines Linux dans le même réseau virtuel, elles doivent pouvoir communiquer l’une avec l’autre (soit 2 machines sur votre poste, soit vous pouvez travailler à 2 en utilisant des interfaces bridge).

Le serveur telnet doit être installé sur l’une des deux machines et le client telnet sur l’autre machine.

Sur le serveur tapez:

tcpdump -i [interface] -XX -s 0 tcp port 23

À partir du client:

telnet [ip serveur]

Notez que quand vous tapez le mot de passe, chaque caractère est envoyé en clair et se voit dans la capture tcpdump.

ssh

ssh (Secure Shell)

ssh permet, entre autres, de prendre en main une autre machine Linux mais cette fois, la connexion est très fortement cryptée.

Aucun message en clair ne passe sur le réseau.

SSH utilise le port TCP 22 par défaut mais il peut être configuré pour utiliser un autre port.

Il est possible de spécifier l’utilisateur avec lequel on se connecte (l’utilisateur doit exister sur la machine cible):

$ ssh user@host

ssh est disponible sur toutes les distributions Linux et Unix.

ssh permet aussi d’exécuter une commande à distance:

$ ssh user@host commande

Laboratoire 2

Démarrez deux machines Linux (A et B).

Ouvrez une session sur A.

En vous plaçant sur A, utilisez SSH pour exécuter la commande ls sur B.

Quel est le répertoire dont vous voyez le contenu?

Pouvez-vous afficher le contenu d’un autre répertoire?

Pouvez vous donner un chemin absolu? Un chemin relatif?

Depuis A, ouvrez une session avec ssh sur la machine B.

Lancez la commande top.

Quel CPU est utilisé? Celui de A ou celui de B?

Lancez Firefox. Que se passe-t-il?

X11 Forwarding

L’interface graphique de Linux est un serveur auquel se connectent les applications pour afficher des fenêtres.

Dans l’immense majorité des cas, l’application se connecte au serveur graphique (ou serveur X11) de la machine locale.

L’application peut aussi se connecter sur le serveur graphique d’une autre machine. Dans ce cas la fenêtre s’ouvrira sur l’autre machine mais l’application s’exécutera sur la machine d’origine.

Exemple: on lance l’application sur la machine A mais l’application se connecte au serveur graphique de la machine B. Dans ce cas, l’application s’exécute sur A mais l’affichage a lieu sur B (les ressources de B seront utilisées pour gérer l’affichage).

Le fichier de configuration du serveur SSH est /etc/ssh/sshd_config.

Il faut trouver la ligne X11Forwarding et s’assurer que le paramètre est à yes:

#AllowAgentForwarding yes
#AllowTcpForwarding yes
#GatewayPorts no
X11Forwarding yes
#X11DisplayOffset 10
#X11UseLocalhost yes
#PermitTTY yes

Ensuite la fenêtre s’ouvrira si ssh est lancé à l’aide de la commande suivante :

$ ssh -X <user>@<host>

Formatif 3

Connectez vous à la machine distante en utilisant X11 forwarding.

Créez un fichier à l’aide gedit et écrivez dedans.

Sauvegardez le fichier.

Où est-il sauvegardé?

scp

SCP (SeCure Copy)

La suite ssh permet aussi de copier des fichiers entre serveurs Linux.

Pour copier du serveur local au serveur distant (dans le répertoire de l’utilisateur):

$ scp fichier user@serveur:

Ou en utilisant un chemin relatif par rapport au répertoire de l’utilisateur:

$ scp fichier user@serveur:Bureau

Ou en utilisant un chemin absolu:

$ scp fichier user@serveur:/home/user

Il est possible de copier du serveur distant au serveur local, depuis le répertoire de l’utilisateur vers le réperoire courant (chemin relatif):

$ scp user@serveur:fichier .

Ou en utilisant un chemin relatif distant et absolu local:

$ scp user@serveur:Bureau/fichier /etc

Ou absolu dans les deux cas:

$ scp user@serveur:/etc/services /etc

Laboratoire 4

Créer un fichier de test contenant votre nom.

Copiez le sur la machine distante:

• Dans le répertoire de l’utilisateur distant

• Dans /mnt. Est-ce possible? Pourquoi? Comment résoudre le problème?

Allez sur la machine distante, modifiez le fichier que vous avez placé dans /mnt pour y ajouter la date.

Retourner sur la machine locale.

Copiez le fichier se trouvant dans /mnt sur la machine distante pour le placer dans le répertoire courant.

Copiez le fichier se trouvant dans /mnt sur la machine distante pour le placer dans /mnt de la machine locale.

Les clés de chiffrements

Chiffrement symétrique:

• Les deux parties utilisent la même clé. Il faut donc que tous les participants possèdent la clé et qu’elle soit échangée de façon sécurisée.

• Problème: imaginez un site web avec 1000 visiteurs, il faudra donc gérer 1000 clés et les échanger de façon sécurisée.

Les algorythme de chiffrement symétriques:

• DES

• 3DES

• AES

• RC4

• RC5

• MISTY1

• …

Chiffrement asymétrique:

• Les deux parties utilisent des clés différentes. La clé publique permet de crypter et seule la personne possédant la clé privée sera en mesure de décrypter le message.

• Ce qui est crypté avec une clé peut uniquement être décrypté avec l’autre clé.

Chiffrement asymétrique:

• La clé publique peut être distribuée de façon illimitée à tout le monde.

• La clé privée doit être conserver précieusement de façon confidentielle.

• Problème 1: la clé publique doit être fournie de façon sécurisée sinon un pirate peut fournir à vos clients sa clé publique et pourra réaliser une attaque de l’homme du milieu.

• Problème 2: le chiffrement par clés asymétriques est 1000 fois plus lent que le chiffrement par clés symétriques.

Problème 1: la clé publique est signée au sein d’un certificat par une autorité de certification de confiance pour garantir que c’est la bonne clé publique qui est transmise.

Problème 2: le chiffrement asymétrique n’est utilisé qu’au début pour permettre l’échange sécurisé d’une clé symétrique qui ne sera valide que pour la durée de la session.

Les principaux protocoles de chiffrement sont:

• RSA (chiffrement et signature)

• DSA (signature seulement)

Pour créer un couple de clés:

$ ssh-keygen -t rsa

Generating public/private rsa key pair.
Enter file in which to save the key (/home/axel/.ssh/id_rsa): 
Created directory '/home/axel/.ssh'.
Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in /home/axel/.ssh/id_rsa.
Your public key has been saved in /home/axel/.ssh/id_rsa.pub.
The key fingerprint is:
SHA256:iCjIFYCiTFXPTjLvVDqsWjQYKNMIR0OH+xWwF1v2Z3U axel@m1.dom.local
The key's randomart image is:
+---[RSA 2048]----+
|o+B++o. o     . E|
|+=oo..+= .   . . |
|O..+.oo= .. o    |
|=oo.ooO.o  o     |
|o..o.+.BS        |
| .  o = .        |
|     o .         |
|    o            |
|   .             |
+----[SHA256]-----+

Par défaut, les clés sont créées dans ~/.ssh/ et se nomment id_rsa et id_rsa.pub.

ATTENTION: la clé privée id_rsa doit être protégée: permission 400 et ne doit jamais être distribuée.

Crypter ou signer

Crypter avec la clé publique:

• Si je crypte avec la clé publique, seule la personne ayant la clé privée pourra décrypté le message (la clé publique ne peut pas décrypter ce qui a été crypté avec la clé publique).

• Dans ce cas, la confidentialité est assurée, il s’agit bien de cryptage.

Signer avec la clé privée:

• Si je crypte avec la clé privée, toutes les personnes possédant la clé publique pourront décrypter le message, il n’y a donc aucune confidentialité. Par contre, si elles parviennent à décrypter le message à l’aide de la clé publique, cela signifie qu’il a été crypté avec la clé privée.

• Comme une seule personne possède la clé privée, cela signifie obligatoirement que le message vient de cette personne: on parle de signature.

On crypte avec la clé publique, on signe avec la clé privée.

Connexion ssh sans mot de passe

À l’aide d’un couple de clés on pourra se connecter à une machine distante en utilisant ssh sans avoir besoin de mot de passe.

Pour cela, il faudra signer le message à l’aide de la clé privée. Ceci permet de prouver notre identité.

On signe un message à l’aide de la clé privée, ce message est envoyé à la machine distante. Si la machine distante peut décrypter le message à l’aide de la clé publique correspondant à la clé privée, cela signifie que l’identité de l’utilisateur a été vérifiée et qu’il peut donc se connecter.

Pour cela, il faudra préalablement copier la clé publique sur la machine distante.

Puis il faut la placer dans le fichier ~/.ssh/authorized_keys de l’utilisateur qui sera autorisé à se connecter sans mot de passe.

Pour copier la clé dans le fichier:

$ cat id_rsa.pub > ~user/.ssh/authorized_keys

Toutes les autres clés qui seront ajoutées ensuite devront l’être avec:

$ cat id_rsa.pub >> ~user/.ssh/authorized_keys

Les permissions sur le fichier authorized_keys doivent être 600 et elles doivent être 700 sur le répertoire .ssh.

Laboratoire 5

Sur la machine locale, générez un couple de clés RSA.

À l’aide de scp, copiez la clé publique sur la machine distante.

Placez la clé publique dans le fichier authorized_keys.

Testez que vous pouvez vous connecter sans mot de passe.

Ajoutez la clé d’un deuxième utilisateur dans le même fichier authorized_keys.

Testez que les deux utilisateurs peuvent se connecter au même compte distant sans mot de passe.

Le problème est qu’il faut toujours entrer la passphrase lors d’une connexion ssh.

Pour cela on utilise la commande ssh-add qui va faire passer la passphrase à ssh-agent.

$ eval $(ssh-agent)
$ ssh-add [chemin/clef privée]

On saisit la passphrase et on peut maintenant se connecter sans entrer ni passphrase ni mot de passe.

Laboratoire 5bis

En utilisant ssh-add et ssh-agent stockez la passphrase de votre clé privée en mémoire et assurez-vous que vous pouvez maintenant vous connecter sans mot de passe ni passphrase.

Tunnel ssh

Un tunnel ssh permet de contourner les limitations imposées par un firewall.

Cela peut permettre d’accéder à un site bloqué ou bien à un service dont le port est fermé.

Le principe consiste à ouvrir une connexion ssh vers une machine extérieure puis lorsque l’on se connecte à un port donné sur la machine locale, le trafic vers ce port est redirigé dans le tunnel ssh puis vers le serveur inaccessible sur le port de notre choix.

Dans l’exemple ci-dessous, tout ce qui est envoyé à localhost sur le port 8080 sera redirigé dans le tunnel ssh puis vers le serveur web sur le port 80.

À noter que le premier port de la commande (ici 8080) peut être n’importe quel port qui n’est pas déjà utilisé (les ports de 1 à 1024 sont réservés à root).

Il est possible d’ouvrir plusieurs tunnel ssh (vers la même machine Linux ou différentes machines Linux) simultanément à condition que ce port soit différent sur chacun des tunnels.

Le deuxième port (ici 80) doit être le port sur lequel écoute le serveur distant (celui qui est inaccessible). Ce n’est pas à vous de choisir ce port, c’est celui sur lequel écoute le serveur.

Ainsi, pour un serveur SMTP, vous devrez indiquer 25, pour un serveur telnet, on utilisera 23.

À noter que dans un tunnel ssh, toutes les communications sont cryptés donc si vous utilisez telnet dans un tunnel ssh, le mot de passe ne passera pas en clair sur le réseau.

Exemple: je souhaite me connecter au site www.gyoukou.ca qui est bloqué par le firewall de mon entreprise mais je possède un serveur Linux à la maison et je sais que le firewall de mon entreprise laisse passer SSH (TCP 22).

J’exécute la commande:

$ ssh -L 8080:www.gyoukou.ca:80 root@monserveur.domaine.ca

Ensuite j’ouvre un navigateur et me connecte à l’adresse:

http://localhost:8080

Le trafic sera redirigé dans le tunnel ssh vers monserveur.domaine.ca qui redirigera le trafic vers le port 80 de www.gyoukou.ca.

J’aurai donc accès à ce site alors que le firewall l’interdit et le firewall ne verra qu’une connexion ssh entre ma machine locale et mon serveur Linux.

Laboratoire 6

Connectez vous au site www.chat.com en utilisant le port local 9090.

Vous aurez besoin de deux machines:

• Le poste sur lequel vous ouvrez une session avec votre utilisateur.

• Un poste distant jouant le rôle de votre serveur Linux à la maison.

ATTENTION: de très nombreux sites web ayant des redirections automatiques ou étant hébergés sur des serveur Apache avec des hôtes virtuels, le tunnel ssh ne fonctionnera pas.

Notez que le tunnel ssh est peu utiliser pour des sites web mais beaucoup plus pour d’autres services.

ssh pour Windows

Des outils existent sur Windows pour se connecter à des serveurs ssh ou copier de fichiers.

Les plus connus sont:

• Putty pour une connexion ssh

• WinSCP pour les copies de fichier

Les deux existent sous forme d’exécutable portable, donc rien à installer.

Laboratoire 7

Téléchargez les applications portables Putty et Winscp.

Connectez vous à une machine distante Linux en utilisant les deux outils.