SSH basics

SSH is a tool for secure remote use of a machine. To use a computer remotely, you first install the SSH server software on this computer: aptitude install openssh-server should be enough on Debian-based distros. Then, using another machine, you can log in remotely with the command: ssh login@server where "login" is your login name and "server" is the domain name (or IP address) of the server. You then give your password and voilà: you are connected to the remote machine and can enter commands as if you were in front of a physical terminal for this machine.

SSH est un outil permettant d'utiliser une machine à distance de façon sécurisée. Pour ce faire, il faut d'abord installer le serveur SSH sur la machine que vous voulez contrôler : aptitude install openssh-server devrait suffire pour les distributions dérivées de Debian. Une fois que cela est fait, vous pouvez vous connecter à distance depuis une autre machine avec la commande ssh login@server où "login" est votre nom d'utilisateur et "serveur" le nom de domaine (ou l'adresse IP) du serveur. Vous donnez alors votre mot de passe, et vous êtes connecté à la machine distante : vous pouvez entrer des commandes comme si vous étiez en face d'un terminal physique pour cette machine.

Security

Unlike Telnet, SSH has a very strong focus on security. (OpenSSH is developed by the OpenBSD team.) First, your actual password is never sent in plaintext to the host. It works more or less like this: the server asks you to encrypt some random data using your password. Only the encrypted data (which is not sufficient to recover your password) is sent by your machine. The server check if it matches what it got using your actual password. If the two match, you are given access. Second, all further exchanges between you and the server are encrypted. This means that you can log in using SSH over any kind of connection, no matter how insecure. (Open Wifi networks are a good example.)

