cat comme shell pour un user restreint?

J'ai besoin de me connecter à quelques machines pour faire des tâches de maintenance, mais parfois les machines peuvent être derrière des pare-feux ou des NAT.

La façon dont je l'ai fait est de donner à l'user des conseils sur la façon de se connecter à mon système avec SSH afin que le tunnelage inverse soit activé, comme "utiliser la command ssh -R 12345:localhost:22 [email protected] et connectez-vous avec le mot de passe xyzzy ".

Maintenant, cela fonctionne très bien, mais pour des raisons de security, je dois désactiver le login ssh pour l'user uremonte quand je l'ai terminé et n'oubliez pas de le réactiver lorsque j'en ai besoin ou si quelqu'un peut se connecter à mon administration machine frontend non désirée, ou les users légitimes pourraient essayer de jouer pendant que j'utilise le tunnel.

J'ai pensé à placer le shell de l'user dans /etc/passwd dans /bin/cat , afin que quiconque se connecte n'ait aucune chance de faire quoi que ce soit sur le shell et que la connection rest active pour le tunnel inverse. Cela semble être OK, mais je voudrais être sûr que cela ne perce pas de trous dans mon système.

Donc, la question est, est-ce absolument sûr? Y a-t-il un moyen pour que quelqu'un se connecte à ce count pourrait se détacher du piège à chat?

C'est une raison assez standard pour changer la coquille. Typiquement /bin/false ou d'autres coquilles comme /bin/cat sont utilisés.

En général, vous ne pouvez pas vous échapper de /bin/cat et il est peu probable que le cat ait un bug de security, mais d'autres methods peuvent encore fonctionner, comme créer un DoS ou contourner les règles du pare-feu.

Un autre problème probablement plus grave est si vous utilisez le module internal-sftp pour sftp . Cela permettrait aux users avec /bin/cat comme shell d'utiliser sftp pour accéder à votre système de files et parcourir son contenu.

Pour votre cas d'utilisation spécifique, je vous recommand d'utiliser des tunnels ou des vpns au lieu de fournir un access ssh à vos clients.