Ceci est une ancienne révision du document !



SSH avancés

Cette page présente les usages avancés de SSH, ou particuliers répondant à un besoin très précis.

Voir sur SSH bases pour les usages les plus courants de SSH et sa configuration de base.

Il peut arriver (en entreprise, dans un cybercafé…) qu'il y ait un mandataire (« proxy ») HTTP. Pour initier une connexion vers un poste de l'extérieur il est nécessaire d'utiliser l'outil connect-proxy.

Installer le paquet connect-proxy.

Editer le fichier /etc/ssh/ssh_config pour y ajouter les adresses IP extérieures :

host ip_du_pc_distant
ProxyCommand connect-proxy -H adresse.du_proxy:port %h %p

Remplacer ip_du_pc_distant et adresse.du_proxy:port par ce qui convient. Vous pouvez maintenant vous connecter à travers votre mandataire en toute transparence, avec la commande ssh.

Quand on utilise SSH L'authentification par clé publique, le serveur distant peut limiter l'utilisation de certaines commandes permises.
Si vous maintenez un dépôt cvs , vous pourriez utiliser des lignes comme ceci dans le fichier authorized_keys2 :

command="/usr/bin/cvs server" ssh-dss <nom_commande> 

Ceci permettrait que seule cette commande puisse être utilisée à l'exception d'autres.

L'authentification par clé publique (voir ci-dessus) peut également être employée pour automatiser les tâches qui exigeraient habituellement l'introduction au clavier d'un mot de passe.
Imaginez vouloir copier un dossier à partir d'un ordinateur distant tous les jours à minuit. Tout ce que vous avez à faire c'est d'établir la confiance entre ces deux ordinateurs.
Créez un compte de service sur un ordinateur, créez une paire de clés (ssh-keygen -t dsa) et quand on vous demande de rentrer la passphrase tapez juste sur la touche « Entrée ». Ceci fera que votre clé privée ne sera pas protégée. Ajoutez la clé publique de l'autre ordinateur dans le fichier authorized_keysssh-copy-id »).

Maintenant vous pouvez utiliser SSH sur cette machine sans une passphrase à taper. Ajoutez une référence à SSH dans votre crontab et vous êtes prêt.

Avoir une clef privée non protégée peut être une faille de sécurité. Les intrus devront seulement obtenir l'accès à la clé privée et pourront accéder aux ordinateurs distants.

Si vous devez fréquemment copier des fichiers avec SSH ou accéder à d'autres ordinateurs de votre réseau (ce qui est une tâche commune pour des administrateurs), vous vous demandez probablement s'il y a une manière de simplifier l'utilisation de la passphrase. En fait il y a SSH agent. Vous devez seulement entrer votre passphrase une fois en employant ssh-add et tout ce que vous commencez comme sous-processus de SSH agent se rappellera cette passphrase.

Trop théorique ? Bien, vous n'aurez pas besoin de vous inquiéter de l'agent. Votre session X est prête pour avoir le ssh-agent en session automatiquement. Tout ce que vous devez faire c'est lancer ssh-add et saisir votre passphrase. La prochaine fois que vous utiliserez SSH pour accéder à un autre ordinateur, vous n'aurez pas à entrer à nouveau votre passphrase. Cool, non ? :-)

  • Vous devrez bloquer votre session pendant vos absences car d'autres pourraient accéder aux ordinateurs distants à partir de votre machine sans savoir votre passphrase.
  • Si vous voulez rentrer votre passphrase une fois juste après l'ouverture de session, vous pouvez ajouter un appel à ssh-add comme ceci :
    • Cliquez sur Système → Préferences → Sessions → Programme au démarrage.
    • Cliquez sur « Ajouter ».
    • Entrez la commande « ssh-add ».

À la prochaine ouverture de session, vous devrez taper votre passphrase.

