IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

OpenSSH : Mise en place et description détaillée d'un serveur SSH

Cet article vise à appréhender l'installation, la configuration et les différentes possibilités d'utilisation d'OpenSSH sous Linux. Il détaille les différentes options de configuration offertes par OpenSSH et les différents types de connexion à un serveur SSH, que ce soit sous un système GNU/Linux, Unix ou Windows.

Commentez Donner une note à l´article (4.5)

Article lu   fois.

L'auteur

Profil ProSite personnel

Liens sociaux

Viadeo Twitter Facebook Share on Google+   

I. Introduction

OpenSSH est un ensemble d'outils développés sous licence OpenBSD. Son nom est la contraction d'OpenBSD Secure SHell. OpenSSH permet d'effectuer des communications sécurisées à travers un réseau, reposant sur le protocole SSH. OpenSSH offre une solution de remplacement sécurisée pour rlogin, telnet, rcp et ftp.
OpenSSH est disponible sur un grand nombre de systèmes d'exploitation dont BSD, Linux, AIX, HP-UX, Solaris, Mac OS X, Windows via Cygwin…

SSH est un protocole de communication sécurisée reposant sur le mode client-serveur. SSH signifie Secure SHell. SSH offre la confidentialité des échanges et l'authentification des correspondants.
Il existe deux versions du protocole, la version 2 étant largement utilisée maintenant.
Le protocole SSH utilise par défaut le port 22.

II. Installation et fonctionnement du serveur OpenSSH

II-A. Sur un système Linux

Remarque : la méthode d'installation proposée dans cet article repose sur le fonctionnement de la distribution Debian et ses dérivés. Pour les autres distributions, veuillez vous reporter aux commandes de gestion des paquets implantées pour la distribution choisie.

Installation du serveur OpenSSH :

Installation d'OpenSSH
Sélectionnez
> apt-get install openssh-server

L'installation du serveur OpenSSH crée un dossier /etc/ssh et génère un couple de clés RSA :

  • ssh_host_rsa_key contenant la clé privée du serveur ;
  • ssh_host_rsa_key.pub contenant la clé publique du serveur.

Lorsqu'un client demande une connexion au serveur, ce dernier envoie au client sa clé publique. Le client utilise alors la clé publique reçue pour envoyer au serveur une clé secrète. Le serveur reçoit alors la clé publique et la décrypte avec sa clé privée, prouvant ainsi qu'il est bien le serveur.
Pour le prouver au client, le serveur crypte un message type avec la clé publique du client et lui envoie. Si le client arrive à lire le message en le décryptant avec sa clé privée, il a l'assurance de communiquer avec le véritable serveur. Le canal de communication sécurisée est alors créé.

Si pour une quelconque raison, vous étiez amené à devoir générer à nouveau le couple de clés du serveur, reportez-vous à la partie IV-2-a et nommez les clés ssh_host_rsa_key.

II-B. Sous Windows, avec Cygwin

Cette partie ne traite pas de ce qu'est Cygwin et comment l'installer, mais de comment installer un serveur SSH sous Cygwin.

cygwin logo Cygwin est une sorte d'émulateur de système Unix sous Windows. Il est constitué d'un grand nombre de paquets, logiciels libres existants sous Linux dont OpenSSH. Ainsi, il est possible d'avoir un serveur SSH sous Windows !

Pour faire fonctionner un serveur SSH sous Cygwin, il est nécessaire de créer les groupes et utilisateurs de Windows dans Cygwin en copiant ceux-ci de Windows à Cygwin :

 
Sélectionnez
#Pour les utilisateurs :
mkpasswd -l > /etc/passwd

#Pour les groupes :
mkgroup -l > /etc/group

Il est nécessaire de donner un mot de passe à votre utilisateur Windows afin de permettre une connexion par SSH !

Les groupes et utilisateurs sont maintenant créés.
Il faut maintenant initialiser la configuration du serveur SSH avec cette commande :

Initialisation du serveur SSH
Sélectionnez
ssh-host-config -y

Entrez les informations demandées.
Lorsqu'il vous est demandé « CYGWIN= », la réponse à entrer est : ntsec tty.

Comme sous Unix/Linux, Windows dispose de variables d'environnement, notamment le PATH. Il est nécessaire d'éditer le PATH et de rajouter le répertoire des commandes pour Cygwin.
Pour cela, allez dans :
Poste de travail --> Propriétés --> Avancé --> Variables d'environnement

proprietes systeme
Fenêtre des propriétés système de WIndows XP

Dans la partie « Variables système », cliquez sur « Nouveau » :
- le nom de la variable à ajouter est : CYGWIN ;
- la valeur de cette variable est : ntsec tty.

variable cygwin
Variable CYGWIN

Ensuite, sélectionnez PATH dans la liste, cliquez sur « Éditer » et ajoutez à la fin du PATH : C:\Cygwin\bin.

