Autoriser l'utilisateur à configurer un tunnel SSH, mais rien d'autre

Question

J'aimerais autoriser un utilisateur à configurer un tunnel SSH vers une machine particulière sur un port particulier (disons 5000), mais je souhaite limiter cet utilisateur autant que possible. (L’authentification se fera avec une paire de clés publique / privée).

Je sais que je dois éditer le fichier ~ / .ssh / registered_keys pertinent, mais je ne sais pas exactement quel contenu y être ajouté (autre que la clé publique).

Answer 1

Sur Ubuntu 11.10, j'ai trouvé que je pouvais le bloc de commandes ssh, envoyé avec et sans l'option-T, et de bloquer scp copie, tout en permettant la redirection de port.

Plus précisément, j'ai un redis-server sur "somehost" lié à localhost:6379 que je souhaite partager en toute sécurité via les tunnels ssh à d'autres hôtes qui ont un keyfile et ssh, avec:

$ ssh -i keyfile.rsa -T -N -L 16379:localhost:6379 someuser@somehost

Ce sera la cause de la redis-le serveur "localhost" port 6379 sur "somehost" apparaissent localement sur l'ordinateur hôte de l'exécution de la commande ssh, réadressé à "localhost" port 16379.

Sur la télécommande "somehost" Voici ce que j'ai utilisé pour authorized_keys:

cat .ssh/authorized_keys   (portions redacted)

no-pty,no-X11-forwarding,permitopen="localhost:6379",command="/bin/echo do-not-send-commands" ssh-rsa rsa-public-key-code-goes-here keyuser@keyhost

Le non-pty voyages plus ssh tentatives qui veulent ouvrir un terminal.

Le permitopen explique quels sont les ports peuvent être transférées, dans ce cas, le port 6379 le redis-server port je voulais avant.

La commande="/bin/echo do-not-send-commandes de" l'écho de retour "do-not-send-commandes" si quelqu'un ou quelque chose ne réussit pas à envoyer des commandes à l'ordinateur hôte via ssh -T ou autrement.

À partir d'un récent Ubuntu man sshd, authorized_keys / commande est décrite comme suit:

command="commande" Spécifie que la commande est exécutée à chaque fois que cette touche est utilisée pour l'authentification. La commande fournie par l'utilisateur (le cas échéant) est ignoré.

Les tentatives d'utilisation de scp sécurisé des fichiers de la copie échoue également avec un écho de "do-not-send-commandes" j'ai trouvé sftp échoue également avec cette configuration.

Je pense que le shell restreint suggestion, faite dans certaines réponses précédentes, est également une bonne idée. Aussi, je suis d'accord que tout détaillé ici pourrait être déterminée à partir de la lecture de "l'homme sshd" et la recherche qui y est pour "authorized_keys"

Answer 2

Vous aurez probablement souhaitez définir le shell de l'utilisateur pour le shell restreint. Unset la variable de CHEMIN d'accès de l'utilisateur ~/.bashrc ou ~/.bash_profile, et ils ne seront pas en mesure d'exécuter toutes les commandes. Plus tard, si vous décidez que vous voulez pour permettre à l'utilisateur(s) à exécuter un ensemble limité de commandes, à l'instar less ou tail , par exemple, vous pouvez copier le permis de commandes à un répertoire séparé (comme /home/restricted-commands) et de mettre à jour le CHEMIN pour pointer vers ce répertoire.

Answer 3

En plus de l'option allowed_keys comme no-X11-forwarding, il y en a exactement une que vous demandez: permitopen = "host: port". En utilisant cette option, l'utilisateur peut uniquement configurer un tunnel vers l'hôte et le port spécifiés.

Pour plus de détails sur le format de fichier AUTHORIZED_KEYS, reportez-vous à man sshd.

Answer 4

Ma solution est de fournir à l'utilisateur qui ne peut être tunneling, sans un shell interactif, jeu de shell dans /etc/passwd pour /usr/bin/tunnel_shell.

Il suffit de créer le fichier exécutable /usr/bin/tunnel_shell avec une boucle infinie.

#!/bin/bash
trap '' 2 20 24
clear
echo -e "\r\n\033[32mSSH tunnel started, shell disabled by the system administrator\r\n"
while [ true ] ; do
sleep 1000
done
exit 0

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

Answer 5

Je suis en mesure de configurer le fichier allowed_keys avec la clé publique pour la connexion. Ce dont je ne suis pas sûr, ce sont les informations supplémentaires dont j'ai besoin pour limiter les tâches que ce compte est autorisé à faire. Par exemple, je sais que je peux mettre des commandes telles que:

 no-pty,no-port-forwarding,no-X11-forwarding,no-agent-forwarding
 

Vous voudriez une ligne dans votre fichier allowed_keys qui ressemble à ceci.

 permitopen="host.domain.tld:443",no-pty,no-agent-forwarding,no-X11-forwardi
ng,command="/bin/noshell.sh" ssh-rsa AAAAB3NzaC.......wCUw== zoredache