Vous pouvez :

  • Utiliser le mode natif de base de SSH, voir SSH bases
  • Utiliser le mode natif avancé de SSH : les directives Chroot et Match de SSH, qui permettent de limiter pour certains utilisateurs l'utilisation du ssh au sftp et dans un répertoire déterminé. Voir sftp avec Chroot pour les détails.
  • Utiliser MySecureShell (s'installe en plus de openssh-server)

MysecureShell ajoute une couche au dessus de SSH sur le serveur et demande l'emploi de Java sur le client pour disposer d'une interface graphique de paramétrage de SSH/SFTP. Cela n'apporte toutefois aucune fonction ni sécurité supplémentaire par rapport au mode natif avancé.

Tunnéliser sa connexion Web est très utile dans quelques situations :

  • l'admin du réseau où vous êtes vous empêche d'accéder à certains sites ;
  • votre connexion Web est peu ou pas sécurisée (wifi sans chiffrement (encryption) ou par chiffrement WEP).

On va donc installer le serveur de médiation Squid (serveur mandataire) sur une machine Ubuntu (qui sera le serveur) à laquelle on accèdera par une machine distante possédant un client SSH et un navigateur Web. Dans l'exemple présent, ce sera un client sous Windows.

On obtiendra alors un accès sécurisé à un mandataire distant (le serveur sous Ubuntu) qui se connectera aux sites Web et renverra le résultat à votre navigateur.

Partie serveur

Premièrement, il faut installer le programme Squid. Le paquet à installer est squid.

Normalement si tout se déroule bien, Squid devrait être fonctionnel. Il est probable qu'une erreur arrive car le programme de configuration n'arrivera pas à trouver le nom d'hôte de la machine. Il faut donc ouvrir le fichier de configuration de Squid et lui indiquer que la machine n'a pas de nom d'hôte. On ouvre le fichier de configuration /etc/squid/squid.conf et on ajoute cette ligne :

visible_hostname none

Après l'enregistrement du fichier de configuration, vous pouvez normalement générer les répertoires qui contiendront le cache de Squid par la commande :

sudo squid -z

Grâce à SSH, les connexions reçues par Squid seront des connexions provenant du serveur lui-même. Mais par défaut, Squid n'accepte que les connexions loopback. On devrait alors quand même ajouter une autorisation pour l'adresse IP non loopback (127.0.0.1) du serveur. Vous ouvrez donc le fichier de configuration et vous ajoutez ces deux lignes :

acl ordi src 192.168.1.1
http_access allow ordi

Dans l'exemple, ordi est le nom choisi pour la règle et 192.168.1.1 est l'adresse IP locale de l'ordinateur. Vous pouvez donc maintenant démarrer Squid par :

sudo squid start

ou le redémarrer par :

sudo squid reload

Squid est normalement prêt à recevoir les connexions venant de la machine hôte.

Partie client

FIXME A rédiger, manquant.

La partie précédente consiste à installer un mandataire HTTP sur le serveur et de s'y connecter via SSH. Cependant, SSH lui-même peut jouer le rôle de mandataire, ce qui évite l'installation d'un logiciel supplémentaire.

Partie serveur

Il n'y a en principe rien à faire. Cette fonctionnalité est activée par défaut sous Ubuntu.

Partie client

Cette fois, le mandataire est de type SOCKS (à prendre en compte lors de la configuration du navigateur).

Sous Linux (dont Ubuntu)

Utiliser la commande ssh avec l'option -D :

# Ouverture d'un tunnel ssh (sur le port 1234 local) vers un serveur qui autorise la connexion
# le port (1234 dans cet exemple) est choisi arbitrairement, tant qu'il n'est pas utilisé pour autre chose
ssh -D 1234 monuser@monserver.net

Configurer ensuite le navigateur, gestionnaire de courrier, etc., pour utiliser un mandataire de type SOCKS 5, adresse : localhost, port: 1234 (selon ce que vous avez utilisé ci dessus).

La connexion fonctionnera tant que le tunnel restera ouvert (si vous fermez le terminal ayant servi à ouvrir le tunnel, vous fermerez le tunnel). Pour vous assurer que le tunnel remplit son office, affichez une page telle que http://www.monip.org et constatez que l'IP affichée n'est pas la même que lorsque vous naviguez sans mandataire.

Sous Windows, avec Putty

La configuration est la même qu'au point 6.2, sauf qu'il faut cocher la case "dynamic". La case "destination" n'est pas prise en compte et peut rester vide.

Vous pouvez ouvrir plusieurs tunnels utilisant des ports différents ou des utilisateurs différents. Ainsi, la navigation peut utiliser un tunnel vers un serveur, la messagerie un tunnel vers un autre serveur, etc.

Il est possible aussi d'utiliser un navigateur passant par le tunnel et un autre navigateur sortant directement.

Gestion des tunnels

Il existe une petite application graphique bien pratique pour gérer les tunnels SSH : au lieu de les recréer chaque fois on utilise GSTM (Graphical SSH Tunnel Manager).

Il est intéressant de pouvoir accéder à des ressources réseau locales (RDP, VNC, Administration périphérique réseau comme les box, etc.) sans pour autant rendre ces périphériques directement accessibles depuis Internet. SSH permet l'accès à ces ressources comme si l'on était en local (une sorte de réseau privé virtuel).

Prenons un exemple.

Accéder à une machine Windows via RDP

Donc nous avons un réseau avec une machine sous Windows (XP, Vista…) avec comme adresse locale 192.168.1.2 où TSE est activé mais accessible uniquement en local, un serveur ssh sous Ubuntu avec comme IP locale 192.168.1.3, et une Livebox (ou autre) dont seul le port ssh (22) est traduit (en franglais on dit translaté, Cf.Network_address_translation) pour un accès au serveur ssh depuis l'extérieur.

Nous voulons depuis l'extérieur accéder à la machine Windows via RDP.

Nous allons pour cela utiliser la tunnélisation. À partir de votre station depuis l'extérieur on va tunnéliser la connexion RDP de la station Windows au travers du serveur ssh :

$ ssh -L 3389:192.168.1.2:3389 username@IP_Publique_Box

Il suffit ensuite d'ouvrir le terminal serveur client sur votre machine et de se connecter à localhost.

Nous pouvons de la même façon accéder à la configuration de notre Box sans pour autant devoir la rendre accessible depuis Internet (attention seul root peut faire suivre le port 80) :

# sudo ssh -L 80:192.168.1.1:80 username@IP_Publique_Box

Puis en ouvrant son navigateur préféré et en entrant comme adresse http://localhost

FIXME Expliquer dans quel cadre ces opérations peuvent servir.

Pour accéder à un serveur par rebond sur un serveur ssh intermédiaire, on réalise normalement 2 connexions ssh ce qui peut devenir fastidieux lorsqu'on doit réaliser cette opération régulièrement.
SSH peut cependant faciliter cette opération en effectuant au choix une des deux manipulations :

  1. une modification de fichier pour provoquer une connexion ssh vers le serveur de destination directement
Pour toutes les commandes décrites ci-dessous, il est possible d'ajouter un nom d'utilisateur pour changer d'utilisateur.

Connexion ssh vers le serveur de destination via un serveur ssh intermédiaire

Il s'agit d' exécuter sur le poste client la commande ssh vers le serveur final

ssh <srv_intermédiaire> ssh <srv_final>
Si vous obtenez l'erreur suivante :
Pseudo-terminal will not be allocated because stdin is not a terminal.

rajouter l'option -t sur la connexion ssh du serveur intermédiaire, ce qui donne :

ssh -t <srv_intermédiaire> ssh <srv_final>

Connexion ssh vers le serveur de destination directement

Le fonctionnement n'est pas du tout le même que précédemment car ssh parlera ici directement avec le serveur final.
Indiquez directement sur le poste client la commande ProxyCommand en modifiant le fichier

~/.ssh/config
Host <srv_final>
ProxyCommand ssh <srv_intermédiaire> nc %h %p

L'utilisation de la commande nc (netcat), qui doit être présente sur le serveur intermédiaire, permet ainsi de se connecter sur le port ssh du serveur final et établit juste un lien entre le client et le serveur final.

Avec le "mode netcat intégré" introduit avec la version 5.4, l'option "nc" n'est plus nécessaire.
Il s'agira donc de modifier sur le serveur intermédiraire
~/.ssh/config
Host <srv_final>
ProxyCommand ssh -W %h:%p <srv_intermédiaire>

Délai lors de la connexion

Si vous avez un délai de plusieurs secondes avant que la connexion SSH ne se fasse, essayez d'ajouter ceci à votre fichier ~/.ssh/config

GSSAPIAuthentication no

Ceci désactive l'identification par GSSAPI qui engendre parfois des délais lorsqu'elle n'est pas utilisée. (Source : http://www.refreshinglyblue.com/2007/5/18/long-delay-before-ssh-authentication)

Liens

  • Tuto. « Chrooter » un utilisateur en ssh facilement.
  • Config. Configuration et sécurisation de ssh.

Contributeurs :

  • utilisateurs/sx1/ssh_avance.1330760156.txt.gz
  • Dernière modification: Le 03/03/2012, 08:35
  • par sx1