variable path
Variable PATH

Voilà, il ne vous reste plus qu'à autoriser le démarrage du serveur SSH au démarrage de Windows. Pour cela, utilisez les commandes :

 
Sélectionnez
net start sshd
cygrunsrv -S sshd

II-C. Cygwin pour Windows Vista et Seven

Les grands changements entre les systèmes Windows XP et Vista (puis Seven) ont entrainé des problèmes dans l'installation traditionnelle de Cygwin.
Vous trouverez dans cette section les manipulations recommandées par Projet Cygwin afin de faire fonctionner au mieux Cygwin sur un OS Windows Vista ou Seven.

Pour lancer l'installeur Cygwin sous Windows Vista et Seven, vous devez faire un clic droit sur l'icône d'installation et choisir l'option : « exécuter en tant qu'administrateur ».

Également, une fois installée, ouvrez une console et exécutez ces six commandes afin de fixer des problèmes de droits :

Commandes permettant de fixer les problèmes de droits sous Vista et Seven
Sélectionnez
chmod +r  /etc/passwd
chmod u+w /etc/passwd
chmod +r  /etc/group
chmod u+w /etc/group
chmod  755  /var  
touch /var/log/sshd.log
chmod 664 /var/log/sshd.log

Enfin, suite à l'exécution de la commande ssh-host-config -y, si le script vous renvoie le commentaire suivant : « This script plans to use cyg_server, Do you want to use a different name? », Répondez « no » puis entrée.

Exécutez ensuite la commande suivante : cyglsa-config.

Lorsque le script s'arrête et vous demande de définir les variables d'environnement pour CYGWIN (« environment variable CYGWIN= »), entrez ceci : ntsec tty.
- ntsec est une variable d'environnement utilisée par Cygwin afin d'utiliser les règles de sécurité de Windows pour le contrôle des accès utilisateurs aux fichiers et autres programmes.
- tty est une variable d'environnement utilisée par Cygwin pour fonctionner correctement avec des éditeurs de texte comme nano ou vi. Sans cela, vous ne pouvez pas insérer de caractères.

III. Configuration du serveur d'OpenSSH

La configuration du serveur ssh se résume en un fichier : /etc/ssh/sshd_config.
La configuration par défaut du serveur est suffisante à son fonctionnement.
Voici une description des différents paramètres qui composent le fichier /etc/shh/sshd_config :

Certaines des descriptions suivantes sont issues de la traduction de la manpage de sshd_config.

Paramètres

Description

Port

Désigne le port qu'écoute le serveur. Par défaut, c'est le port 22.

Protocol

Désigne la version du protocole ssh utilisé par le serveur. Par défaut, c'est la version 2.

ListenAddress 0.0.0.0

Correspond à l'adresse locale d'écoute du serveur sshd en ipv4.

ListenAddress ::

Correspond à l'adresse locale d'écoute du serveur sshd en ipv6.

AllowUsers

Ce mot-clef peut être suivi d'une liste de motifs de noms d'utilisateurs, séparés par des espaces. S'il est spécifié, seuls les noms d'utilisateurs correspondant à un des motifs sont autorisés à se connecter. On peut utiliser les caractères « * » ou « ? » comme des jokers. Seuls les noms d'utilisateurs sont valides ; les identifiants d'utilisateurs (UID) ne sont pas reconnus. Par défaut, la connexion est autorisée pour tous les utilisateurs. Si le motif est de la forme UTILISATEUR@MACHINE, alors UTILISATEUR et MACHINE sont vérifiés séparément, en restreignant les connexions à des utilisateurs en particulier provenant de machines en particulier.

AllowGroups

Ce mot-clef peut être suivi d'une liste de motifs de noms de groupes, séparés par des espaces. S'il est spécifié, seuls les utilisateurs dont le groupe principal ou les groupes supplémentaires correspondent à un des motifs sont autorisés à se connecter. On peut utiliser les caractères « * » ou « ? » comme jokers. Seuls les noms de groupes sont valides ; les identifiants de groupes (GID) numériques ne sont pas reconnus. Par défaut, la connexion est autorisée pour tous les groupes.

DenyUsers

Ce mot-clef est suivi d'une liste de motifs de noms d'utilisateurs, séparés par des espaces. Les utilisateurs dont le nom correspond à un des motifs ne sont pas autorisés à se connecter. Dans les motifs, on peut utiliser les caractères « * » et « ? » comme des jokers. On ne spécifie que des noms d'utilisateurs ; les identifiants numériques d'utilisateurs ne sont pas autorisés. Par défaut, tous les utilisateurs sont autorisés à se connecter. Si le motif est de la forme UTILISATEUR@MACHINE, UTILISATEUR et MACHINE sont vérifiés séparément, et la connexion est restreinte à certains utilisateurs se connectant de certaines machines.

