Red Hat Linux 7.1: Guide de référence officiel Red Hat Linux | ||
---|---|---|
Précédent | Chapitre 11. Protocole SSH | Suivant |
Une interface sécurisée en ligne de commande n'est que la première des nombreuses façons dont SSH peut être utilisé. En ayant la quantité nécessaire de bande passante, les sessions X11 peuvent être dirigées sur un canal SSH ou bien, en utilisant la retransmission TCP/IP, les connexions par port entre systèmes, considérées auparavant comme étant non sécurisés, peuvent être appliquées à des canaux SSH spécifiques.
Ouvrir une session X11 par le biais d'une connexion SSH établie est aussi facile que d'exécuter un programme X lorsque l'on exécute déjà un client X sur son propre ordinateur hôte. Lorsqu'un programme X est exécuté à partir de l'invite shell sécurisée, le client et le serveur SSH créent un nouveau canal sécurisé au sein de la connexion SSH en cours et les données du programme X sont ensuite envoyées à l'ordinateur client par ce canal, comme si la connexion au serveur X se faisait via un terminal local.
Comme vous pouvez l'imaginer, la retransmission X11 peut être très utile. Vous pourriez, par exemple, l'utiliser pour créer une session interactive sécurisée au moyen de l'interface utilisateur graphique up2date sur le serveur pour mettre à jour des paquetages de votre choix (si les paquetages Red Hat Network nécessaires sont installés sur le serveur). Pour ce faire, vous n'avez qu'à vous connecter au serveur au moyen de ssh et taper :
up2date |
On vous demande alors de donner votre mot de passe root pour ce serveur, puis l'agent de mise à jour Red Hat apparaît et vous pouvez mettre à jour vos paquetages sur le serveur comme si vous étiez confortablement assis devant cet ordinateur.
Cependant, le temps-système de traitement nécessaire pour chiffrer et déchiffrer les données sécurisées envoyées par le canal et la quantité supplémentaire de bande passante requise pour envoyer des données d'application X par le canal, peuvent être assez élevés. Il est donc nécessaire de tester correctement le tout, afin de s'assurer que le programme X est toujours utilisable, en fonction des caractéristiques de votre matériel et de votre bande passante.
La retransmission TCP/IP fonctionne de concert avec le client SSH qui demande qu'un port donné sur le client ou le serveur soit mappé sur la connexion SSH en cours.
Pour mapper un port local d'un ordinateur client à un port distant sur un serveur, vous devez d'abord connaître les numéros de port des deux ordinateurs. Vous pouvez même mapper deux ports différents et non standard l'un à l'autre.
Pour créer un canal de retransmission TCP/IP en mode de réception des connexions sur l'ordinateur hôte local, utilisez la commande suivante (tout doit être sur une seule ligne) :
ssh -L <port-local>:<nomhôte-distant>:<port-distant> <nomutilisateur>@<nomhôte> |
Remarque | |
---|---|
Afin de pouvoir définir la retransmission TCP/IP pour qu'elle puisse être en mode réception des ports inférieurs à 1024, il est nécessaire d'avoir un accès super-utilisateur, tout comme pour l'exécution de services en mode de réception des ports inférieurs à 1024. |
Par exemple, si vous voulez vérifier votre courrier sur un serveur appelé mail.domain.com au moyen du protocole POP et que SSH est disponible sur ce serveur, vous pouvez utiliser la commande suivante pour définir la retransmission TCP/IP :
ssh -L 1100:mail.domain.com:110 mail.domain.com |
Une fois la retransmission TCP/IP en place entre les deux ordinateurs, vous pouvez diriger votre client POP mail pour qu'il utilise l'hôte local comme serveur POP et 1100 comme port pour vérifier le nouveau courrier. Ainsi, toute requête envoyée au port 1100 de votre système sera redirigée en toute sécurité au serveur mail.domain.com.
Si mail.domain.com n'exécute aucun démon de serveur SSH, mais que vous pouvez tout de même vous connecter par SSH à un ordinateur tout près, au moyen d'un pare-feu par exemple, vous pouvez quand même utiliser SSH pour rendre sécurisée la partie de la connexion POP qui est faite sur un réseau public. Dans ce cas, la commande est légèrement différente :
ssh -L 1100:mail.domain.com:110 other.domain.com |
Dans cet exemple, vous transférez votre requête POP du port 1100 de votre ordinateur au moyen de la connexion SSH au port 22 de other.domain.com. Ensuite, other.domain.com se connecte au port 110 de mail.domain.com pour vous permettre de vérifier votre courrier. Seule la connexion entre vous et other.domain.com est sécurisée, mais dans nombre de cas, cela suffit pour acheminer des informations sur un réseau public de façon sécurisée et pour vous offrir plus de sécurité qu'auparavant.
Bien entendu, dans cet exemple et celui qui le précède, vous devez être en mesure de faire l'authentification auprès du serveur SSH pour pouvoir utiliser la retransmission TCP/IP. Assurez-vous d'abord de pouvoir exécuter des commandes SSH normales avant de vous lancer dans l'aventure de la retransmission TCP/IP.
La retransmission TCP/IP peut être très utile pour obtenir des informations de façon sécurisée à travers un pare-feu. Si le pare-feu est configuré de façon à permettre le trafic SSH par son port standard (22), mais bloque l'accès aux autres ports, une connexion entre deux ordinateurs hôtes qui utilisent des ports bloqués est tout de même possible en redirigeant leur communication sur une connexion SSH établie entre eux.
Remarque | |
---|---|
Cela peut par contre être très risqué. L'utilisation de la retransmission TCP/IP pour transférer des connexions de cette façon permet à tout utilisateur sur le système client de se connecter au service auquel vous transférer des connexions, ce qui peut être dangereux et peut compromettre votre système client. Vérifiez auprès de l'administrateur système qui s'occupe du pare-feu avant d'utiliser la retransmission TCP/IP pour le contourner. Les administrateurs système préoccupés par la retransmission TCP/IP n'ont qu'à désactiver cette fonction en définissant un paramètre No pour la ligne AllowTcpForwarding dans /etc/ssh/sshd_config et redémarrer le service sshd. |
Précédent | Sommaire | Suivant |
Fichiers de configuration d'OpenSSH | Niveau supérieur | Exiger SSH pour les connexions à distance |