§ Posté le 24/03/2013 à 17h 07m 20
Ça fait plusieurs fois que je mentionne SSh dans mes articles précédents, comme s'il était acquis que tout le monde connaissait. En pratique, cependant, il semble que ce ne soit pas le cas, donc quelques petites explications s'imposent.
Présentation et utilisation de base
Donc, allons-y pour la présentation générale : SSh signifie « Secure Shell », parce que le principe est de permettre d'ouvrir, à distance, une manière sécurisée d'interagir avec la machine (« Shell », en anglais, est utilisé pour désigner les interfaces, d'une manière générale(1)).
La plupart du temps, cette manière d'interagir est « simplement » une ligne de commande ; mais il existe d'autres possibilités, que je détaillerai un peu plus bas.
L'installation est simplissime, d'où le fait que j'ai hésité à poster cet article ailleurs que dans mes notes d'installation : sous Debian et Ubuntu, en tout cas, le client ssh est, me semble-t-il, installé par défaut, et pour le serveur, vous n'avez qu'à installer le paquet openssh-server.
La configuration par défaut est, normalement, directement utilisable : dès que le serveur SSh est installé sur la machine, vous pouvez vous connecter à distance à chacun de vos comptes utilisateurs. Les différents comptes système (dont, sous Ubuntu, le compte root) ne sont pas accessibles, car ils n'ont pas de mot de passe (sous Debian, le compte root a un mot de passe, mais SSh est préconfiguré pour ne pas accepter qu'on s'y connecte).
Si vous avez plusieurs comptes utilisateurs sur la machine et que vous voulez faire en sorte que seuls certains d'entre eux puisse se connecter, lisez les quelques mots que je dis à ce sujet dans le premier article de cette section.
Pour l'utilisation de base, c'est tout simple : vous ouvrez un terminal, et vous lancez la commande suivante :
ssh login@adresse.de.la.machineÇa devrait normalement ouvrir une ligne de commande sur l'autre machine (si le login est le même que celui que vous êtes entrain d'utiliser, il est inutile de le préciser, vous pouvez mettre l'adresse de la machine uniquement).
Bien sûr, vous pouvez ajouter quelques options, comme je vais vous en proposer quelques unes un peu plus bas.
Accès par clefs
L'accès de base, je viens d'en parler, utilise les mots de passe des comptes système. C'est bien, mais ce n'est pas forcément le meilleur moyen de fonctionner. Il existe aussi la possibilité, en plus ou à la place du login classique, d'utiliser, pour se loguer, un système de clef publique/clef privée.
Je vous ai déjà vaguement parlé de ce principe de double clef en vous présentant TLS, et j'y reviendrai peut-être un peu plus tard, mais pour faire simple, il faut que vous gardiez l'une de vos deux clefs (votre clef privée) secrète, et que vous transmettiez l'autre (votre clef publique) au serveur, ces deux opérations lui permettant de s'assurer que c'est bien vous.
La commande pour générer lesdites clefs, à lancer depuis votre machine cliente, est
ssh-keygen -t rsaCette commande va vous demander d'entrer un mot de passe pour sécuriser votre clef : chaque fois que vous voudrez vous connecter à SSh, on vous demandera alors de taper ce mot de passe-ci, et non plus celui de votre compte, ce qui permet une double-sécurité (la clef privée + votre mot de passe, au lieu de juste un mot de passe tout seul).
Notez que vous pouvez préférer ne pas entrer de mot de passe pour votre clef, ce qui fait qu'on vous connectera directement. C'est potentiellement plus pratique, mais beaucoup moins sécurisé.
Le répertoire .ssh situé dans votre répertoire personnel est destiné à contenir, entre autres, les informations concernant ces clefs. Sur votre machine cliente, il doit contenir, après exécution de la commande précédente, un fichier id_rsa et un fichier id_rsa.pub (les noms seront légèrement différents si vous utilisez un type autre que rsa à la génération, je ne sais plus lesquels sont dispos).
Le premier contient la clef privée : n'y touchez pas. Le second contient la clef publique, qu'il faudra transférer sur le serveur. Cette clef publique tient normalement en une seule ligne (une longue ligne, qui sera donc probablement affichée en plusieurs morceaux par votre éditeur, mais sans caractère de retour à la ligne dedans, quoi).
Du côté serveur, le même répertoire doit contenir (ce n'est probablement pas encore le cas, alors créez-le) un fichier authorized_keys, qui contient, comme son nom l'indique, la liste des clefs publiques (une par ligne) que SSh doit accepter pour ce compte-ci.
Pour plus de renseignements à ce sujet, vous pouvez aller voir la documentation Ubuntu-fr, qui est, comme d'habitude, excellente.
Outils graphiques par SSh
Si vous avez des applications graphiques sur votre serveur, vous pouvez les lancer par SSh. Et ce, même si aucun environnement graphique n'est installé sur le serveur en question (ce qui est généralement le cas ; un serveur avec un environnement graphique, il n'y a que Ras' pour faire ça).
Il vous suffit de passer l'option « -X » au lancement de SSh, et les applications présentes sur le serveur pourront utiliser l'environnement graphique de votre machine distance pour se lancer.
C'est pour cela que je vous disait qu'il est possible de gérer un serveur par SSh sans devoir utiliser le terminal (du moins, passée une première étape de configuration).
Supposons par exemple que vous ayez un dock ou un tableau de bord installé sur le serveur, et configuré pour lancer quelques applis utiles. Je vais prendre fbpanel comme exemple, mais remplacez-le par un autre si vous préférez.
Dans ce cas, tout ce que vous avez à faire, c'est vous rajouter dans le tableau de bord de votre machine cliente un bouton qui lance la commande
ssh -X utilisateur@machine fbpanelEt cliquer sur ce bouton vous ouvrira votre tableau de bord du serveur (à vous de vous organiser pour qu'il soit bien intégré à votre environnement local), ce qui vous permettra d'accéder aux outils du serveur sans devoir passer par le terminal.
Vous pouvez aussi utiliser le système de notifications(2), par exemple si vous lancez des scripts qui vont avoir besoin d'attirer votre attention à certains moments. Si vous utilisez, comme moi, xfce4-notifyd pour cela, vous devrez installer ce paquet sur le serveur aussi, mais ça vous permettra d'avoir une configuration différente pour les notifications venues du serveur et pour celles venues de la machine cliente (chez moi, celles de la machine cliente s'affichent en bas à droite, et celles du serveur en bas à gauche, par exemple ; il est aussi possible d'utiliser deux thèmes différents).
Quelques limites à ce truc, tout de même : d'abord, si vous avez plusieurs comptes utilisateurs sur le serveur, vous ne pourrez pas passer de l'un à l'autre en conservant le mode graphique : la connexion est permise à l'utilisateur auquel vous vous connectez, mais dès que vous passez à un autre, elle est bloquée (vous la retrouverez en retrouvant le compte initial). Si jamais quelqu'un savait comment outrepasser ça, qu'il le signale, ça m'intéresse(3).
Ensuite, je n'ai pas essayé depuis un moment, mais il me semble bien qu'il ne faut pas espérer lancer de la musique comme ça : même si la fenêtre du lecteur est gérée par votre environnement graphique local, ce qui est lancé sur le serveur fonctionne sur le serveur, et c'est donc la sortie son du serveur, s'il y en a une, qui s'activera (ça peut servir à faire des blagues aux gens qui sont à côté du serveur, notez). Pour écouter localement des fichiers sonores présents sur le serveur, vous devrez utiliser l'accès aux fichiers pour les ouvrir avec un lecteur local.
Accès aux fichiers
SSh vous fournit un accès à la machine. Cet accès n'est pas forcément un moyen de lancer des commandes : il peut aussi s'agir d'un accès aux fichiers. On parle, dans ce cas-là, de SFTP.
Pour transférer un fichier d'un ordinateur à l'autre, la commande scp est fournie avec le client SSh de base. Cela s'utilise, en ligne de commande, à peu près comme un cp ordinaire, à ceci près qu'il faut préciser lequel des deux fichiers est sur la machine distante, et par quel compte on va y accéder.
Ainsi, la commande
scp utilisateur@machine:fichier1 .va copier, dans le répertoire depuis lequel on lance cette commande (le « . » final veut dire « vers le répertoire courant »), le fichier situé dans le répertoire personnel de l'utilisateur. Donc, un transfert de la machine distante vers la machine locale.
À l'inverse, la commande
scp fichier2 utilisateur@machine:machin/fichier2va copier le fichier (situé dans le répertoire courant) vers le serveur, et le placer dans le répertoire « machin », lui-même situé dans le répertoire personnel. Encore une fois, si le login est le même entre les deux comptes, ce n'est pas la peine de le préciser.
Différence notable avec le cp local : si vous voulez copier tout un répertoire, avec un cp local, vous pouvez préciser soit l'option « -r », soit l'option « -R » (personnellement, j'utilise par habitude plus souvent le R majuscule). Avec scp, seul le r minuscule est reconnu.
Seulement, ça, ça ne fait que le transfert, ça ne vous permet pas d'accéder directement aux fichiers qui sont sur le serveur, sans les recopier en local. Pour faire ce genre de choses, il faut utiliser un autre outil, sshfs, contenu dans le paquet du même nom.
Ce système est l'un des systèmes de fichiers fournis par FUSE, qui est un outil permettant de monter des systèmes de fichiers virtuels. En langage un peu plus humainement compréhensible : FUSE vous permet de connecter des espaces de stockage virtuels (image de disque dur ou accès par le réseau au disque dur d'une autre machine, par exemple) à peu près comme si vous branchiez une clef USB sur votre ordinateur. Et SShFS est donc le truc qui permet à FUSE de fonctionner par SSh.
L'utilisation de base est assez simple :
sshfs utilisateur@machine:cible point_de_montageDans lequel « cible » doit être un répertoire existant sur le serveur (comme pour scp, si vous indiquez « . », ça prend votre répertoire personnel), et « point_de_montage » doit être un répertoire existant (et vide) sur la machine locale (même remarque que d'habitude pour le login).
Une fois cette commande lancée (à condition que FUSE ait été correctement configuré, mais voyez le lien ci-dessus), vous pouvez accéder au contenu du répertoire distant de la me façon que s'il s'agissait d'un répertoire local.
Quand vous aurez terminé de travailler, vous pouvez lancer
fusermount -u point_de_montagepour fermer la connexion.
(Notez que, sous GNOME, vous pouvez aussi demander à Nautilus de vous faire ça sans passer par fuse et sshfs (et KDE doit fournir à peu près le même genre de chose, mais je n'ai pas essayé). Seulement, dans ce cas, ce sera interne à votre environnement, donc pas forcément compatible avec tout ; je vous conseille plutôt d'utiliser la méthode décrite ci-dessus)
Faire proxy facilement
D'abord, qu'est-ce qu'un proxy, au juste ? Ce terme un peu bizarre désigne quelque chose (en l'occurrence, un ordinateur, mais le mot peut être utilisé dans d'autres contextes) qui va servir d'intermédiaire entre vous et ce que vous voulez faire.
Par exemple, quand vous envoyez votre collègue de bureau vous chercher un café au lieu d'y aller vous-même, on peut dire que votre collègue de bureau sert de proxy entre vous et la machine à café (pensez à le remercier, quand même).
Pour les connexions à Internet, ça peut vous servir à contourner un réseau un peu trop fermé. Par exemple, si vous voulez accéder à un site Web, mais que le réseau sur lequel vous vous trouvez vous refuse la connexion, vous pouvez utiliser votre serveur SSh comme proxy : c'est lui (qui n'est, on l'espère, pas bloqué) qui va chercher la page que vous voulez voir, puis il la retransmet à votre navigateur, et le réseau bloqueur n'y voit que du feu.
D'où le proverbe geek que je citais il y a quelques articles : « quand SSh passe, tout passe ».
Alors, comment fait-on ça, me direz-vous ? Le plus simplement du monde. Il suffit d'ajouter, quand vous vous connectez à SSh, une simple petite option, pour préciser le numéro de port(4) que vous allez utiliser pour ça, grâce à l'option -D.
Veillez à choisir un numéro de port qui n'est pas encore occupé. Par exemple, je n'ai jamais eu de soucis avec le port 7744, donc je tape :
ssh -D 7744 utilisateur@machineEt, tant que le shell qui s'ouvre de cette façon n'est pas refermé, j'ai un proxy actif sur le port 7744.
Il suffit ensuite de configurer les logiciels pour qu'ils utilisent ce proxy. Par exemple, sous Firefox, vous allez dans préférences → avancé → réseau → paramètres de connexion, et vous choisissez une connexion manuelle. Il faut alors préciser « localhost » comme hôte SOCKS, avec le numéro de port correspondant, et le tour est joué.
Bien sûr, vous pouvez cumuler les options, et vous servir de la même connexion SSh pour ouvrir une appli graphique (avec -X) et pour servir de proxy (avec -D num)(5).
Puisqu'on parle de proxy, autre chose à signaler : votre serveur SSh doit être accessible depuis l'extérieur pour que vous puissiez vous y connecter hors de chez vous, mais il est tout de même présent sur votre réseau local. Vous pouvez donc vous en servir comme relai pour accéder aux autres machines de votre réseau local, celles qui ne sont pas accessibles par l'extérieur. Vous pouvez, notamment, installer SSh sur plusieurs de vos machines, et sauter comme ça de l'une à l'autre.
Si vous voulez accéder directement à une machine en particulier, vous pouvez même lancer SSh en lui demandant directement de lancer un autre SSh derrière. Dans ce cas, vous aurez besoin de l'option « -t », qui permet de forcer SSh à utiliser le tty actif (faute de quoi, il râlera pour la saisie de mot de passe).
Sur les autres systèmes
Tous les systèmes Unix-like proposent SSh de base, il me semble. En fait, le « open » dans le nom des paquets vient de celui d'OpenBSD, parce que l'implémentation actuellement utilisée un peu partout vient de chez eux.
Mac OS X, le système d'exploitation d'Apple, est un Unix-like, donc il n'y a pas trop de soucis à ce niveau, en tout cas au niveau client (ç'n'est pas trop fait pour faire serveur, de toute façon). Il y aura peut-être éventuellement quelques soucis avec les outils graphiques (pas essayé, à l'époque où j'avais Mac OS X, je n'avais pas encore mon serveur), mais en ligne de commande, ça marchera.
Pour Windows, qui n'est pas un Unix-like, c'est un poil plus compliqué, mais il existe des outils.
Pour lancer un terminal en SSh, vous pouvez utiliser l'outil PuTTY (logiciel portable, qui n'a pas besoin d'être installé). En farfouillant dans les options, vous pouvez utiliser l'option pour faire proxy socks, et quelques autres trucs (pensez à régler l'encodage des caractères, au passage). Par contre, n'espérez pas faire du graphique avec (ça, ce serait peut-être possible en utilisant des outils plus avancés, genre cygwin, mais je n'ai jamais essayé).
Pour le transfert de fichiers, il existe un outil appelé WinSCP, mais ça fait trop longtemps que je n'ai pas eu à l'utiliser pour que je puisse vous donner beaucoup de détails à son sujet.
Récupérer la main
Pour finir, une petite astuce que Yionel m'a fait découvrir il y a peu (il en a également fait part sur son blog à lui). Il arrive, de temps à autres, qu'une perte passagère de connexion bloque le shell distant, vous empêchant de faire quoi que ce soit dans votre terminal. En fait, SSh vous propose un moyen de récupérer de ça.
Si vous appuyez sur la touche entrée, puis que vous envoyez un caractère « ~ » (ça se fait avec altgr+é/2 sur un clavier azerty standard(6)), puis que vous envoyez un caractère « . », SSh se terminera et rendra la main au shell que vous utilisiez avant. Quelques autres astuces sont possibles : envoyer un « ? » plutôt que le point final vous en affichera la liste.
