SSH : Secure SHell

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/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).

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

2. 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

3. 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 -b 1024 -t dsa

   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 est un mauvais exemple de phrase !»).

2. Vous disposez alors de deux fichiers, tous deux sont des fichiers textes :

   • $HOME/.ssh/id_dsa : votre clé privée (protégée par cryptage via votre passphrase)

   • $HOME/.ssh/id_dsa.pub : la partie publique de votre clé

3. 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_dsa

4. Sur le serveur distant, vous devrez ajouter le contenu du fichier local id_dsa.pub au fichier $HOME/.ssh/authorized_keys du serveur. Pour cela, il vous faudra accéder au serveur par un autre moyen (telnet, FTP, ssh avec accès par mot de passe, etc) ou contacter l'administrateur de ce serveur.

A 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.

2. 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 décrypter.

3. 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 concerant 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 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'envoie 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_dsa.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 pas 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, téléphone, visioconf, etc.). Pour voir l'empreinte de votre clef, tapez : ssh-keygen -l -f ~/.ssh/id_dsa.pub

Annexes

Exemple de configuration du serveur

Adaptez la configuration du vôtre, ne prenez pas celui-ci tel quel ! Note : il s'agit d'une config de Sarge, sans doute cela a-t-il un peu évoluté avec Etch.

• # 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 parefeu sera configuré pour, soit ne pas accepter les connexions ssh venant de votre FAI/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).

Une solution amusante je trouve est celle-ci : frapper 3 fois sur le parefeu avant d'entrer sur ssh...

• La doc est bien réalisée : Toc, toc, toc... (copie locale)

A 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

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

• modif permission sur ce fichier : chmod 600 ~/.ssh/config

• créer ~/.ssh/toctoctoc.sh :

  #!/bin/sh
  host=$1
  port=$2
  shift 2
  if ! nc -zw1 $host $port ; then
  for p in $* ; do
    nc -w1 $host $p < /dev/null > /dev/null 2>&1
  done
  fi
  exec nc $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)

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 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_dsa
  @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

• Oulalala c'est pas sécure, 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.