DenyGroups

Ce mot-clef est suivi d'une liste de motifs de noms de groupes, séparés par des espaces. Les utilisateurs dont le groupe principal ou les groupes secondaires correspondent à un des motifs ne sont pas autorisés à se connecter. Dans les motifs, on peut utiliser les caractères « * » et « ? » comme des jokers. On ne spécifie que des noms de groupes ; les identifiants numériques de groupes ne sont pas autorisés. Par défaut, tous les groupes sont autorisés à se connecter.

HostKey

Définit le chemin de la clé privée du serveur. Par défaut, /etc/ssh/ssh_host_rsa_key.

UsePrivilegeSeparation

Spécifie si sshd sépare les privilèges en créant un processus fils non privilégié pour prendre en charge le trafic réseau entrant.
Après une authentification réussie, un autre processus est créé avec les privilèges de l'utilisateur authentifié.
Le but de la séparation de privilèges est d'éviter l'escalade de privilèges si le processus non privilégié est corrompu. Par défaut, yes.

KeyRegenerationInterval

Dans la version 1 du protocole, la clé éphémère du serveur est régénérée automatiquement après ce nombre de secondes (si elle a été utilisée).
Le but de la régénération est d'éviter le décryptage de sessions capturées en s'introduisant plus tard sur la machine et en volant la clé.
La clé n'est jamais stockée nulle part. Si la valeur est 0, la clé n'est jamais régénérée. Par défaut 3600, (secondes).

ServerKeyBits

Définit le nombre de bits de la clé éphémère pour la version 1 du protocole. La valeur minimale est 512 et la valeur par défaut est 768.

SyslogFacility

Donne le code de facilité utilisé lors de l'enregistrement des messages du démon sshd Les valeurs possibles sont : DAEMON, USER, AUTH, LOCAL0, LOCAL1, LOCAL2, LOCAL3, LOCAL4, LOCAL5, LOCAL6, LOCAL7. Par défaut, AUTH.

LogLevel

Donne le niveau de verbosité utilisé lors de l'enregistrement des messages du démon sshd Les valeurs possibles sont : QUIET, FATAL, ERROR, INFO, VERBOSE, DEBUG, DEBUG1, DEBUG2 and DEBUG3. Par défaut INFO. DEBUG et DEBUG1 sont équivalents. DEBUG2 et DEBUG3 spécifient des niveaux plus élevés de sortie de débogage. L'enregistrement à l'aide d'un niveau DEBUG a tendance à empiéter sur la vie privée des utilisateurs et n'est pas recommandé.

LoginGraceTime

Désigne la durée d'inactivité (en minutes) au bout de laquelle le serveur se déconnecte automatiquement. Si la valeur est 0 (zéro), le serveur ne se déconnecte jamais. Par défaut, 120.

PermitRootLogin

Définit si oui ou non le super-utilisateur Root a l'autorisation de se connecter par ssh.
L'argument est « yes », « without-password », « forced-commands-only » ou « no ». Par défaut, yes.
Si cette option est réglée à « without-password », l'authentification par mot de passe est désactivée pour root.
Si cette option est réglée à « forced-commands-only », les connexions de root sont autorisées avec une authentification par clé publique, mais seulement si l'option command est spécifiée (ce qui peut être utile pour effectuer des sauvegardes à distance même si les connexions de root sont normalement interdites). Toutes les autres méthodes d'authentification sont désactivées pour root.
Si cette option est réglée à « no », root n'est pas autorisé à se connecter.

StrictModes

Spécifie si sshd doit vérifier les modes et le propriétaire des fichiers de l'utilisateur et du répertoire de base (home directory) de l'utilisateur avant d'accepter une connexion. C'est normalement souhaitable, parce que quelquefois, les novices laissent accidentellement leur répertoire ou leurs fichiers en accès complet à tout le monde. Par défaut, yes.

RSAAuthentication

Spécifie si on autorise la pure authentification RSA. Par défaut « yes ». Cette option ne s'applique qu'à la version 1 du protocole.

PubkeyAuthentication>

Spécifie si on autorise l'authentification par clé publique, par opposition à l'authentification par mot de passe. Par défaut, yes.
Note : Cette option ne s'applique qu'à la version 2 du protocole.

AuthorizedKeysFile

Indique le chemin du fichier contenant les clés publiques des utilisateurs distants.

IgnoreRhosts
RhostsRSAAuthentication

Spécifie que l'on n'utilise pas les fichiers .rhosts et .shosts pour les authentifications activées par les options RhostsAuthentication et RhostsRSAAuthentication ou HostbasedAuthentication.
Les fichiers /etc/hosts.equiv et /etc/ssh/shosts.equiv sont néanmoins utilisés. Par défaut, yes.

HostbasedAuthentication

