SSH est un outil très polyvalent. Dans certains cas, presque trop !
Oui je sais je suis provocateur. Je vous explique : il y a peu, j’ai voulu fournir une connexion « tunnelisée » à un collègue pour raisons professionnelles. Pour ça, comme vous le savez peut être, SSH et sa fonction de tunneling est idéal.
Je ne vais pas expliquer comment faire du SSH tunneling, Internet est déjà rempli d’articles à ce sujet.
Mon problème à moi, était de fournir cette fonction de tunnel, et absolument rien d’autre.
En effet, on a tendance à l’oublier, mais ouvrir un compte et donner un accès SSH c’est, par défaut, donner énormément de droits. Lecture sur la plupart des répertoires de la machine et exécution de scripts, en sont deux parmi les plus dangereux. Quand la machine est prévue à l’origine en tant que serveur familial et qu’on décide de faire confiance à tous ceux qui y ont accès, le prêt d’une partie de cette machine à un extérieur prend des allures de jeu dangereux et oblige à revoir en profondeur la gestion des comptes.

En mode fainéant, au plus simple, j’ai cherché à atteindre mon but de limitation drastique des droits. Plusieurs étapes sont nécessaires :

– Création d’un compte

sudo adduser invite

Pour ma part, j’ai mis un mot de passe super compliqué que je me suis empressé d’oublier. Je préfère en effet la gestion par clef privé/publique, qui permet une bien meilleure granularité.

– Connexion avec le nouvel utilisateur, puis création d’une clef et copie de sa partie publique dans le magasin des clefs de confiance

sudo su - invite
ssh-keygen
cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys

La clef privée qui a été générée (id_rsa sans extension) au coté de la clef publique sera celle qu’il faudra fournir à votre invité pour qu’il se connecte.

– Création d’un script très limité faisant office de shell. Par défaut, une connexion SSH exécute un shell (celui défini dans le fichier /etc/passwd pour l’utilisateur), et c’est ce shell qui est chargé de communiquer grâce à ses entrées/sorties standard avec l’utilisateur distant. Un shell standard (bash, sh) permet beaucoup trop de chose. Un shell limité à sa plus simple expression est ce qu’il nous faut. Et si on le codait nous même? En voilà le contenu :

#!/bin/sh
/bin/echo "Bienvenue.
Acces invite restreint, pas de shell !
q pour quitter"
read ans
while [ "$ans" != "q" ]
do
/bin/echo "q (pour quitter) est la seule touche valide"
read ans
done
exit 0

Que fait-il ? Rien, à part attendre la frappe de la lettre « q » qui mettra fin à la connexion. Difficile de faire plus simple.
Placer ce fichier dans un coin de votre disque, en n’oubliant pas de le rendre exécutable à coup de chmod +x

– Arrivé ici, je connais bon nombre de linuxiens qui s’empresserait d’aller coller le chemin du script dans la ligne de /etc/passwd correspondant à l’utilisateur invité. Grave erreur. Si en effet, l’utilisateur se retrouverait alors par défaut connecté à notre nouveau « shell », ceci ne serait que par défaut. Une simple option de la ligne de commande du SSH client permet de choisir le shell de son choix. La solution est d’utiliser les restrictions permises par l’utilisation d’une authentification par clef privée. C’est tout simple, il suffit de rajouter juste avant la clef dans authorized_keys un paramètre forçant la commande exécutée à la connexion de l’utilisateur. Ce qui nous donne par exemple :

command="/home/invite/login.sh" ssh-rsa AAAAB3NT[...]B68w== invite@spammeur.net

– Que nous reste-il à faire? Arrivé ici, l’utilisateur ne peut plus se connecter autrement qu’avec notre shell bidon, mais peut tout à fait exécuter des tunnels, comme nous le souhaitons. Cependant, SSH est vicieux et fourni encore d’autres services. Je pense en particulier au SFTP. Avec un accès SFTP, l’invité est capable d’aller modifier le fichier authorized_keys de son compte pour retirer la restriction de scripts… Réduisant à néant nos efforts pour le limiter ! On pourrait protéger ce fichier par root, et coupler ensuite la protection avec un chrootage « des familles » pour empêcher de surcroît l’indiscret de fouiller le disque, mais faisons au plus simple.
On édite /etc/ssh/sshd_config et on commente comme ceci la ligne suivante :

#Subsystem sftp /usr/lib/openssh/sftp-server

NB : pour une raison inconnue, chez moi commenter cette ligne n’a pas suffit. Qu’à cela ne tienne, aux grands maux les grands remèdes :

sudo mv /usr/lib/openssh/sftp-server /usr/lib/openssh/sftp-serverNO

– On n’oublie pas de recharger sshd avec les nouveaux paramètres :
/etc/init.d/sshd reload

– Dernière chose pour les petits distraits : n’oubliez pas de configurer votre serveur FTP pour empêcher l’accès de l’utilisateur « invite ». De même avec tous les services que vous possédez et qui peuvent se baser sur l’authentification système.

Pfioui, la sécurité, ça n’est pas une mince affaire.