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

97

Je voudrais permettre à un utilisateur de configurer un tunnel SSH vers une machine particulière sur un port particulier (par exemple, 5000), mais je veux restreindre 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 / allowed_keys pertinent, mais je ne sais pas exactement quel contenu y mettre (autre que la clé publique).

unix  ssh 
— Lorin Hochstein
source

Réponses:

91

Sur Ubuntu 11.10, j'ai découvert que je pouvais bloquer les commandes ssh, envoyées avec et sans -T, et bloquer la copie scp, tout en autorisant le transfert de port.

Plus précisément, j'ai un serveur redis sur "somehost" lié à localhost: 6379 que je souhaite partager en toute sécurité via des tunnels ssh avec d'autres hôtes qui ont un fichier de clés et qui seront ssh avec:

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

Cela fera apparaître localement le serveur redis, le port "localhost" 6379 sur "somehost" sur l'hôte exécutant la commande ssh, remappé sur le port "localhost" 16379.

Sur la télécommande "somehost" Voici ce que j'ai utilisé pour authorised_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 no-pty déclenche la plupart des tentatives ssh qui veulent ouvrir un terminal.

Le permitopen explique quels ports sont autorisés à être transférés, dans ce cas le port 6379 est le port redis-server que je voulais transférer.

La commande = "/ bin / echo do-not-send-commands" fait écho à "do-not-send-commands" si quelqu'un ou quelque chose parvient à envoyer des commandes à l'hôte via ssh -T ou autrement.

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

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

Les tentatives d'utilisation de la copie sécurisée de fichiers scp échoueront également avec un écho de "do-not-send-commands". J'ai trouvé que sftp échoue également avec cette configuration.

Je pense que la suggestion de shell restreint, faite dans certaines réponses précédentes, est également une bonne idée. De plus, je conviens que tout ce qui est détaillé ici pourrait être déterminé en lisant "man sshd" et en y recherchant "authorized_keys"

— Paul
source
1
Bien no-ptyqu'il ne permette pas d'ouvrir la fenêtre interactive, cela ne fait rien pour empêcher l'exécution de la commande, de sorte que l'utilisateur peut modifier le authorized_keysfichier s'il a accès avec quelque chose comme ssh server 'sed -i -e s/no-pty// ~/.ssh/authorized_keys'.
— synapse
4
@synapse command = "/ bin / echo do-not-send-commands", également répertorié ci-dessus, est destiné à bloquer les commandes. et fournissez un message. Aviez-vous l'intention que votre exemple vienne à l'encontre de tous les paramètres ci-dessus ou ne commentez-vous que no-pty?
— Paul
Il convient de mentionner que les administrateurs ne sont pas obligés d'accorder aux utilisateurs la propriété d'un fichier autorisé_keys ou d'un répertoire contenant, ni qu'il existe même dans le répertoire personnel d'un utilisateur (en supposant que le serveur ssh est configuré correctement pour son emplacement)
— Daniel Farrell
?? @DanFarrell les .ssh / allowed_keys appartiendraient-ils à root, ou wheel, ou à qui?
— Andrew Wolfe
@AndrewWolfe généralement, ~user/.ssh/authorized_keysserait propriétaire useret usergérerait les clés autorisées utilisées pour accéder au compte. SSH est pointilleux sur les autorisations et peut imposer des attentes ~/.ssh/et son contenu. J'ai fait un sudo chown root: .ssh/authorized_keyset il semble m'avoir empêché de me connecter, mais je sais par expérience passée que l'utilisateur n'a pas à posséder ce fichier - rootpeut le gérer si vous préférez.
— Daniel Farrell
18

Vous voudrez probablement définir le shell de l'utilisateur sur le shell restreint . Désinitialisez la variable PATH dans le ~ / .bashrc ou le ~ / .bash_profile de l'utilisateur, et ils ne pourront exécuter aucune commande. Plus tard, si vous décidez que vous souhaitez autoriser le ou les utilisateurs à exécuter un ensemble limité de commandes, comme lessou tailpar exemple, vous pouvez copier les commandes autorisées dans un répertoire séparé (tel que /home/restricted-commands) et mettre à jour le PATH pour qu'il pointe vers ce répertoire.

— Jason Day
source
1
Mais cela n'empêche pas l'utilisateur de spécifier une commande différente sur la ligne de commande ssh, comme ssh use@host "/bin/bash", n'est-ce pas?
— Fritz
Oui, c'est le cas, en supposant que user@hostrbash est le shell. Voir The Restricted Shell
— Jason Day
D'accord, je l'ai essayé et vous avez raison. La commande spécifiée étant exécutée par le shell de connexion, son exécution /bin/bashéchoue car elle contient des barres obliques.
— Fritz
3
Bien qu'il faille dire que permettre lessest probablement une mauvaise idée, car à partir de là, vous pouvez échapper à un shell sans restriction avec !/bin/bash. Voir pen-testing.sans.org/blog/2012/06/06/… pour d'autres exemples. Donc, autoriser des commandes individuelles devrait être fait très, très soigneusement, voire pas du tout.
— Fritz
17