Spécifie si on autorise une authentification par rhosts ou /etc/hosts.equiv conjointement avec une authentification de machine cliente réussie par clé publique (authentification par machines). Cette option est similaire à l'option RhostsRSAAuthentication et ne s'applique qu'à la version 2 du protocole. Par défaut, no.

IgnoreUserKnownHosts

Spécifie si sshd doit ignorer le fichier $HOME/.ssh/known_hosts de l'utilisateur lors des authentifications des options RhostsRSAAuthentication ou HostbasedAuthentication. Par défaut, no.

PermitEmptyPasswords

Définit si le serveur accepte la connexion à un compte utilisateur ne possédant pas de mot de passe. Par défaut, no.

ChallengeResponseAuthentication

Spécifie si on autorise l'authentification par stimulation-réponse (challenge response).
Toutes les formes d'authentification de login.conf5 sont gérées. Par défaut, yes.

PasswordAuthentication

Permet d'autoriser l'authentification par mot de passe. Par défaut, yes.

X11Forwarding

Permet de rediriger les sorties X11. Cela permet donc d'ouvrir des applications graphiques à distance par exemple.
La redirection X11 est automatiquement désactivée si l'option UseLogin est activée. Par défaut, no.

X11DisplayOffset

Spécifie le premier numéro d'affichage disponible pour les redirections X11 de sshd. Ceci évite à sshd d'interférer avec les vrais serveurs X11. Par défaut, 10.

PrintMotd

Permet d'afficher le contenu du fichier /etc/motd (message du jour) à la connexion. Par défaut, yes

PrintLastLog

Permet d'afficher la date et l'heure de la dernière connexion. Par défaut, yes.

TCPKeepAlive

Permet de garder ouverte une connexion ssh existante grâce à l'envoi d'un paquet chiffré par ssh. Par défaut, yes.

UseLogin

Spécifie si on utilise login pour les connexions à des sessions interactives. Par défaut, no.
Note 1 : on n'utilise jamais login pour l'exécution de commandes à distance.
Note 2 : si cette option est activée, on désactive X11Forwarding parce que login ne sait pas traiter les cookies xauth. Si on spécifie l'option UsePrivilegeSeparation, elle sera désactivée après l'authentification.

MaxStartups

Spécifie un nombre maximal de connexions concurrentes au démon sshd non authentifiées. Les connexions supplémentaires sont purgées si elles ne peuvent pas s'authentifier ou si le délai de grâce défini à l'aide de l'option LoginGraceTime expire pour une connexion. Par défaut 10.
Par ailleurs, on peut activer une purge hâtive aléatoire en spécifiant un triplet « début:taux:total » (par exemple, « 10:30:60 »).
sshd refuse les tentatives de connexion avec une probabilité de « taux/100 » (30 %) s'il y a « début » (10) connexions non authentifiées en cours. La probabilité augmente linéairement et toutes les tentatives de connexion sont refusées si le nombre de connexions non authentifiées atteint « total » (60).

Banner

Pour certaines juridictions, l'envoi d'un message avant l'authentification est nécessaire pour disposer d'une protection légale.
Le contenu du fichier spécifié est envoyé à l'utilisateur distant avant d'autoriser la connexion. Cette option n'est disponible qu'avec la version 2 du protocole. Par défaut, on n'affiche pas de message.

AcceptEnv

Spécifie quelles variables d'environnement envoyées par le client seront copiées dans l'environnement de la session. Cette option n'est supportée que par la version 2.

Subsystem sftp

Configure un sous-système externe (par exemple un démon de transfert de fichiers). Les arguments doivent être un nom de sous-système et une commande à exécuter lors d'une requête à ce sous-système. La commande sftp-server8 implémente le sous-système de transfert de fichiers « sftp ». Par défaut, aucun sous-système n'est défini. Note : cette option ne s'applique qu'à la version 2 du protocole.


D'autres options existent. Vous pouvez les retrouver sur la manpage officielle de sshd_config d'OpenSSH.

Comme souvent, le démarrage, l'arrêt et le redémarrage du serveur se font comme ceci, respectivement :

 
Sélectionnez
/etc/init.d/ssh start
/etc/init.d/ssh stop
/etc/init.d/ssh restart

IV. Authentification

Différentes possibilités existent concernant l'authentification pour la connexion au serveur SSH : l'authentification par mot de passe et l'authentification par échange de clés. Voici comment mettre en place ces deux techniques.

IV-A. Par login/mot de passe

Cette méthode d'authentification est très simple, il suffit d'exécuter la commande de connexion SSH :

 
Sélectionnez
ssh login@nom_du serveur
# ou
ssh login@IP_du_serveur

