Première approche

Si vous n'avez jamais utilisé SSH (bon, je sais, vous lisez mes articles, c'est donc peu probable ;D), voici comment se présente une commande de connexion à un serveur distant :

ssh utilisateur@www.mon-serveur-fort-fort-lointain.com

Notez que www.mon-serveur-fort-fort-lointain.com peut aussi bien être un nom de domaine qu'une adresse IP. Notez que lors d'une première connexion à un serveur SSH, vous vous verrez afficher le message suivant :

The authenticity of host 'www.mon-serveur-fort-fort-lointain.com (124.36.213.184)' can't be established.
RSA key fingerprint is 02:11:f2:db:ad:42:86:de:f3:10:9a:fa:41:2d:09:77.
Are you sure you want to continue connecting (yes/no)? 

Cela signifie que le serveur vous est inconnu. En effet, chaque serveur SSH dispose d'une signature distincte. Le client SSH tient à jour une base de données des signatures des différents serveurs qu'il a rencontré. Nous aborderons plus loins la finalité de cette base de serveurs, et les outils qui l'accompagne. Pour le moment, répondez "yes" à cette question.

Le client SSH demande alors le mot de passe de votre utilisateur sur le serveur distant. Saisissez le, et hop, miracle de la technologie... pas si moderne que ça..., vous êtes connecté sur votre serveur.

SCP et SFTP, ou comment transférer des fichiers via une connexion sécurisée

SCP signife Secure CoPy. SCP peut être considé comme une version "réseau et chiffrée" de la commande locale cp. Un exemple d'utilisation de scp est :

scp -r ./Mon-Dossier-Local utilisateur@www.mon-serveur-fort-fort-lointain.com:~/Mon-dossier-distant

Elle copie un dossier local et son contenu vers le serveur distant, et ce n'est qu'un exemple commun d'utilisation. Je vous invite à lire la page man de cette commande :

man scp

SFTP signifie SSH file transfer protocol, et n'a absolument aucun rapport avec FTP... sauf son but qui est de transférer des fichiers :). Pour plus d'informations sur cet outil, je vous invite à lire la page man de la commande sftp :

man sftp

Identification sans mot de passe, ou un mot de passe pour les gouverner tous

Dans certains cas, il est nécessaire de disposer d'une identification sans mot de passe vers un serveur. C'est notamment le cas pour la copie de sauvegardes sur un serveur distants, que ce soit à l'aide de SFTP ou de RSYNC. Pour ce faire, nous allons créer une paire de clefs de chiffrement RSA. Nous placerons sur le serveur de destination notre clef publique, et nous conserverons précieusement la clef privé à l'abri des regards indiscrets.

Note : Une clef publique peut être placée sur un nombre illimité de serveurs distants. On peut ainsi placer un seul mot de passe (vraiment sécurisé) sur la clef privée pour accéder à tous les serveurs ainsi préparés. C'est très pratique, mais personnellement, je ne suis pas fan de ce genre de méthode.... sauf pour mes machines virtuelles Xen (sinon, trop de mots de passe à retenir).

Par défaut, les clefs sont créées pour l'utilisateur de l'ordinateur que vous êtes en train d'utiliser. Vous pouvez aussi la placer sur une clef USB pour l'utiliser sur d'autres ordinateurs, mais si vous perdez la clef, vous perdez votre accès au serveur.

Création de la paire de chiffrement RSA

Voici quelques commandes de création de paires de chiffrement RSA.

• La commande par défaut, pour créer une clef avec mot de passe pour l'utilisateur courant :
  

  /usr/bin/ssh-keygen -t rsa -f ${HOME}/.ssh/id_rsa
  

• La commande pour créer une clef pour l'utilisateur courant, mais ne nécessitant pas de mot de passe (utile pour automatiser les copies distantes) :
  

  /usr/bin/ssh-keygen -t rsa -N "" -f ${HOME}/.ssh/id_rsa

