Réseau - Web - GNU/Linux

2018 18 janvier

Restreindre un accès SSH

Rédigé par Marc GUILLAUME | Aucun commentaire

Créer un accès SSH pour un usage précis

il existe de nombreux cas de figure où l'on veut offrir un accès SSH à des utilisateurs sur un serveur pour une utilisation bien précise sans leur accorder de droits en dehors de cette utilisation ciblée. C'est par exemple le cas lorsque l'on veut concéder un accès MySQL au travers d'un tunnel SSH, donner accès à un dépôt CVS etc.

La difficulté

La contrainte posée par SSH est que pour se connecter l'utilisateur doit disposer d'un compte unix sur la machine serveur SSH. Si vous lui créez un compte utilisateur classique, disposant d'un shell, même limité, l'utilisateur pourra se loguer sur le serveur comme un utilisateur normal de la machine. Ce n'est pas toujours souhaitable.

Il faut donc disposer d'un moyen de laisser l'utilisateur se connecter à une application serveur spécifique et rien d'autre.

La solution

Pour pouvoir appliquer cette solution il faut impérativement que l'identification sur le serveur SSH se fasse par un jeu de clés Diffie/Hellman. L'utilisateur n'a pas à saisir de mot de passe mais doit avoir fourni sa clé publique pour qu'elle soit installée sur le serveur.