Lors de la première connexion SSH au serveur avec ce login, il vous est demandé si le fingerprint de la clé publique du serveur est bon. Si le fingerprint de la clé publique du serveur est bien le même que celui affiché à votre écran, vous pouvez accepter de continuer en tapant yes.
La clé publique du serveur SSH est alors copiée dans le fichier ~/.ssh/know_hosts, ceci permettant garder en mémoire l'authenticité de la clé publique du serveur pour les prochaines connexions.

Ensuite, le mot de passe de l'utilisateur utilisé pour se connecter vous est demandé.

Première connexion par SSH - Fingerprint
Sélectionnez
The authenticity of host '[192.168.0.7] ([192.168.0.7])' can t be established.
RSA key fingerprint is 12:12:m3:df:6f:23:3b:18:99:ea:84:p6:d1:de:f6:71.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '[192.168.0.7]' (RSA) to the list of known hosts.
root@192.168.0.7 s password:

IV-B. Par échange de clés

Cette méthode d'authentification repose sur la cryptographie asymétrique, par l'utilisation du couple clé privée/clé publique créé par l'utilisateur client, de la même façon que le fait le serveur.

IV-B-1. Génération des clés

SSH propose de générer le couple de clés publique/privée en utilisant au choix deux algorithmes : DSA et RSA.
Utiliser au choix RSA ou DSA.
Pour ce faire, OpenSSH propose un outil de génération très simple à utiliser : ssh-keygen.

Génération du couple clé privée / clé publique pour le user client
Sélectionnez
ssh-keygen -t rsa

À l'exécution de cette commande, le couple de clés est généré. Il vous est alors demandé le chemin où vous voulez stocker ces clés et leur nom. La touche « entrée » permet de valider le chemin proposé par défaut.
La clé privée prend les droits 600 et la clé publique 644.
Suite à cela, il vous est demandé d'entrer une passphrase qui vous permettra de protéger votre clé privée. Cette passphrase peut contenir tout caractère et « métacaractère », même des espaces. Elle est à retenir, car elle vous est demandée à chaque connexion par échange de clés.

 
Sélectionnez
user@debian:~/.ssh$ ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/home/user/.ssh/id_rsa): 
Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in /home/user/.ssh/id_rsa.
Your public key has been saved in /home/user/.ssh/id_rsa.pub.
The key fingerprint is:
f1:68:21:f2:b5:61:c2:cd:22:c4:48:e8:ab:c2:12:z7 user@debian
The key s randomart image is:
+--[ RSA 2048]----+
|     o++o        |
|    o..o.o o     |
|   .  o = + .    |
|  . .  o +       |
| . P .  S .      |
|.   =    o o     |
|.. .      . .    |
|o..        .     |
|.o               |
+-----------------+

IV-B-2. Diffusion de la clé publique

Pour permettre l'authentification par échange de clés, il est nécessaire de donner votre clé publique au serveur, selon de principe de la cryptographie asymétrique.
Encore une fois, OpenSSH a pensé à tout et vous offre un outil pour copier votre clé publique au serveur en toute sécurité : ssh-copy-id

 
Sélectionnez
ssh-copy-id -i chemin/clé/publique/id_rsa.pub login@serveur_ssh

À cet instant, le fichier known_hosts est alors lu pour voir si la machine est connue. Puis, le mot de passe session de l'utilisateur « login » est demandé et ce sera la dernière fois. Les prochaines connexions avec cet utilisateur se feront donc par échange de clé privée/clé publique et à l'aide de la passphrase entrée lors de la génération des clés de l'utilisateur.

Bien que ssh-copy-id soit conçue spécialement pour copier votre clé publique sur le serveur SSH, il est possible d'effectuer cette tâche d'une autre façon, avec scp :

Copie de la clé publique cliente sur le serveur SSH avec scp
Sélectionnez
scp /home/login/.ssh/id_rsa.pub login@serveur_SSH:/home/login/clé_publique

ssh login@serveur_SSH
cat clé_publique >> /home/login/.ssh/authorized_keys
rm clé_publique

IV-B-3. Connexion ssh

De cette manière donc, la connexion ssh ne se fait plus par login/mot de passe, mais grâce à l'échange de clés privées/clés publiques et à l'utilisation de la passphrase.
La commande de connexion reste cependant la même :

 
Sélectionnez
ssh login@nom_du serveur
# ou
ssh login@IP_du_serveur

IV-C. Au revoir mots de passe, passphrase…

Si vous utilisez ssh régulièrement, vous avez dû vous rendre compte que cela devient très vite fatigant de devoir retaper à chaque connexion ssh son mot de passe ou sa passphrase.
Il existe deux remèdes à ce désagrément : l'authentification sans mot de passe et ssh-agent.

IV-C-1. L'authentification sans mot de passe

L'authentification sans mot de passe est très pratique et pratiquement incontournable pour exécuter des scripts distants, par exemple un script shell d'arrêt global se connectant à tour de rôle sur vso différents serveurs pour exécuter la commande spécifique d'arrêt.
L'authentification sans mot de passe est donc très efficace, mais pose cependant un problème de sécurité non négligeable.

