SSH : Secure SHell

<<TableOfContents>>

SSH permet de se connecter à un serveur en mode sécurisé, c'est à dire en minimisant les risques d'espionnage. Si une personne écoute les informations qui transitent entre votre machine (avec un client SSH) et votre serveur (disposant d'un serveur SSH), cette personne ne pourra pas voir ce que vous faites sur le serveur. Les informations qui transitent sont en effet cryptées.

L'installation du serveur SSH (`sshd`) est simple : `aptitude install ssh`

Cela installe par la même occasion un client (`ssh`) et un ensemble de logiciel permettant de gérer vos clefs.

= Configuration du serveur =

La configuration de base du service SSH est correcte, mais améliorable. Il est en effet recommandé de désactiver la possibilité de se connecter par login/password et de ne permettre que la connexion à travers un échange de clefs (mettre `PasswordAuthentication no` dans `/etc/ssh/sshd_options`), ou bien au minimum d'interdire la connexion avec mot de passe vers l'utilisateur `root` (mettre `PermitRootLogin without-password` dans `/etc/ssh/sshd_options`).

Par ailleurs, il est bon de limiter la possibilité de connexion à certains utilisateurs. Pour cela, une technique intéressante est de créer un groupe `ssh` et d'y placer les utilisateurs désirés. Ensuite, ajouter l'option `AllowGroups ssh` dans `/etc/ssh/sshd_options`. C'est tout ! (Comme toujours, relancez le service pour que la modification soit prise en compte)

Enfin, dans le cas d'une machine qui sera gérée par plusieurs personnes, donner directement l'accès root via SSH peut-être gênant (qui a fait quoi : logs des connexions difficiles à analyser). Une solution élégante est de bloquer l'accès root direct (`PermitRootLogin no`), d'ouvrir un accès SSH aux utilisateurs concernés en leur créant chacun un compte et de leur donner un accès aux commandes d'administration via `sudo`. Cependant, il est parfois indispensable d'avoir l'accès root via SSH, par exemple pour faire une sauvegarde distante avec certains logiciels. Dans ce cas la solution idéale est d'autoriser uniquement les accès restreints à des commandes particulières (`PermitRootLogin forced-commands-only`).

Un exemple de configuration `/etc/ssh/sshd_config` est en annexe (tout en bas de la page). Le manuel complet est quant à lui disponible avec la commande `man sshd_config`.

= Utilisation de clef publique / clef privée =

Un des intérêts de SSH est qu'il vous permet de vous connecter à un serveur distant sans avoir besoin d'indiquer votre mot de passe, uniquement en utilisant un échange de clef selon un algorithme de chiffrement à clé publique. L'idée générale est la suivante :
 1. vous vous créez une paire de clé, l'une privée et l'autre publique ;
 1. la clé privée reste sur votre ordinateur (dans le sous-répertoire `.ssh` de votre répertoire personnel), elle est est protégée par cryptage avec un mot de passe ;
 1. vous placerez la clé publique sur tous les serveurs auxquels vous désirez accéder en toute confidentialité.

Concrétement :

 1. Commencez par vous créer une clé : `ssh-keygen` (ne pas spécifier l'emplacement, la taille ou le type, ils sont corrects par défaut)

 Une ''passphrase'' vous sera demandée qui protégera votre clé privée par cryptage. Indiquez toujours une ''passphrase'', sinon votre clé privée serait en accessible (et donc utilisable) par l'administrateur de l'ordinateur ou un pirate éventuel ! Une ''passphrase'' peut être un simple mot de passe, mais vous pouvez profiter de l'occasion pour utiliser une vraie « phrase de passe » (une phrase entière, telle que « ceci n'est pas un si mauvais exemple de phrase !»).
 1. Vous disposez alors de deux fichiers, tous deux sont des fichiers textes :
  . `$HOME/.ssh/id_rsa` : votre clé privée (protégée par cryptage via votre ''passphrase'') ;
  . `$HOME/.ssh/id_rsa.pub` : la partie publique de votre clé.
 1. Vérifiez à ce moment que le répertoire `$HOME/.ssh` est lisible seulement par vous : `chmod 700 $HOME/.ssh` et que la clef privée n'est lisible que par vous : `chmod 600 $HOME/.ssh/id_rsa`.
 1. Sur le serveur distant, vous devrez ajouter le contenu du fichier local `id_rsa.pub` au fichier `$HOME/.ssh/authorized_keys` du serveur. Pour cela, il vous faudra accéder au serveur par un autre moyen (par exemple via un accès SSH par mot de passe) ou contacter l'administrateur de ce serveur.

À partir de ce moment, vous pourrez vous connecter avec `ssh nom.du.serveur` : votre ''passphrase'' vous sera demandée afin que votre client `ssh` puisse lire votre clé privée, un message crypté avec cette clé sera envoyé au serveur qui pourra la décrypter avec la clef publique, etc… (je ne vais pas faire un topo sur le fonctionnement d'un système à clé publique, si ça vous intéresse demandez à Google)

Vous noterez déjà une chose : lorsque vous tapez votre ''passphrase'', c'est votre ordinateur local qui travaille (le client `ssh`). Cette ''passphrase'' est uniquement destinée à pouvoir utiliser la clé privée locale, elle n'est jamais et ne doit en aucun cas être transmise sur le réseau. Ne tapez jamais une ''passphrase'' sur une machine distante si vous n'en êtes pas l'administrateur ou si la connexion n'est pas sécurisée (cryptée) !

Lors de votre première connexion au serveur distant, assurez-vous que vous être le seul à pouvoir modifier le fichier des clefs publiques autorisées, en tapant par exemple : `chmod 644 $HOME/.ssh/authorized_keys`.  Vous pouvez même faire un `chmod 600` afin que personne ne puisse deviner qui vous êtes (en cherchant sous google votre clef ou l'empreinte de votre clef, on pourrait tomber sur une de vos pages : c'est de la paranoïa, mais… qui sait !).

= Utilisation d'un agent SSH =

Saisir sa ''passphrase'' à chaque connexion SSH peut être fastidieux. Heureusement, un agent SSH va nous simplifier la vie. Ce logiciel spécifique tourne en tâche de fond et il est capable de garder en mémoire votre clé privée décryptée et de crypter des informations avec elle. Il sera donc utilisé par votre client `ssh` pour crypter les informations quand c'est nécessaire, votre client n'aura donc plus besoin de vous demander la ''passphrase''.

Voici comment utiliser un agent SSH :
  1. Lancez l'agent SSH avec `ssh-agent xxx` où `xxx` est le nom de votre shell. La plupart du temps il suffira de taper : {{{eval `ssh-agent`}}} pour pouvoir l'utiliser immédiatement dans votre shell courant (uniquement) et ses processus enfants.

  Notez que si vous êtes sur un poste Ubuntu ou Debian, l'agent est généralement lancé lorsque vous démarrez une session X11 (session graphique GNOME ou KDE).

  Pour savoir si l'agent est déjà lancé, tapez `ps waux | grep $SSH_AGENT_PID` : vous devrez voir la ligne correspondante à un processus `ssh-agent`. Dans le cas contraire, c'est que l'agent n'est pas lancé, il faut le faire à la main comme indiqué ci-dessus.

  1. Ajouter votre clef privée à l'agent : `ssh-add`. Votre devrez saisir votre ''passphrase'' à ce moment là, afin que l'agent puisse charger la clé privée et la décrypter.
  1. C'est tout ! Vos divers clients `ssh` sont programmés pour détecter la présence de l'agent SSH et l'utiliseront si besoin ! Désormais, un simple `ssh nom.du.serveur` vous connectera directement au serveur distant en toute sécurité sans rien vous demander.

 Note concernant la sécurité:: si la machine où tourne votre `ssh-agent` est compromise (i.e. que quelqu'un arrive à s'y connecter avec votre compte ou en tant que `root`) alors toutes vos connexions SSH à échange de clef pourront être usurpées ! Attention donc : n'utilisez `ssh-agent` que sur une machine ''robuste'' dont vous êtes totalement sûr, ne le lancez que lorsque vous en avez besoin et ne lui envoyez pas des clefs avec `ssh-add` pour rien. Faites `ssh-add -D` dès que vous n'avez plus besoin de SSH afin que l'agent oublie toutes vos clefs.

 Astuce concernant l'envoi de clé publique vers un serveur:: si vous avez un agent en fonctionnement et qu'il connait votre clé privée (avec `ssh-add`) alors vous pourrez utiliser le petit programme `ssh-copy-id user@machine` qui saura envoyer votre clé publique au serveur `machine` pour l'utilisateur `user`. Il placera automatiquement votre clé publique dans le `$HOME/.ssh/authorized_keys` et donnera les bons droits à ce fichier. Rien de très magique, mais c'est pratique.

= Comment diffuser ma clef publique ? =

Votre clef publique est constituée d'une seule ligne contenue dans le fichier `$HOME/.ssh/id_rsa.pub`.

La clé publique est faite pour être diffusée : vous pouvez l'envoyer telle quelle dans un mail, sans cryptage... vous pouvez même la placer quelque part sur un serveur Web pourquoi pas (voir par exemple sur ThomasNoël) ! Attention cependant à ce que personne n'intercepte votre envoi. En effet, un pirate pourrait remplacer votre clé par la sienne (technique appelée ''Man in the Middle''). Pour éviter cela, on confirmera avec « l'empreinte de la clé » (''fingerprint'') par un autre moyen de communication (rencontre physique, messagerie Jabber/XMPP sécurisée, visioconférence, téléphone, etc.). Pour voir l'empreinte de votre clef, tapez : `ssh-keygen -l -f ~/.ssh/id_rsa.pub`

= Annexes =

== Exemple de configuration du serveur ==

Adaptez la configuration du vôtre, ne prenez pas celle-ci telle quelle ! Note : il s'agit d'une config de Sarge, sans doute cela a-t-il un peu évolué avec Etch, Lenny, Squeeze et Wheezy.

 {{{
# Exemple de configuration du démon sshd : /etc/ssh/sshd_config
# NB : adaptez votre configuration actuelle en fonction, mais ne copiez pas celle-ci telle quelle !!

Port 22
# Imposer l'utilisation du procole 2, le 1 est définitivement trop bogué (et donc dangeureux !)
Protocol 2
# Clés du serveur pour le protocole SSH v2
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key
# Privilege Separation activé (sécurité) (cela casse le système PAM via clavier : c'est pas grâve)
UsePrivilegeSeparation yes

# ...but breaks Pam auth via kbdint, so we have to turn it off
# Use PAM authentication via keyboard-interactive so PAM modules can
# properly interface with the user ("no" à cause de UsePrivilegeSeparation, cf ci-dessus)
PAMAuthenticationViaKbdInt no
# Durée de vite et taille de la clé ephémère pour un serveur en version SSH v1
KeyRegenerationInterval 3600
ServerKeyBits 768

# Logs...
SyslogFacility AUTH
LogLevel INFO

# Authentification:
LoginGraceTime 600
StrictModes yes
# On ne peut pas se connecter directement en root...
#PermitRootLogin no
# ... ou bien si, mais uniquement pour les commandes forcées
PermitRootLogin forced-commands-only
# On autorise seulement certains utilisateurs à se connecter
# (possibilité de faire user@host, mais attention, voir man sshd_config)
#AllowUsers monlogin
# On doit appartenir au groupe "ssh" pour pouvoir se connecter
AllowGroups ssh

RSAAuthentication yes
PubkeyAuthentication yes

# Authentification "rhosts" interdite
RhostsAuthentication no
# Ne pas utiliser les fichiers ~/.rhosts et ~/.shosts
IgnoreRhosts yes
# Si on veut que ça marche il faut mettre les clés des hôtes connues dans /etc/ssh_known_hosts
RhostsRSAAuthentication no
# Pour le protocole version 2
HostbasedAuthentication no
# A décommanter si vous n'avez pas confiance en ~/.ssh/known_hosts pour RhostsRSAAuthentication
#IgnoreUserKnownHosts yes

# Pour autoriser les mots de passe vide (NON RECOMMANDE !)
PermitEmptyPasswords no

# Mot de passe en clairs sur le tunnel : NON !
PasswordAuthentication no

# Export X11 désactivé par défaut
X11Forwarding no
X11DisplayOffset 10
PrintMotd no
#PrintLastLog no
KeepAlive yes
#UseLogin no

#MaxStartups 10:30:60
#Banner /etc/issue.net
#ReverseMappingCheck yes

# Allow client to pass locale environment variables
AcceptEnv LANG LC_*

Subsystem       sftp    /usr/lib/sftp-server
}}}

== Se connecter de l'extérieur tout en fermant le port 22 ==

Alors voilà, généralement votre pare-feu sera configuré pour, soit ne pas accepter les connexions SSH venant d'Internet (Il suffit de voir le nombre de tentative de connexion SSH pour s'en dissuader), soit, si vous avez besoin de vous connecter sur vos serveurs depuis l'extérieur (vous êtes en mission ou vous avez Internet à la maison), vous allez devoir laisser le port SSH ouvert. Ce qui, si vous voyez le nombre de tentative de connexion, devrait vous empêcher de dormir la nuit… et le jour (vu que vous n'avez pas dormi de la nuit).