SSH, au contraire de Telnet, est très orienté sécurité. (OpenSSH est développé par l'équipe de OpenBSD.) Premièrement, votre mot de passe n'est jamais envoyé en clair à l'hôte. Cela fonctionne à peu près comme ça : le serveur vous demande de chiffrer des données aléatoires à l'aide de votre mot de passe. Seules les données chiffrées (qui ne suffisent pas pour reconstituer votre mot de passe) sont envoyées par votre machine. Le serveur vérifie si ça correspond à ce que lui obtient avec votre mot de passe réel. Si les deux correspondent, il vous donne accès à votre compte. Deuxièmement, toutes les communications ultérieures entre vous et le serveur sont chiffrées. Cela signifie que vous pouvez vous connecter en utilisant SSH via n'importe quel type de connexion, même si elles sont peu sécurisées (par exemple, des réseaux Wifi ouverts.)

SFTP

SSH can also be used as a way to transmit files between two machines (in a FTP-like way). You can directly use the sftp program on the command line, or use graphical FTP clients which support SFTP (such as Filezilla or gFTP); you can even pseudo-mount it using Gnome and KDE. The Gnome integration sometimes refuses to work, but when it works, if the bandwidth is large enough, you can use Totem to play some files from the remote server on your machine. Last but not least, you can use a program called rsync for automatic synchronisation of folders between the client and host. Rsync optimises the transfer rates using diff algos and on-the-fly compression.

SSH peut aussi être utilisé pour transmettre des fichiers entre deux machines (d'une manière semblable à FTP). Depius la ligne de commande, vous pouvez utiliser directement le programme sftp ; vous pouvez aussi utiliser des clients FTP graphiques avec support SFTP (comme Filezilla ou gFTP), ou même le pseudo-monter depuis Gnome ou KDE. L'intégration avec Gnome ne fonctionne pas toujours, mais quand cela fonctionne, si la bande passante est suffisante, vous pouvez utiliser Totem pour jouer des fichiers audio sur votre machine depuis le serveur. Une autre possibilité (et non des moindres) est d'utiliser un programme nommé rsync pour synchroniser automatiquement des répertoires entre le serveur et le client. Rsync optimise les taux de transfert à l'aide d'algorithmes fondés sur diff, et en compressant les transferts à la volée.

Key-based authentication

Entering your password each time you login to a remote host can be a pain. Worse still, it makes it very difficult to script connections to an SSH server for backups or anything. There is no -password switch for SSH; there are obscure ways to work around this, but it is discouraged. It is much better to generate a key used to authentify your machine. You first run the program ssh-keygen to create a key (do not enter any passphrase), and then you log in to the remote host using ssh-copy-id (you might have to pass the path to the *.pub key file in your .ssh folder using the -i switch). Your key is then added to the remote host's allowed keys list, so that you can log in to it (only for your session, of course :)) using the key file (automatically sent by SSH) instead of a password. (If it doesn't work, it might be because SSH thinks the permissions of your home directory, .ssh folder and stuff aren't restrictive enough; search the web for details about how to set up permissions.) Of course, since the key file is sufficient to connect to the server, make sure to keep it private.

Il peut être pénible d'entrer votre mot de passe à chaque fois que vous vous connectez à une machine distante. Pire encore, cela rend très difficile la connexion à un serveur SSH avec des scripts, pour faire des backups ou quoi que ce soit d'autre. Il n'y a pas d'option -password pour SSH; il y a des moyens obscurs de contourner cela, mais ce n'est pas recommandé. Il est de loin préférable de générer une clé permettant d'authentifier votre machine. Vous lancez d'abord le programme ssh-keygen pour créer une clé (ne paramétrez pas de phrase de passe), et puis vous vous connectez à l'hôte distant en utilisant ssh-copy-id (il faudra peut-être passer en paramètre le chemin vers le fichier de clé *.pub dans votre répertoire .ssh avec l'option -i). Votre clé est alors ajoutée à la liste des clés autorisées par l'hôte distant, de sorte que vous pouvez vous y connecter (seulement avec votre session, bien sûr :)) en utilisant le fichier de clé (envoyé automatiquement par SSH) au lieu d'un mot de passe. (Si ça ne fonctionne pas, c'est peut-être parce que SSH a décidé que les permissions de votre répertoire utilisateur, dossier .ssh et autres ne sont pas assez restrictives; cherchez sur Internet pour savoir quelles sont les permissions qu'il faut mettre.) Bien sûr, vu que le fichier de clé est suffisant pour se connecter au serveur, faites en sorte de la garder en sécurité.

Using X

The command line is nice, but perhaps would you prefer to use X applications. SSH also allows you to do that. Just pass the -X switch to SSH on the command line, and run any graphical application you like on the terminal (e.g. "firefox"). It should then appear on your screen, running from the remote host (and once again going through a secure channel). A few caveats, however. First, unless you are on a very low-latency high-speed network (such as a LAN), everything will probably feel quite sluggish. This can be improved a bit with the -C switch (which tells SSH to compress all traffic on-the-fly). Second, this can not be used (as far as I know) to monitor the status of existing applications, only to run new ones: if you want to see what the remote host is displaying (with the desktop and all), you'll be better off with something like VNC. Third, X11 forwarding does not forward the sound. There might be some workarounnds but I don't know any simple one. The sound will be played on the remote machine instead, with potentially unexpected effects on anybody who happens to be nearby... So keep all of this in mind, and stick to the command line whenever possible ;).

La ligne de commande, c'est bien joli, mais peut-être préféreriez-vous utiliser des applications X. SSH vous permet de le faire. Passez juste le paramètre -X à SSH sur la ligne de commande, et lancez l'application graphique de votre choix depuis le terminal (par exemple "firefox"). Elle devrait alors apparaître sur votre écran, en étant exécutée sur la machine distante (et à nouveau au travers d'un canal sécurisé). Il y a quelques limitations, cependant. Premièrement, à moins d'être sur un réseau à très faible latence et à très grande vitesse (un réseau local, par exemple), tout sera probablement très lent. On peut un peu l'améliorer avec l'option -C (qui demande à SSH de compresser tout le trafic à la volée). Deuxièmement, on ne peut pas se servir de l'option -X (enfin, pas que je sache) pour suivre l'exécution d'applications déjà lancées ; on peut juste en lancer de nouvelles. Si vous voulez voir précisément ce que l'hôte distant affiche (avec le bureau et tout), vous feriez mieux d'utiliser quelque chose comme VNC. Troisièmement, le forwarding X11 ne permet pas d'avoir du son. Il y a peut-être une manière de l'avoir, mais je n'en connais aucune qui soit simple. Le son sera en fait joué sur la machine distante, ce qui peut avoir des effets imprévus sur les personnes qui sont à proximité... Donc, gardez tout cela en tête, et tenez-vous-en à la ligne de commande dans la mesure du possible. ;)

Tunnels

Tunnels are a very useful tool which I just discovered. Say you're on holiday with no connection except an open Wifi network, and you want to check your e-mail. If you can use a protocol which is already secure (such as HTTPS for a webmail) then you're fine. However, if the protocol isn't secure, it is not a very good idea to broadcast your passwords in plaintext for anybody to sniff and reuse. If you've understood everything I said up to now, you might be tempted to use SSH to log in to a machine with a trusted web connection and then check your mail, so that your passwords first go through SSH (encrypted) over the Wifi connection and then in plaintext from the trusted machine to the server on the secure connection. A better option is to create a tunnel (in fact, creating a SOCKS server is an even better option, I'll present it in the next paragraph). Tunnels are created by passing to SSH the -L switch with something like 123:mailserver.org:456. If you run this, pointing a program to port 123 on your machine will cause SSH to forward its input to the host you connected to, which will in turn redirect the traffic to port 456 of mailserver.org. Another use case is to reach a machine within a LAN from the outside world: use ssh machine_a 123:machine_b:123 with "machine_a" one of the machines in the LAN which can be reached from the WAN, and "machine_b" the target LAN machine identified by its LAN address. When you request something on port 123 of your machine, everything will happen as if you were machine_a trying to access machine_b on port 123.

Les tunnels sont un outil très pratique que j'ai découvert récemment. Par exemple, disons que vous êtes en vacances avec pour seule connexion un réseau Wifi ouvert, et que vous voulez relever votre courriel. Si vous utilisez un protocole qui est déjà sécurisé (par exemple, HTTPS pour accéder à un webmail), vous êtes tranquille. Par contre, si le protocole n'est pas sécurisé, vous n'avez probablement pas envie d'émettre vos mots de passe en clair pour que n'importe qui puisse les intercepter et s'en servir. Si vous avez compris ce que j'ai écrit jusqu'à maintenant, vous avez peut-être envie d'utiliser SSH pour vous connecter à une machine avec une connexion sécurisée à Internet et de relever votre courriel à partir de là, de sorte que vos mots de passe transitent d'abord sous forme chiffrée avec SSH via la connexion Wifi, et puis en clair depuis la machine de confiance jusqu'au serveur via la connexion sécurisée. Il y a une meilleure manière de faire, c'est d'utiliser des tunnels (en fait, créer un serveur SOCKS est encore plus pratique, j'en parlerai dans le prochain paragraphe). Pour créer un tunnel, il faut passer à SSH l'option -L avec un paramètre comme 123:mailserver.org:456. Cela signifie que si un programme se connecte au port 123 sur votre machine, SSH transmettra la connexion à l'hôte auquel vous vous êtes connecté, qui redirigera à son tour le trafic au port 456 de mailserver.org. Une autre utilisation possible est d'atteindre depuis le monde extérieur une machine à l'intérieur d'un réseau local : utilisez ssh machine_a 123:machine_b:123 où "machine_a" est une des machines du réseau local accessible depuis l'extérieur, et "machine_b" la machine cible du identifiée par son adresse dans le réseau local. Quand vous accéderez au port 123 de votre machine, tout se passera comme si vous étiez la machine_a en train d'essayer d'accéder à machine_b sur le port 123.

SOCKS

A better solution for the Wifi use case above is to create a SOCKS server. Creating a tunnel is fine, but suppose that you want to use the secure tunnel on several ports, to visit several websites... You won't use a tunnel for every connection you want to secure. Instead, you'll use the -D switch and pass a port number (say 9999). This will create a SOCKS server on your machine, port 9999, which will redirect its input to the trusted machine you connected to using SSH and then use it. What you will do is instruct your OS and/or whatever application you're using (e.g. Ubuntu has a system-wide setting but Firefox and Thunderbird have their own options and will override it) to use the SOCKS proxy at 127.0.0.1 port 9999. When these applications want to use Internet, they will send their queries through the SOCKS proxy (no matter whom they connect to, no matter which port), and SSH will redirect them to the trusted machine who will perform the query. This enables you to do anything you wish on an untrusted connection in a quite straightforward way, and can also be used for other things (e.g. circumvent IP blocks on the machine you're using by appearing to the outside world as the trusted machine...). The only downside, as with everything to do with tunneling, is higher ping (instead of going directly to the remote host, you have to pass through the trusted machine), and smaller rates (the slowest member of the chain will limit the speed; for instance, if you download a file from the web through a tunnel involving a trusted machine on a home connection, chances are that the web server has a decent upload speed but that your trusted machine hasn't and will slow the whole thing down).

Une meilleure solution, si vous n'avez qu'une connexion Wifi non sécurisée à portée, est de créer un serveur SOCKS. Créer un tunnel est déjà bien, mais si vous voulez utiliser différents ports et différents sites web, vous n'aller pas créer un tunnel pour chaque connexion. Vous allez plutôt utiliser le paramètre -D et passer en paramètre un port, par exemple 9999. Ceci va créer un serveur SOCKS sur votre machine (sur le port 9999) qui va rediriger tout ce qu'il reçoit à la machine de confiance (à laquelle vous vous êtes connecté avec SSH) qui va ensuite l'exécuter. Il faudra juste dire à votre système d'exploitation et/ou aux applications que vous utilisez (par exemple, Ubuntu a un paramètre pour cela mais Firefox et Thunderbird ne suivent pas le réglage système et ont leur propres options) d'utiliser le proxy SOCKS à l'adresse 127.0.0.1 port 9999. Quand ces applications voudront utiliser Internet, elles enverront leurs requêtes au serveur SOCKS (peu importe à qui elles se connectent, peu importe le port), et SSH les redirigera à la machine de confiance qui effectuera la requête. Cela vous permet de faire ce que vous voulez sur la connexion non sécurisée sans trop se prendre la tête, et peut être utilisé pour toutes sortes d'autres choses (par exemple, contourner des blocages d'IP sur la machine que vous utilisez, en apparaissant comme la machine de confiance pour le monde extérieur...). Le seul inconvénient, qui s'applique à toute cette histoire de tunneling, est que vous allez avoir un ping plus élevé (au lieu de vous connecter directement à la machine distante, il faut passer par la machine de confiance) et des débits plus bas (le maillon le plus lent de la chaîne sera limitant ; par exemple, si vous téléchargez un fichier depuis le web via un tunnel passant par une machine de confiance avec un fournisseur d'accès standard, il est probable que le serveur web a une vitesse d'upload bien supérieure à votre machine de confiance, qui va tout ralentir).

Over HTTP

It seems that you can (quite) easily embed SSH traffic in HTTP to work around stringent firewall policies. I haven't had the occasion to try it yet (but I'll probably do it soon). See this explanation.

Il semblerait qu'il soit (assez) facile d'inclure du trafic SSH dans du HTTP pour contourner des pare-feux restrictifs. Je n'ai pas encore eu l'occasion d'essayer, mais je le ferai sans doute bientôt. Voir ces explications.