Son principe est tout simple.
Cela consiste en la génération d'un couple de clé privée/clé publique, de la même manière que pour l'authentification par échange de clés et en la diffusion de votre clé publique. Cependant, au moment de rentrer une passphrase comme il l'est demandé au cours de la génération du couple de clés, vous n'entrez rien et vous faites « Entrée ». Répétez cette touche à la demande de resaisie de la passphrase.
Cela a pour effet de renseigner la chaîne vide comme passphrase, ce qui revient à dire qu'il n'y a pas de passphrase.
Ainsi, lors de la connexion par ssh, l'étape de demande de passphrase est « omise » et la connexion s'effectue sans demande « de vérification au clavier ».

Authentification sans mot de passe
Sélectionnez
debian:/home/user# ssh login@IP_serveur 
Linux lenny.debian.com 2.6.26-1-686 #1 SMP Fri Mar 6 11:08:15 UTC 2009 i686

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
lenny:~#

IV-C-2. Utilisation de ssh-agent

Ssh-agent est un autre outil développé par OpenSSH permettant d'utiliser l'authentification par échange de clés avec une passphrase sans avoir à toujours taper cette dernière.
Une fois ssh-agent démarré, tous les commandes ou programmes exécutés par ssh sont des sous-processus de ssh-agent, ne nécessitant plus d'authentification ultérieure.

Ainsi, il ne reste donc plus qu'à récupérer les variables d'environnement, de les mettre en place pour ssh-agent et demander à ssh-agent de s'occuper de notre clé publique et le tour est joué…

récupération des variables d'environnement
Sélectionnez
ssh-agent

Les variables d'environnement s'affichent à l'écran. Pour les mettre en place pour ssh-agent, il suffit de copier les trois lignes de l'écran et de les recoller dans la console.

Mise en place des variables d'environnement pour ssh-agent
Sélectionnez
user@debian:~$ ssh-agent 
SSH_AUTH_SOCK=/tmp/ssh-TubtX25143/agent.25943; export SSH_AUTH_SOCK;
SSH_AGENT_PID=25984; export SSH_AGENT_PID;
echo Agent pid 25984;
ssh-add
Sélectionnez
ssh-add ~/.ssh/id_dsa.pub
# ou
ssh-add id_rsa.pub

C'est fini… Enfin presque. En effet, ssh-agent n'est « valable » que dans la console dans laquelle il a été lancé. Ce qui signifie que si vous fermez votre console et en ouvrez une autre, il faut tout recommencer.

IV-C-3. Automatiser l'utilisation de ssh-agent

Comme il a été dit à la fin de la partie IV-3-b, ssh-agent n'est valable que pour la console dans laquelle il est lancé.
Ainsi, pour optimiser l'utilisation de ssh-agent et éviter de devoir recommencer le lancement de ssh-agent et la copie des variables d'environnement à chaque fois, des personnes se sont penchées sur le problème (notamment Joseph M. Reagle) et ont écrit un bout de code pour pallier ce problème.

Ce code est à coller dans le fichier .x_profile de votre HOME. Par exemple, avec un shell en Bash, le fichier en question est : /home/votre_user/.bash_profile

Code permettant de ne plus avoir à lancer ssh-agent à chaque nouvelle console. Ce code est à placer dans le .x_profile de votre home
Sélectionnez
SSH_ENV="$HOME/.ssh/environment"

function start_agent {
     echo "Initialising new SSH agent..."
     /usr/bin/ssh-agent | sed 's/^echo/#echo/' > "${SSH_ENV}"
     echo succeeded
     chmod 600 "${SSH_ENV}"
     . "${SSH_ENV}" > /dev/null
     /usr/bin/ssh-add;
}

# Source SSH settings, if applicable

if [ -f "${SSH_ENV}" ]; then
     . "${SSH_ENV}" > /dev/null
     ps -ef | grep ${SSH_AGENT_PID} | grep ssh-agent$ > /dev/null || {
         start_agent;
     }
else
     start_agent;
fi

Ainsi, avec ce code, il n'est plus nécessaire de lancer ssh-agent. Vous n'avez qu'à copier votre clé sur le serveur si ce n'est pas déjà fait et vous connecter en ssh sans besoin de mot de passe.

V. Un peu de sécurité

V-A. Changer le port d'écoute côté serveur

Comme dit plus haut, le port d'écoute par défaut d'un serveur SSH est le port 22. Or, vous remarquerez que très souvent, des machines inconnues tentent de se connecter par SSH sur vos serveurs grâce à des scripts automatisés testant sur le port 22 un grand nombre d'utilisateurs et mot de passe couramment utilisés tels que root, mysqladmin, oracle…
Une première barrière pour éviter toute intrusion par SSH est de changer le port d'écoute du serveur SSH.