Remarque : Si vous souhaitez créer votre clef à un autre emplacement que celui recommandé, il suffit de remplacer "${HOME}/.ssh/id_rsa" par l'emplacement et le nom de fichier de votre choix (par exemple: /chemin/vers/ma-clef/nom-de-la-clef).

Une fois la clef créée, vous disposez d'une paire de fichiers :

• ~/.ssh/id_rsa : La clef privée : elle ne doit en aucun cas être diffusée. C'est ce fichier qui constitue la clef de voute de l'identification unifiée par SSH. Si cette clef est compromise, vous pouvez considérer que tous vos serveurs le sont.
• ~/.ssh/id_rsa.pub : La clef publique : Cette clef est à placer sur les serveurs sur lesquels vous souhaitez disposer d'une authentification unifiée.
  

Mise en place de la clef publique sur un serveur distant

Une fois la paire de chiffrement RSA créée, il est nécessaire de la placer dans le fichier authorized_keys de votre utilisateur sur le serveur distant. Pour ce faire, deux solutions s'offrent à vous.

Prérequis : configuration du serveur distant

Afin que l'authentification par clef soit possible, il est nécessaire que le serveur distant soit configuré pour l'accepter. Pour ce faire, utilisez la ligne de commande suivante pour mettre à Yes la valeur PubkeyAuthentication :

/bin/sed -i -e 's/^[#\t ]*PubkeyAuthentication[\t ]*.*$/PubkeyAuthentication yes/' \
         /etc/ssh/sshd_config

N'oubliez pas de redémarrer le serveur SSH pour prendre en compte la configuration :

/etc/init.d/ssh restart

Solution automatisée

Pour placer votre clef publique sur le serveur distant de manière simple est rapide, la commande suivante est pour vous :

/usr/bin/ssh-copy-id -i ${HOME}/.ssh/id_rsa.pub utilisateur@www.mon-serveur-fort-fort-lointain.com

Solution manuelle "automatique"

Vous pouvez reproduire un comportement similaire à celui de ssh-copy-id à l'aide de cette ligne de commande :

cat ${HOME}/.ssh/id_rsa.pub | /usr/bin/ssh utilisateur@www.mon-serveur-fort-fort-lointain.com "/usr/bin/tee -a ~/.ssh/authorized_keys"

Solution manuelle

Si la solution automatisée ne convient pas à votre environnement, vous pouvez ajouter cette clef manuellement. Pour ce faire, commencez par copier la clef publique sur le serveur distant :

scp ${HOME}/.ssh/id_rsa.pub utilisateur@www.mon-serveur-fort-fort-lointain.com:~/

Puis identifiez vous sur le serveur distant :

ssh utilisateur@www.mon-serveur-fort-fort-lointain.com

Et enfin, ajoutez la clef publique au fichier authorized_keys :

/bin/cat ~/id_rsa.pub | /usr/bin/tee -a ~/.ssh/authorized_keys

Gérer la base des serveurs connus