En plus de l'option authorized_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.

— Marbu
source
13
Vous devrez également spécifier "no-pty" dans le cadre de l'ensemble d'options. Si vous n'utilisez que "permitopen", alors vous restreindrez les tunnels à l'hôte / port donné ... mais vous autoriserez toujours les shells interactifs.
— John Hart
La restriction de la redirection de port avec permitopen verrouille-t-elle également le type de transfert de périphérique tunnel que ssh -w demande?
— flabdablet
5
@JohnHart: no-ptyne restreint pas non plus l'accès au shell, vous aurez toujours accès au shell, il ne vous montrera tout simplement pas l'invite; Vous pouvez toujours donner des commandes et voir la sortie très bien. Vous avez besoin de l' command="..."option si vous souhaitez restreindre l'accès au shell à partir de .ssh/authorized_keys.
— Aleksi Torhamo
9

Ma solution est de fournir à l'utilisateur qui peut uniquement effectuer un tunneling, sans shell interactif , pour 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 .

#!/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

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

— Daniel W.
source
9
CTRL + Z échappera au script, vous donnant un accès complet à bash ... Essayez d'ajouter "trap '' 20" (sans guillemets) au tout début du script
— Big Papoo
1
merci pour l'indice, j'ai ajouté le piégeage de certains signaux d'interruption
— Daniel W.
1
J'utilise juste / bin / cat pour un "shell". Semble bien fonctionner. Je n'ai pas connaissance d'exploits contre cat, et même si vous trouviez un modèle d'entrée qui réussit à le planter, votre session ssh se terminerait simplement.
— flabdablet
4
@BigPapoo: L'avez-vous réellement testé? Je ne vois pas où ça s'échapperait. Si vous êtes dans un shell et que vous exécutez tunnel_shell, vous devrez shell -> /bin/bash tunnel_shellbien sûr vous échapper de nouveau vers le shell, mais si vous avez défini tunnel_shell comme shell de l'utilisateur, vous n'aurez que l' /bin/bash tunnel_shellexécution, sans shell vers lequel échapper , d'aussi loin que je puisse voir. Je l'ai testé et je n'ai pas pu m'échapper avec ctrl-z. Si vous avez fait l' essayer et pourrait échapper, pourriez - vous poster la configuration? De même, si vous connaissez une documentation indiquant que cela devrait fonctionner comme ça, pourriez-vous la publier?
— Aleksi Torhamo du
3

Je suis en mesure de configurer le fichier allowed_keys avec la clé publique pour me connecter. Ce dont je ne suis pas sûr, ce sont les informations supplémentaires dont j'ai besoin pour restreindre ce 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
— Zoredache
source
3

Voici un joli article que j'ai trouvé utile: http://www.ab-weblog.com/en/creating-a-restricted-ssh-user-for-ssh-tunneling-only/

L'idée est: (avec le nouveau nom d'utilisateur restreint "sshtunnel")

useradd sshtunnel -m -d /home/sshtunnel -s /bin/rbash
passwd sshtunnel

Notez que nous utilisons rbash (restricted-bash) pour restreindre ce que l'utilisateur peut faire: l'utilisateur ne peut pas cd (changer de répertoire) et ne peut pas définir de variables d'environnement.

Ensuite, nous éditons la variable d'environnement PATH de l'utilisateur en /home/sshtunnel/.profilerien - une astuce qui empêchera bash de trouver des commandes à exécuter:

PATH=""

Enfin, nous interdisons à l'utilisateur de modifier les fichiers en définissant les autorisations suivantes:

chmod 555 /home/sshtunnel/
cd /home/sshtunnel/
chmod 444 .bash_logout .bashrc .profile
— juanmf
source
0

J'ai fait un programme C qui ressemble à ceci:

#include <stdio.h>
#include <unistd.h>
#include <signal.h>
#include <stdlib.h>
void sig_handler(int signo)
{
    if (signo == SIGHUP)
        exit(0);
}

int main()
{
    signal(SIGINT, &sig_handler);
    signal(SIGTSTP, &sig_handler);

    printf("OK\n");
    while(1)
        sleep(1);
    exit(0);
}

J'ai défini le shell de l'utilisateur restreint sur ce programme.

Je ne pense pas que l'utilisateur restreint puisse exécuter quoi que ce soit, même s'il le fait ssh server command, car les commandes sont exécutées à l'aide du shell, et ce shell n'exécute rien.

— fangfufu
source
-3

Vous allez générer une clé sur la machine des utilisateurs via le client ssh qu'ils utilisent. pUTTY par exemple a un utilitaire pour faire exactement cette chose. Il générera à la fois une clé privée et une clé publique.

Le contenu du fichier de clé publique généré sera placé dans le fichier allowed_keys.

Ensuite, vous devez vous assurer que le client ssh est configuré pour utiliser la clé privée qui a généré la clé publique. C'est assez simple, mais légèrement différent selon le client utilisé.

— cheval pâle
source
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.