Les ports jusqu'à 1024 sont « réservés » pour divers protocoles et applications. Ainsi, choisissez un port de nombre supérieur à 1024.
Pour changer le port d'écoute, il suffit d'éditer le fichier de configuration côté serveur : /etc/ssh/sshd_config :

Changement du port d'écoute du serveur SSH
Sélectionnez
vi /etc/ssh/sshd_config

#la ligne à éditer est :
Port 22

#Changer le 22 en un autre nombre

Lorsque le port de connexion au serveur SSH est changé, différent du port par défaut 22, il est nécessaire de le renseigner dans la ligne de commande de connexion en utilisant l'option -p.

Par exemple, si vous avez modifié le port par défaut et choisi d'utiliser le port 2222, la ligne de commande de connexion devient :

 
Sélectionnez
ssh -p 2222 login@serveur_SSH

V-B. Bloquer l'accès à Root par SSH

Les scripts automatisés (notamment) qui tentent de se connecter par SSH sur vos serveurs utilisent principalement les logins couramment utilisés dont Root fait bien sûr partie.
Le fait de laisser l'accès à Root par SSH fait gagner une étape à un pirate qui souhaite s'introduire dans votre système. En effet, le fait de bloquer l'accès à Root entraine la nécessité à un pirate de trouver un nom d'utilisateur autre, existant sur votre système. Sans cela, le pirate dispose donc du nom d'utilisateur, il ne lui reste plus qu'à trouver le mot de passe de Root pour s'introduire.

Cette fois encore, tout se passe dans le fichier de configuration du serveur SSH /etc/ssh/sshd_config. Une option permet de bloquer l'accès à Root, qu'il faut placer à « no » :

Option de /etc/ssh/sshd_config permettant de bloquer l'accès à Root par SSH
Sélectionnez
PermitRootLogin no

V-C. Restreindre l'accès à des utilisateurs et/ou groupes spécifiques

La section précédente montre comment bloquer l'accès SSH au super-utilisateur Root. Cependant, par défaut, SSH autorise l'accès à tous les utilisateurs de tous les groupes.
De nombreux logiciels créent automatiquement un utilisateur et/ou un groupe spécifique pour les administrer. Ces utilisateurs possèdent un mot de passe par défaut qui, s'il n'est pas modifié, peut permettre à un pirate d'accéder facilement à votre machine en utilisant ce couple de login/mot de passe, tel que oracle/oracle.

Il est donc possible et fortement conseillé de restreindre l'accès au serveur SSH à quelque(s) utilisateur(s) privilégié(s) de confiance. Plusieurs options sont disponibles pour effectuer cette restriction, au niveau du fichier de configuration du serveur SSH /etc/ssh/sshd_config :

Restriction d'accès SSH par autorisation limitée
Sélectionnez
AllowUsers Foo Bar
AllowGroups SSH_serv

Cet exemple utilise les options « Allow… ». Ces deux options permettent de définir les utilisateurs et groupes autorisés à se connecter par SSH. Seuls les utilisateurs Foo et Bar, ainsi que les utilisateurs appartenant au groupe SSH_serv peuvent donc se connecter. Tous les autres voient leur accès par SSH bloqué.

Il existe une autre façon de restreindre l'accès :

Restriction d'accès SSH par blocage
Sélectionnez
DenyUsers Foo Bar
DenyGroups SSH_serv

Dans ce nouvel exemple, la restriction ne se fait plus par la définition d'une liste d'utilisateurs et groupes autorisés à se connecter, mais par la définition des utilisateurs et groupes n'ayant pas le droit de se connecter.
Ici, tous les utilisateurs peuvent se connecter par SSH à l'exception des utilisateurs Foo et Bar, ainsi que les membres du groupe SSH_serv.

VI. Transfert de fichiers sécurisé : SCP

VI-A. Fonctionnement de la commande scp

Il existe de nombreuses façons de transférer des fichiers d'une machine à une autre, ftp, rcp… mais celles-ci ne sont pas sécurisées. OpenSSH propose donc une commande permettant ce transfert à travers un canal chiffré, reposant sur le protocole SSH : scp.

Son utilisation est très simple. C'est une combinaison de cp et de ssh.
Dans le premier exemple, le fichier /var/log/data.txt est transféré de la machine locale vers le HOME de l'utilisateur SSH utilisé pour la connexion au serveur SSH :

 
Sélectionnez
scp /var/log/data.txt login@serveur_SSH:/home/login/

Dans ce second exemple, le fichier /var/log/data.txt est transféré du serveur SSH vers le HOME de l'utilisateur local « moi » :

 
Sélectionnez
scp login@serveur_SSH:/var/log/data.txt /home/moi/

VI-B. Scp par un port différent du port 22