La base des serveurs connus permet de limiter les possibilités d'une attaque par l'homme du milieu (c.a.d. que qu'un prend de manière transparente la place de votre serveur, et peut ainsi récupérer votre mot de passe).

Ajouter un serveur à la base

Pour ajouter un serveur existant à votre base des serveurs connus, vous pouvez utiliser la commande suivante :

/usr/bin/ssh-keyscan -H -t rsa www.mon-serveur-fort-fort-lointain.com | /usr/bin/tee -a ~/.ssh/known_hosts

Supprimer un serveur de la base

Pour supprimer une adresse IP ou un serveur de votre base des serveurs connus (c'est très utile si vous réinstallez vos serveurs régulièrement (ou que comme moi, vous zappez fréquemment vos machines virtuelles Xen)), vous pouvez utiliser la commande suivante:

/usr/bin/ssh-keygen -R www.mon-serveur-fort-fort-lointain.com
/usr/bin/ssh-keygen -R 124.36.213.184

Remarque : Il est nécessaire de supprimer séparément la clef associée à l'adresse IP et celle associée au nom de domaine.

Transférer des partitions d'un serveur à un autre

Voici un exemple d'utilisation avancée de SSH : Il est possible de dupliquer une partition d'un serveur à un autre via SSH. Cela se fait très simplement à l'aide de cette commande :

/bin/dd if=/dev/sda3 | /usr/bin/ssh -i utilisateur@www.mon-serveur-fort-fort-lointain.com "/bin/dd of=/var/backup/server-hdd.bin"

La cible comme la source peut aussi bien être un fichier, une partition physique ou une partition LVM. Notez qu'ici SSH joue le role de pipe (|). La commande ci-dessus revient à exécuter cette commande avec un pipe qui passe par le réseau :

/bin/dd if=/dev/sda3 | /bin/dd of=/var/backup/server-hdd.bin

Mettre en place un tunnel SSH

Le tunnel SSH est un outil très efficace permettant de limiter les failles de sécurité. En effet, à l'aide d'un tunnel SSH, il est possible d'accéder au ports d'un serveur normalement bloqués par un pare-feu. Ainsi, il suffit de laisser ouvert le port 22 (SSH) d'un serveur pour pouvoir par la suite accéder à tous les ports ouverts sur ce serveur, même si ces derniers sont bloqués par le pare-feu.

Pour mettre en place un serveur SSH, vous pouvez utiliser la ligne de commande suivante :

/usr/bin/ssh -N -f utilisateur@www.mon-serveur-fort-fort-lointain.com \
       -L4373:www.mon-serveur-fort-fort-lointain.com:3128 sleep 60

Dans la commance ci-dessus, nous lions le port localhost:4373 au port www.mon-serveur-fort-fort-lointain.com:3128. Ainsi, en vous connectant à localhost:4373, vous accédez à www.mon-serveur-fort-fort-lointain.com:3128. L'option "sleep" spécifie le délai de démarrage maximal du service tunnelé. Ici, si au bout de 60s le port de destination n'est pas ouvert, la création du tunnel est abandonnée.

Remarque : Il est aussi possible de créer un tunnel SSH vers un serveur du réseau local du serveur SSH. Par exemple, pour accéder au serveur IMAP situé sur le LAN de www.mon-serveur-fort-fort-lointain.com.

/usr/bin/ssh -N -f utilisateur@www.mon-serveur-fort-fort-lointain.com \
       -L143:imap.fort-fort-lointain.lan:143 sleep 60

Bien sûr, par LAN, cela peut vouloir dire votre réseau de machines virtuelles Xen.

Source : Merci à Joël Marchand pour son article Comment constituer des tunnels ssh, pour utiliser POP, IMAP, SMTP, FTP, et plus encore depuis l'extérieur ?.

Pour aller plus loin

Affichage déporté avec VNC

Il est possible de faire passer une connexion à un serveur VNC par un tunnel SSH. Voici un exemple de ligne de commande qui fait ça :

ssh -C -L5900:localhost:5900 serveur.ma-maison-fort-fort-lointaine.com "x11vnc -noxdamage" & (sleep 8s && vncviewer -bgr233 localhost:0)

Source : Merci à legreffier sur le channel #ubuntu-fr du réseau irc.freenode.net qui m'a expliqué les différences entre X, VNC, et NX et qui m'a fourni la ligne de commande ci-dessus :).

Minimiser les déconnections intempestives

Si vous utilisez un routeur pas terrible qui n'est pas capable de conserver une connexion TCP ouverte (pour ne pas le citer, le Syswan Duolinks), et que vous rencontrez fréquemment des erreurs du genre :

Read from remote host mon-serveur.domaine.com: Connection reset by peer
Connection to mon-serveur.domaine.com closed.

Vous devez activer le "keep alive" pour vos connexions SSH. Cela se fait simplement en ajoutant les options suivantes à votre fichier /etc/ssh/ssh_config :

    TcpKeepAlive yes
    ServerAliveInterval 150