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 :
> apt-get install openssh-serverL'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 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 :
#Pour les utilisateurs :
mkpasswd -l > /etc/passwd
#Pour les groupes :
mkgroup -l > /etc/groupIl 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 :
ssh-host-config -yEntrez 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
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.
Ensuite, sélectionnez PATH dans la liste, cliquez sur « Éditer » et ajoutez à la fin du PATH : C:\Cygwin\bin.
Voilà, il ne vous reste plus qu'à autoriser le démarrage du serveur SSH au démarrage de Windows. Pour cela, utilisez les commandes :
net start sshd
cygrunsrv -S sshdII-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 :
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.logEnfin, 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. |
|
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). |
|
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. |
|
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. |
|
AuthorizedKeysFile |
Indique le chemin du fichier contenant les clés publiques des utilisateurs distants. |
|
IgnoreRhosts |
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. |
|
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). |
|
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. |
|
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. |
|
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. |
|
Banner |
Pour certaines juridictions, l'envoi d'un message avant l'authentification est nécessaire pour disposer d'une protection légale. |
|
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 :
/etc/init.d/ssh start
/etc/init.d/ssh stop
/etc/init.d/ssh restartIV. 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 :
ssh login@nom_du serveur
# ou
ssh login@IP_du_serveurLors 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é.
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.
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.
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
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 :
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é_publiqueIV-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 :
ssh login@nom_du serveur
# ou
ssh login@IP_du_serveurIV-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 ».
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é…
ssh-agentLes 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.
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 ~/.ssh/id_dsa.pub
# ou
ssh-add id_rsa.pubC'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
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;
fiAinsi, 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 :
vi /etc/ssh/sshd_config
#la ligne à éditer est :
Port 22
#Changer le 22 en un autre nombreLorsque 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 :
ssh -p 2222 login@serveur_SSHV-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 » :
PermitRootLogin noV-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 :
AllowUsers Foo Bar
AllowGroups SSH_servCet 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 :
DenyUsers Foo Bar
DenyGroups SSH_servDans 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 :
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 » :
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 -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 :
X11Forwarding yesPour ouvrir une session SSH sur le serveur en autorisant le déport d'affichage, il faut rajouter l'option -X à la commande de connexion :
ssh -X login@serveur_SSHDe 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 :
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 :
ssh -p 2222 -N -L 1234:serveur_web_SSH:8080 login@serveur_web_SSHVoilà, 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.
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.