Dans le paragraphe V qui traite de la sécurité, il est conseillé d'utiliser un port différent du port 22 par défaut d'écoute du serveur SSH. Or, comme il a été vu plus haut, cette action entraine le fait de devoir spécifier le numéro du port utilisé lors de la connexion par SSH.
Scp utilisant SSH, il en est donc de même pour lui, il est nécessaire de renseigner le port à utiliser pour contacter le serveur SSH dans la commande. Cela se fait avec l'option -P.

la commande ssh utilise l'option -p (« p » minuscule) pour spécifier le numéro de port à utiliser, alors que scp utilise l'option -P (P majuscule).

scp vers un serveur SSH écoutant le port 2222
Sélectionnez
scp -P 2222 /var/log/data.txt login@serveur_SSH:/home/login/

VII. Utiliser une application graphique à distance : X11 Forwarding

OpenSSH permet de se connecter de manière sécurisée sur un ordinateur distant. Une des diverses options que propose OpenSSH est le X11 forwarding. Cela consiste à faire du déport d'affichage sur une machine cliente, et ce, à travers un canal chiffré.
Par exemple, si vous souhaitez travailler chez vous sur une application graphique couteuse, installée uniquement sur le serveur de votre entreprise, cela est possible de le faire en toute sécurité.

Les prérequis sont :

  • disposer d'une connexion SSH avec le serveur ;
  • disposer d'un serveur graphique sur la machine cliente ;
  • un débit suffisant pour faire transiter les informations graphiques.

Pour le X11 Forwarding, il n'est pas nécessaire d'avoir d'installé un serveur graphique sur le serveur, mais juste sur la machine devant afficher la fenêtre graphique de l'application.

Comme souvent, pour activer l'option X11 Forwarding sur le serveur SSH, il suffit de mettre à « yes » l'option X11Forwarding dans le fichier de configuration su serveur SSH : /etc/ssh/sshd_config :

Option X11Forwarding
Sélectionnez
X11Forwarding yes

Pour ouvrir une session SSH sur le serveur en autorisant le déport d'affichage, il faut rajouter l'option -X à la commande de connexion :

 
Sélectionnez
ssh -X login@serveur_SSH

De plus amples informations sur le X11 Forwarding sont disponibles dans l'article de Davidbrcz et ovh : Exécution d'applications X à distance

VIII. Utiliser SSH en tant que tunnel sécurisé : TCP Forwarding

Le TCP Forwarding, ou tunnel SSH, permet d'accéder à distance à des services théoriquement inaccessibles depuis l'extérieur du réseau de façon sécurisée. Par exemple, vous pouvez grâce à ce procédé accéder à l'intranet de votre entreprise depuis l'extérieur, vous connecter à votre serveur mail ou bien encore traverser un pare-feu.

Pour être plus clair, voici un schéma théorique de ce qui se passe lors d'une communication par un tunnel SSH :

schema tunnel ssh
Schéma de principe d'un tunnel SSH

Ce schéma montre la communication pour accéder à l'intranet de votre entreprise depuis l'extérieur.

  • Le serveur Web hébergeant l'intranet de votre entreprise utilise le port 8080.
  • 1234 est le port côté client depuis lequel le tunnel SSH est créé (remarque : utilisez un port supérieur à 1024).
  • Pour des raisons de sécurité, le port du serveur SSH a été changé, il est accessible sur le port 2222.

Ainsi pour créer le tunnel SSH, la commande est :

Établissement d'un tunnel SSH vers le serveur web de l'intranet
Sélectionnez
ssh -p 2222 -N -L 1234:serveur_web_SSH:8080 login@serveur_web_SSH

Voilà, le tunnel est créé. Maitenant pour accéder à l'intranet, il suffit de changer les paramètres de votre navigateur web préféré et de renseigner l'utilisation du proxy : localhost par le port : 1234.

paramètres de connexion du navigateur
Fenêtre des paramètres de connexion de votre navigateur

IX. Conclusion

Avec cet article, j'ai essayé de vous présenter les nombreuses possibilités d'utilisation de SSH dont l'utilité n'est plus à prouver.

X. Liens utiles

Ces liens peuvent être utilisés en complément :
- Site officiel d'OpenSSH
- Site officiel de Cygwin
- Manpage de sshd en français
- Manpage developpez.com

Remerciements

Merci à Davidbrcz et ovh pour leur article sur l'exécution d'applications X à distance.
Merci à _Mac_ pour la qualité de sa relecture.

Vous avez aimé ce tutoriel ? Alors partagez-le en cliquant sur les boutons suivants : Viadeo Twitter Facebook Share on Google+   

Ce document est issu de http://www.developpez.com et reste la propriété exclusive de son auteur. La copie, modification et/ou distribution par quelque moyen que ce soit est soumise à l'obtention préalable de l'authorisation de l'auteur.