La procédure de connexion par clés (expliquée ici) consiste, sur le serveur SSH, à stocker les clés des utilisateurs autorisés à utiliser un compte sur le serveur dans un fichier (conventionnellement le fichier $HOME/.ssh/authorized_keys de l'utilisateur de connexion) qui sera consulté lors des tentatives de connexion de l'utilisateur pour son identification et l'acceptation ou non de sa connexion.

C'est dans ce fichier que plusieurs options de sshd, le démon SSH, va permettre de limiter les accès d'un utilisateur.

La page de man de sshd précise (dans sa traduction française) :

FORMAT DU FICHIER AUTHORIZED_KEYS
$HOME/.ssh/authorized_keys est le fichier par défaut qui liste les clefs publiques autorisées pour l'authentification RSA 
pour la version 1 du protocole, et pour l'authentification par clef publique (PubkeyAuthentication) pour la version 2 du protocole. 
On peut utiliser l'option AuthorizedKeysFile pour spécifier un autre fichier de configuration. 

 Chaque ligne du fichier contient une clef (les lignes vides ou débutant par le caractère « # » sont ignorées et considérées comme des commentaires). 
Chaque clef publique RSA consiste en les champs suivants, séparés par des espaces : options, bits, exposant, modulo, commentaire. 
Chaque clef publique pour la version 2 du protocole consiste en : options, type de clef, clef encodée en base64, commentaire. 
Les champs d'option sont optionnels ; leur présence est déterminée par le fait que la ligne commence avec un nombre ou pas 
(le champ d'option ne commence jamais par un nombre). Les champs bits, exposant, modulo et commentaire déterminent la clef RSA pour la version 1 du protocole ; 
le champ commentaire n'est pas utilisé pour quoi que ce soit (mais peut servir à l'utilisateur pour identifier sa clef). 
Pour la version 2 du protocole, le type de clef est « ssh-dss » ou «ssh-rsa ». 

 Note : les lignes contenues dans ce fichier font en général quelques centaines de caractères (à cause de la taille du modulo de la clef RSA). 
Il n'est pas très judicieux de les saisir manuellement ; il est plus fiable de les copier dans les fichiers identity.pub id_dsa.pub ou id_rsa.pub puis de les coller. 
sshd impose une taille minimale du modulo pour la clef RSA pour la version 1 du protocole et pour les clefs pour la version 2 du protocole de 768 bits. 
 Les options (s'il y en a) consistent en une liste d'entrées séparées par des virgules. Les espaces sont interdits, sauf entre des guillemets. 
Les spécifications d'options suivantes sont supportées. Note : les mots-clefs des options ne sont pas sensibles à la casse.
[...]
from=pattern-list
	Spécifie qu'en plus de l'authentification RSA, le nom canonique de la machine distante doit figurer dans la liste des motifs séparés par des virgules (« * » et «? » sont des jokers). La liste peut aussi contenir des motifs précédés par l'opérateur de négation « ! » ; si le nom canonique de la machine correspond au motif nié, on n'accepte pas la clef. Le but de cette option est éventuellement d'améliorer la sécurité : l'authentification RSA en elle-même ne permet pas d'avoir confiance dans le réseau ou les serveurs de noms ou quoi que ce soit (à part la clef) ; par contre, si quelqu'un vole la clef, cette clef lui permet de se connecter depuis n'importe où dans le monde. Cette option supplémentaire rend encore plus difficile l'utilisation d'une clef volée (les serveurs de noms et/ou les routeurs peuvent avoir été compromis en plus de la clef elle-même).
command=commande
	Spécifie que cette commande doit être exécutée si on utilise cette clef pour s'authentifier. La commande fournie par l'utilisateur (s'il y en a une) est ignorée. La commande est exécutée sur un pseudo-terminal (pty) si le client a demandé un pseudo-terminal ; sinon elle est exécutée sans terminal. Si on a besoin d'un canal 8-bits propre, on ne doit pas demander de pseudo-terminal, ou alors on spécifie no-pty On peut inclure une apostrophe (« ' ») dans la commande en la faisant précéder d'une anti-barre (« \ »). Cette option peut être utile pour restreindre à des actions spécifiques. Par exemple, une clef peut n'autoriser qu'à effectuer des sauvegardes distantes, mais rien d'autre. Note : le client doit spécifier des redirections TCP/IP ou X11 sauf s'ils sont explicitement interdits. Cette option s'applique à l'exécution d'un interpréteur de commandes (shell), d'une commande ou d'un sous-système.
environment=NAME=value
	Spécifie que la chaîne de caractère doit être ajoutée à l'environnement lors de la connexion en utilisant cette clef. Les variables d'environnement définies de cette manière outrepassent les autres variables d'environnement par défaut. On peut spécifier plusieurs de ces options. Cette option est désactivée automatiquement si l'option UseLogin est activée.
no-port-forwarding
	Interdit les redirections TCP/IP si on utilise cette clef pour l'authentification. Toute demande de redirection de port de la part de l'utilisateur retournera une erreur. Ceci peut être utilisé par exemple pour une connexion avec l'option command
no-X11-forwarding
	Interdit les redirections X11 si on utilise cette clef pour l'authentification. Toute demande de redirection X11 de la part de l'utilisateur retournera une erreur.
no-agent-forwarding
	Interdit les redirections de l'agent d'authentification si on utilise cette clef pour l'authentification.
no-pty
	Empêche l'allocation de terminal (toute demande d'allocation d'un terminal virtuel échouera).
permitopen=host:port
	Limite les redirections de port « ssh -L » locales de telle manière qu'il n'est possible de se connecter qu'à la machine et au port spécifiés. On peut spécifier des adresse IPv6 avec une autre syntaxe : host/port On peut spécifier plusieurs options permitopen en les séparant par des virgules. Aucune correspondance n'est effectuée sur les noms de machines, ils doivent être des adresses ou des domaines littéraux.

C'est donc l'option command des options de saisie de clé dans $HOME/.ssh/authorized_keys qu'il va falloir utiliser. En prenant l'exemple d'un accès réduit à MySQL il faudra placer en tête de la clé de l'utilisateur la mention command="/usr/bin/mysql", celui-ci n'aura alors accès qu'à MySQL. La clé copiée dans le fichier ressemblera à quelque chose de ce genre :

command="/usr/bin/mysql" ssh-dss AAAAB3NzaC1kc3MAAACBAKS1OVNWEVX6CSaza/WasGZ62Wp
iXR4BqK0U1KOzI9b2/YlzYNqoLgqR5ELyA89tW28e/TOFtJ0yFFBBR79wHGGwij374VPs3jNq7RcmiJL
vMr36fmeJs/QL0pWwvUX0NTNcxVC87khvuIlLrtR3MrSMYLQDZgDJ+sDrM3oYHQY1AAAAFQCHRJ6BX0u
XJZJbeoIVb4LOkoQhVQAAAIBqGzn33b7d/tgw3qiUk6Ns9Ng99Upr3gm7QzqAqekXImZ/Camx/DpF14H
Q8RiwK4UBMuPHaMC9BV7Jqd5j9NtyhGnhfccM1IRzSLwsVHY9DBsQEYpqPfmHZvcEMiP8Enj7pBmgjMk
pVy+Q8Hiyuc8KWqh/GTioHM226UkHPeLbfAAAAIBpoF/G8kf9OzGTq/j1p0eeEK4b39RqDNCJXXbKLJQ
6ZN3XP8bGkXVLHA1YYsFOPIAbds9amvMKG76zFo1dQWyEClEcKlTgvAOWrZWRbzubJT/8L5KUrWMDODB
zkRq8KfUNwd6rqV9gPngN6ulDwaIWqU6pgiV2vygpBMeprbl7kg== user_machin

Comme indiqué dans le manuel, le champ user_machin est un champ de commentaire libre autorisé par sshd qui permet de placer un élément d'identification permettant de savoir à qui appartient la clé publique, ce qui est utile si elles sont nombreuses dans le fichier.

Il ne faut pas omettre les apostrophes autour du nom de la commande.

Dans le cas où vos utilisateurs s'identifient par mot de passe

C'est à priori une méthode à proscrire sur un serveur en production relié à Internet (voir ici). Mais on peut simuler un comportement semblable à celui de la configuration précédente en procédant comme suit.

ATTENTION : Cela reste du bricolage et vous ne devriez en aucun cas l'utiliser en production ! Vous êtes prévenus...

Vous créez un compte user_ssh sur la machine pour donner un accès ssh à vos utilisateurs sur la machine. Pour que ce compte ne donne accès qu'à une commande particulière il faut fournir comme shell à l'utilisateur créé un fichier qui contiendra la commande en question. On utilise l'option --shell de l'utilitaire de création de comptes adduser en lui communicant par exemple la valeur suivante : /home/user_ssh/.lance_commande de manière à obtenir la ligne suivante dans /etc/passwd :

user_ssh:x:1003:1002:,,,:/home/user_ssh:/home/user_ssh/.lance_commande

Puis vous créez le fichier /home/user_ssh/.lance_commande qui contiendra simplement :

#!/bin/bash
/chemin/de/la/commande

Lorsque le client essaye de se connecter via SSH il est redirigé sur le fichier .lance_commande et ne peut exécuter que cette commande.

Écrire un commentaire

Quelle est la troisième lettre du mot xnke ?

Fil RSS des commentaires de cet article

À propos

Yakati.com - Réseau - Web - GNU/Linux © 2017

Généré par PluXml en 0.029s  Compression GZIP activée - Administration

Mes coordonnées

Marc Guillaume
contact[at]yakati.com
79150 ÉTUSSON

Crédits

Pour la gestion du contenu

Généré par PluXml, le Blog ou Cms sans base de données

Pour le contenu

Licence Creative Commons
Ce(tte) œuvre est mise à disposition selon les termes de la Licence Creative Commons Attribution - Pas d’Utilisation Commerciale - Partage dans les Mêmes Conditions 4.0 International.

Pour le thème

Thème SOLID de blacktie.co adapté pour PluXml