SSH est un outil tr\u00e8s polyvalent. Dans certains cas, presque trop !
\nOui je sais je suis provocateur. Je vous explique : il y a peu, j’ai voulu fournir une connexion \u00ab\u00a0tunnelis\u00e9e\u00a0\u00bb \u00e0 un coll\u00e8gue pour raisons professionnelles. Pour \u00e7a, comme vous le savez peut \u00eatre, SSH et sa fonction de tunneling est id\u00e9al.
\nJe ne vais pas expliquer comment faire du SSH tunneling, Internet est d\u00e9j\u00e0 rempli d’articles \u00e0 ce sujet.
\nMon probl\u00e8me \u00e0 moi, \u00e9tait de fournir cette fonction de tunnel, et absolument rien d’autre.
\nEn effet, on a tendance \u00e0 l’oublier, mais ouvrir un compte et donner un acc\u00e8s SSH c’est, par d\u00e9faut, donner \u00e9norm\u00e9ment de droits. Lecture sur la plupart des r\u00e9pertoires de la machine et ex\u00e9cution de scripts, en sont deux parmi les plus dangereux. Quand la machine est pr\u00e9vue \u00e0 l’origine en tant que serveur familial et qu’on d\u00e9cide de faire confiance \u00e0 tous ceux qui y ont acc\u00e8s, le pr\u00eat d’une partie de cette machine \u00e0 un ext\u00e9rieur prend des allures de jeu dangereux et oblige \u00e0 revoir en profondeur la gestion des comptes.<\/p>\n
En mode fain\u00e9ant, au plus simple, j’ai cherch\u00e9 \u00e0 atteindre mon but de limitation drastique des droits. Plusieurs \u00e9tapes sont n\u00e9cessaires :<\/p>\n
– Cr\u00e9ation d’un compte<\/p>\n
sudo adduser invite<\/pre>\nPour ma part, j’ai mis un mot de passe super compliqu\u00e9 que je me suis empress\u00e9 d’oublier. Je pr\u00e9f\u00e8re en effet la gestion par clef priv\u00e9\/publique, qui permet une bien meilleure granularit\u00e9.<\/p>\n
– Connexion avec le nouvel utilisateur, puis cr\u00e9ation d’une clef et copie de sa partie publique dans le magasin des clefs de confiance<\/p>\n
sudo su - invite\nssh-keygen\ncat ~\/.ssh\/id_rsa.pub >> ~\/.ssh\/authorized_keys<\/pre>\nLa clef priv\u00e9e qui a \u00e9t\u00e9 g\u00e9n\u00e9r\u00e9e (id_rsa sans extension) au cot\u00e9 de la clef publique sera celle qu’il faudra fournir \u00e0 votre invit\u00e9 pour qu’il se connecte.<\/p>\n
– Cr\u00e9ation d’un script tr\u00e8s limit\u00e9 faisant office de shell. Par d\u00e9faut, une connexion SSH ex\u00e9cute un shell (celui d\u00e9fini dans le fichier \/etc\/passwd pour l’utilisateur), et c’est ce shell qui est charg\u00e9 de communiquer gr\u00e2ce \u00e0 ses entr\u00e9es\/sorties standard avec l’utilisateur distant. Un shell standard (bash, sh) permet beaucoup trop de chose. Un shell limit\u00e9 \u00e0 sa plus simple expression est ce qu’il nous faut. Et si on le codait nous m\u00eame? En voil\u00e0 le contenu :<\/p>\n
#!\/bin\/sh\n\/bin\/echo \"Bienvenue.\nAcces invite restreint, pas de shell !\nq pour quitter\"\nread ans\nwhile [ \"$ans\" != \"q\" ]\ndo\n\/bin\/echo \"q (pour quitter) est la seule touche valide\"\nread ans\ndone\nexit 0<\/pre>\nQue fait-il ? Rien, \u00e0 part attendre la frappe de la lettre \u00ab\u00a0q\u00a0\u00bb qui mettra fin \u00e0 la connexion. Difficile de faire plus simple.
\nPlacer ce fichier dans un coin de votre disque, en n’oubliant pas de le rendre ex\u00e9cutable \u00e0 coup de chmod +x <\/em><\/p>\n– Arriv\u00e9 ici, je connais bon nombre de linuxiens qui s’empresserait d’aller coller le chemin du script dans la ligne de \/etc\/passwd correspondant \u00e0 l’utilisateur invit\u00e9. Grave erreur. Si en effet, l’utilisateur se retrouverait alors par d\u00e9faut connect\u00e9 \u00e0 notre nouveau \u00ab\u00a0shell\u00a0\u00bb, ceci ne serait que par d\u00e9faut<\/strong>. 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\u00e9e. C’est tout simple, il suffit de rajouter juste avant la clef dans authorized_keys<\/em> un param\u00e8tre for\u00e7ant la commande ex\u00e9cut\u00e9e \u00e0 la connexion de l’utilisateur. Ce qui nous donne par exemple :<\/p>\n
command=\"\/home\/invite\/login.sh\" ssh-rsa AAAAB3NT[...]B68w== invite@spammeur.net<\/pre>\n– Que nous reste-il \u00e0 faire? Arriv\u00e9 ici, l’utilisateur ne peut plus se connecter autrement qu’avec notre shell bidon, mais peut tout \u00e0 fait ex\u00e9cuter 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\u00e8s SFTP, l’invit\u00e9 est capable d’aller modifier le fichier authorized_keys de son compte pour retirer la restriction de scripts… R\u00e9duisant \u00e0 n\u00e9ant nos efforts pour le limiter ! On pourrait prot\u00e9ger ce fichier par root, et coupler ensuite la protection avec un chrootage \u00ab\u00a0des familles\u00a0\u00bb pour emp\u00eacher de surcro\u00eet l’indiscret de fouiller le disque, mais faisons au plus simple.
\nOn \u00e9dite \/etc\/ssh\/sshd_config et on commente comme ceci la ligne suivante :<\/p>\n#Subsystem sftp \/usr\/lib\/openssh\/sftp-server<\/pre>\nNB : pour une raison inconnue, chez moi commenter cette ligne n’a pas suffit. Qu’\u00e0 cela ne tienne, aux grands maux les grands rem\u00e8des :<\/p>\n
sudo mv \/usr\/lib\/openssh\/sftp-server \/usr\/lib\/openssh\/sftp-serverNO<\/pre>\n– On n’oublie pas de recharger sshd avec les nouveaux param\u00e8tres :
\n\/etc\/init.d\/sshd reload<\/p>\n– Derni\u00e8re chose pour les petits distraits : n’oubliez pas de configurer votre serveur FTP pour emp\u00eacher l’acc\u00e8s de l’utilisateur \u00ab\u00a0invite\u00a0\u00bb. De m\u00eame avec tous les services que vous poss\u00e9dez et qui peuvent se baser sur l’authentification syst\u00e8me.<\/p>\n
Pfioui, la s\u00e9curit\u00e9, \u00e7a n’est pas une mince affaire.<\/p>\n","protected":false},"excerpt":{"rendered":"
SSH est un outil tr\u00e8s 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 \u00ab\u00a0tunnelis\u00e9e\u00a0\u00bb \u00e0 un coll\u00e8gue pour raisons professionnelles. Pour \u00e7a, comme vous le savez peut \u00eatre, SSH et sa fonction de tunneling est id\u00e9al. Je […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":[],"categories":[8],"tags":[40,44,50],"_links":{"self":[{"href":"https:\/\/mmed.roulleau.net\/index.php?rest_route=\/wp\/v2\/posts\/160"}],"collection":[{"href":"https:\/\/mmed.roulleau.net\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/mmed.roulleau.net\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/mmed.roulleau.net\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/mmed.roulleau.net\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=160"}],"version-history":[{"count":0,"href":"https:\/\/mmed.roulleau.net\/index.php?rest_route=\/wp\/v2\/posts\/160\/revisions"}],"wp:attachment":[{"href":"https:\/\/mmed.roulleau.net\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=160"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/mmed.roulleau.net\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=160"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/mmed.roulleau.net\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=160"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}