Il existe une solution très efficace : frapper 3 fois sur le pare-feu avant d'entrer par SSH…

 * La doc est bien réalisée : [[http://www.kik-it.com/previousblog/#entry070309-073501|Toc, toc, toc...]] [[/TocTocToc|(copie locale)]]

/!\ À adapter, nmap se lance en tant que `root`, mais pas forcément SSH…

Tini a en gros la même méthode, sans forcément frapper 3 fois avant d'entrer.

 . ''À noter qu'on n'est pas même obligé d'utiliser `nmap`, un simple `netcat` suffit : nc -z "${IP}" 100 200 300 -- ProgFou''
 . ''"nc -z ..." n'a pas marché pour moi, j'ai dû utiliser "nc -w 1 ..." -- MoussaNombre''
 . ''Ouaip, ça marche pas juste avec `-z` à cause du `DROP` derrière... Le `-w1` est une bonne solution, oui. -- Progfou''

<<Anchor(toctoctoc)>>
=== configuration pour une connexion SSH transparente ===

 * créer/modifier `~/.ssh/config` : {{{
(...)
Host xxx.auf.org
  User username
  ProxyCommand ~/.ssh/toctoctoc.sh %h %p 103 202 301
(...)
}}}
  * remplacer ''username'' par le nom d'utilisateur que l'admin système vous a attribué sur ce serveur

 * spécifier les permissions sur ce fichier : `chmod 600 ~/.ssh/config`

 * créer `~/.ssh/toctoctoc.sh` : {{{#!shell
#!/bin/sh
# Depends: netcat
host=$1 ; port=$2 ; shift 2
# NB : utiliser -G1 au lieu de -w1 sur macOS
if ! nc -4zw1 $host $port ; then
for p in $* ; do
  nc -4zw1 $host $p < /dev/null > /dev/null 2>&1 &
  sleep 0.2
done
fi
exec nc -4 $host $port
}}}

 * rendre ce script exécutable avec : `chmod a+x ~/.ssh/toctoctoc.sh`

 * c'est tout : il suffit de faire `ssh xxx.auf.org` pour se connecter au serveur.

== ssh-add automatique lors de la connexion (pam-ssh) ==

<<Anchor(libpam-ssh)>>

Si vous désirez que votre clé SSH privée soit automatiquement ajoutée dans votre agent ssh lorsque vous vous connectez, il suffit de :
 * faire en sorte que votre clé SSH privée soit codée avec le mot de passe de votre compte (utilisez `ssh-keygen -p` pour changer le mot de passe de votre clé, éventuellement) ;
 * installer le paquet [[http://packages.ubuntu.com/libpam-ssh|libpam-ssh]] : `aptitude install libpam-ssh` ;
 * lire ce qui est indiqué dans /usr/share/doc/libpam-ssh/README.Debian. Je (Thomas) n'ai pas suivi leur idée au niveau de l'authentification car elle fait en sorte qu'un second mot de passe est demandé si la clé n'a pas le même. Voici ce que je propose comme modification au niveau de `gdm` :
 {{{
#%PAM-1.0

# fichier /etc/pam.d/gdm avec deux lignes ajoutées pour lippam-ssh

auth    requisite       pam_nologin.so
auth    required        pam_env.so readenv=1
auth    required        pam_env.so readenv=1 envfile=/etc/default/locale
@include common-auth
auth    optional        pam_gnome_keyring.so
# ajout pam-ssh (apres common-auth) : on teste le même mot de passe sur la clé id_dsa (et si ça échoue, tant pis, c'est "optional")
auth    optional        pam_ssh.so use_first_pass keyfiles=id_rsa
@include common-account
session required        pam_limits.so
@include common-session
session optional        pam_gnome_keyring.so  auto_start
# ajout pam-ssh (apres common-session) :
session optional        pam_ssh.so
@include common-password
}}}

Ensuite, chaque fois que vous vous connecterez via `gdm` à votre compte, votre clé sera décryptée en utilisant le mot de passe saisi à la connexion, et ajouté dans votre agent SSH.

 Inconvénients::
  * Ouh-là-là c'est pas ''secure'', le même mot de passe est utilisé pour deux choses différentes et l'agent est automatiquement renseigné (la clé décryptée) même quand on n'en a pas besoin.

 Avantages::
  * C'est nettement plus sécurisé qu'une clé sans mot de passe si vous ne pouvez/voulez pas demander une seconde fois un mot de passe.
  * Par exemple dans le cadre de l'utilisation de système type `sshfs` (afin que vos utilisateurs puissent accéder à leur répertoire sur le serveur depuis leur poste client, surtout pour les portables), cela vous évite de mettre des clés privées sans mot de passe, ou de devoir demander un second mot de passe pour accéder au serveur… C'est vraiment mieux.
  * Lors des cocktails dînatoires, vous pouvez annoncer à la cantonade que vous faites du SSH à la mode SSO. C'est trop la classe.

== SSH pour accéder à ses fichiers ==

SSH permet d'accéder à ses fichiers facilement avec `scp`, `rsync` (qui passe par SSH par défaut), mais vous pouvez aussi utiliser [[SSHFS]] pour monter un système de fichier réseau via SSH. C'est très pratique et c'est une bonne méthode pour donner accès à des données stockées sur un serveur à une machine portable.

/!\ Attention cependant : des problèmes de corruptions de fichiers ont été découvert, lors d'ouverture de documents ODF par OpenOffice, lorsque ceux-ci approchaient les 64 Kio. En revanche, aucun problème n'a jamais été rencontré lorsqu'on copiait ou déplaçait ces fichiers au préalable (pour les éditer localement puis les remettre sur le réseau ensuite).

== Exemples de configuration avancée ==

La plupart des spécificités de connexion SSH pourront se mettre dans un fichier de configuration général `~/.ssh/config` afin d'éviter de les repréciser dans chaque outil utilisant ce type de connexion.

Voici quelques extraits de configuration SSH présentant des cas d'usage typiques. /!\ Attention : l'ordre des blocs de configuration __est__ important !

Exemple de rebond pour accéder à des serveurs derrière une passerelle : {{{
# pas d'intermédiaire ici
Host un-cas-particulier-en-acces-direct.chez-moi.dom 10.0.0.*
  ProxyCommand none

# on doit frapper avant d'entrer
Host passerelle.chez-moi.dom
  ProxyCommand ~/.ssh/toctoctoc.sh %h %p 123 456 789

# on doit rebondir via la passerelle
Host *.chez-moi.dom
  ProxyCommand ssh passerelle.chez-moi.dom -W %h:%p
}}}