accès tunnel uniquement ssh

31

Est-il possible de configurer ssh (sous linux) pour autoriser l'accès au tunneling uniquement? Ie utilisateur peut configurer des tunnels mais ne peut pas obtenir un shell / accéder aux fichiers?

linux ssh ssh-tunnel

— Seconde
source

42

Oui, utilisez simplement /bin/falsecomme shell et demandez à l'utilisateur de démarrer le processus de tunneling SSH sans exécuter de commande à distance (c'est-à-dire l' -Nindicateur pour OpenSSH):

ssh -N -L 1234:target-host:5678 ssh-host

— comte
source

Um, si l'utilisateur n'utilise pas -N, il a accès au shell. Cela ne résout vraiment pas le problème et est dangereux.

— mlissner

12

@mlissner: Non, si vous avez un /bin/falseshell, vous n'aurez pas accès au shell, car chaque session de connexion se terminera immédiatement.

— Sven

10

Dans le fichier .ssh / authorized_keys de l'utilisateur, mettez quelque chose comme ceci:

permitopen="192.168.1.10:3306",permitopen="10.0.0.16:80",no-pty ssh-rsa AAAAB3N...

Donc, fondamentalement, vous les contrôles seraient en face de la clé publique ssh de l'utilisateur séparés par un espace. Dans l'exemple, les connexions utilisant la clé publique spécifique seront autorisées à effectuer la redirection de port SSH uniquement vers le serveur MySQL de 192.168.1.10 et le serveur Web de 10.0.0.16, et ne recevront pas de shell (no-pty). Vous posez spécifiquement des questions sur l'option "no-pty", mais les autres peuvent également être utiles si l'utilisateur est uniquement censé tunneler vers des serveurs spécifiques.

Consultez la page de manuel de sshd pour plus d'options pour le fichier authorized_keys .

Notez que l'expérience de l'utilisateur peut sembler un peu étrange: quand ils ssh dedans, il semblera que la session est suspendue (car ils n'obtiennent pas de pty). C'est bon. Si l'utilisateur a spécifié la redirection de port avec, par exemple, "-L3306: 192.168.1.10: 3306", la redirection de port sera toujours en vigueur.

Dans tous les cas, essayez-le.

— cjc
source

6

C'est un conseil dangereux ; no-ptyn'empêche pas l'accès au shell, il ne donne tout simplement pas de pty au shell. Il n'affiche pas l'invite (c'est-à-dire "semble se bloquer"), mais vous pouvez toujours donner des commandes très bien. Vous avez besoin de l' command="..."option .ssh/authorized_keyssi vous souhaitez restreindre l'accès au shell à partir de là.

— Aleksi Torhamo

@AleksiTorhamo a raison, mais c'est un début; vous devez également définir le shell sur / usr / sbin / nologin ou / bin / false dans / etc / passwd pour restreindre complètement le shell. J'ai modifié l'entrée ci-dessus pour refléter cela, ainsi que les conseils d'Aleksi.

— Jamieson Becker

4

Donnez à l'utilisateur un shell qui ne lui permet que de se déconnecter, comme /bin/press_to_exit.sh

#! / bin / bash
read -n 1 -p "Appuyez sur n'importe quelle touche pour quitter"

De cette façon, il peut rester connecté aussi longtemps qu'il le souhaite, avec des tunnels actifs, mais n'exécuter aucune commande. Ctrl-cferme la connexion.

— Fée Clochette
source

3

Je pense qu'au moins en théorie, l'utilisateur pourra frapper CTRL + C au bon moment (entre les lignes 1 et 2) et se retrouver avec un shell bash complet.

— andreas-h

2

Attribuez un shell qui ne permet pas à l'utilisateur de se connecter.

par exemple

#!/bin/sh
echo "No interactive login available."
sleep 60
exit 0

les empêcherait d'obtenir une invite du shell et leur donnerait un délai d'expiration de 60 secondes - s'il n'y a pas de connexion active pendant 60 secondes, il se fermerait et les déconnecterait ainsi complètement (augmentez le nombre en fonction des besoins).

Ils ne peuvent pas non plus exécuter une commande à distance, car ce shell ne les autorisera pas.

— jrg
source

4

La plupart des installations Linux proposent déjà quelque chose pour cela. / sbin / nologin ou / bin / false ou similaire.

— Rory

1

Que ferait Ctrl-C dans l'exemple ci-dessus?

— Arjan

Arjan: Puisque le script est utilisé comme shell, Ctrl-C aurait le même effet que " logout" sur un script normal.

— grawity

2

J'aime vraiment la réponse d'Earl, avec l'option "-N", mais si vous voulez donner à votre utilisateur un message utile, convivial et informatif - et l'empêcher de laisser des connexions SSH partout - alors un script personnalisé est agréable et clair à propos de ce qu'il fait.

— jrg

2

@jrg Cette discussion est ancienne et vous avez peut-être changé d'avis :) mais à mon humble avis, il est dangereux de sortir des scripts shell faits à la main. Il y en a déjà /sbin/nologin, que vous pouvez personnaliser avec un message convivial dans /etc/nologin.txt.

— dr01

0

Ma solution est de fournir à l'utilisateur qui ne peut tunneler, sans shell interactif , de définir ce shell dans / etc / passwd sur / usr / bin / tunnel_shell .

Créez simplement le fichier exécutable / usr / bin / tunnel_shell avec une boucle infinie .

Utilisez également l' option AllowGroupset Match Group.

Entièrement expliqué ici: http://blog.flowl.info/2011/ssh-tunnel-group-only-and-no-shell-please/

— Daniel W.
source

2

L'utilisateur peut être en mesure de quitter l'exécutable d'une manière ou d'une autre et d'échapper à un shell. Êtes-vous parfaitement convaincu que votre exécutable ne permettra pas de faire cela?

— dr01

2

@ dr01 Pour être honnête, je ne suis pas sûr que ce soit 100% sécurisé. Je suppose que lorsque vous quittez l'exécutable, la session SSH est également fermée. Je ferai des recherches plus approfondies à ce sujet et je pourrais commenter ici.

— Daniel W.