Question Comment créer un utilisateur SSH restreint pour le transfert de port?


ændrük suggéré une connexion inverse pour obtenir une connexion SSH facile avec quelqu'un d'autre (pour l'aide à distance). Pour que cela fonctionne, un utilisateur supplémentaire est nécessaire pour accepter la connexion. Cet utilisateur doit pouvoir transférer son port via le serveur (le serveur agit en tant que proxy).

Comment créer un utilisateur restreint qui ne peut rien faire de plus que ce qui est décrit ci-dessus?

Le nouvel utilisateur doit ne pas être capable de:

  • exécuter des commandes shell
  • accéder aux fichiers ou télécharger des fichiers sur le serveur
  • utiliser le serveur comme proxy (par exemple, webproxy)
  • accéder à des services locaux qui, autrement, n'étaient pas accessibles au public en raison d'un pare-feu
  • tuer le serveur

En résumé, comment créer un utilisateur SSH restreint qui peut uniquement se connecter au serveur SSH sans privilèges, afin de pouvoir me connecter via cette connexion avec son ordinateur?


90
2018-06-10 20:04


origine




Réponses:


TL; DR - allez au bas de la réponse, "Appliquer les restrictions"

L'ajout d'un utilisateur restreint se compose de deux parties: 1. Créer l'utilisateur 2. Configuration du démon SSH (sshd)

Configuration de sshd

Le meilleur endroit pour connaître les possibilités de SSH est de lire les pages de manuel correspondantes:

Où le client SSH peut-il effectuer des actions?

Avant de pouvoir restreindre quelque chose, vous devez connaître les fonctionnalités de SSH. Cracher à travers les pages de manuel donne:

  • Exécution des commandes shell
  • Téléchargement de fichier via sftp
  • Redirection de port
    • Le client transmet un port (dé) utilisé au serveur
    • Le serveur transmet son port au client
    • Le serveur transfère un port d'un autre hôte au client (proxy-ish)
  • Transfert X11 (transfert de l'affichage)
  • Transfert d'agent d'authentification
  • Transmission d'un dispositif de tunnel

Du Authentification section de la page de manuel de sshd (8):

Si le client s'authentifie correctement, une boîte de dialogue de préparation   la session est entrée A ce moment, le client peut demander des choses comme    attribuer une pseudo-tty, transférer des connexions X11, transférer TCP   connexions ou transfert de la connexion de l'agent d'authentification au dessus de   canal sécurisé.

Après cela, le client soit demande un shell ou l'exécution d'une commande.   Les côtés entrent alors en mode session. Dans ce mode, chaque côté peut envoyer   données à tout moment, et ces données sont transmises à / depuis le shell ou la commande   du côté serveur et du terminal utilisateur du côté client.

Options de restriction des fonctionnalités SSH

Les fichiers et leurs options qui modifient le comportement sont les suivants:

  • ~/.ssh/authorized_keys - contient des clés qui sont autorisées à se connecter et qui peuvent avoir des options:
    • command="command" - La commande fournie par l'utilisateur (le cas échéant) est ignorée. Notez que le client peut spécifier le transfert TCP et / ou X11 à moins qu'ils ne soient explicitement interdits. Notez que cette option s'applique à l'exécution du shell, de la commande ou du sous-système.
    • no-agent-forwarding - Interdit le transfert de l'agent d'authentification lorsque cette clé est utilisée pour l'authentification.
    • no-port-forwarding - Interdit le transfert TCP lorsque cette clé est utilisée pour l'authentification
    • no-X11-forwarding - "Interdit le transfert X11 lorsque cette clé est utilisée pour l'authentification."
    • permitopen="host:port" - Limitez le transfert de port local 'ssh -L' afin qu'il ne puisse se connecter qu'à l'hôte et au port spécifiés.
  • ~/.ssh/environment - Ce fichier est lu dans l'environnement lors de la connexion (s'il existe). Le traitement de l'environnement est désactivé par défaut et est contrôlé via l'option PermitUserEnvironment
  • ~/.ssh/rc - Contient des routines d'initialisation à exécuter avant que le répertoire de base de l'utilisateur ne devienne accessible.
  • /etc/ssh/sshd_config - le fichier de configuration système
    • AllowAgentForwarding - Spécifie si le transfert ssh-agent (1) est autorisé.
    • AllowTcpForwarding
    • ForceCommand - "Force l'exécution de la commande spécifiée par ForceCommand, en ignorant toute commande fournie par le client et ~ / .ssh / rc si présente. La commande est appelée en utilisant le shell de connexion de l'utilisateur avec l'option -c."
    • GatewayPorts - "Spécifie si les hôtes distants sont autorisés à se connecter aux ports transférés pour le client. Par défaut, sshd (8) lie les redirections de ports distants à l'adresse de bouclage. Cela empêche les autres hôtes distants de se connecter aux ports transférés. que sshd devrait permettre aux redirections de ports distants de se lier aux adresses sans bouclage, permettant ainsi à d'autres hôtes de se connecter. "
    • PermitOpen:

Spécifie les destinations vers lesquelles le transfert de port TCP est   permis. La spécification de transfert doit être l'une des   formes suivantes:

PermitOpen host:port
PermitOpen IPv4_addr:port
PermitOpen [IPv6_addr]:port

Plusieurs avances peuvent être spécifiées en les séparant par   espace blanc Un argument de 'any' peut être utilisé pour supprimer tout   restrictions et permettre toute demande de transfert. Par défaut tous   Les demandes de transfert de port sont autorisées.


142
2018-06-22 09:11



Pour que cela fonctionne, le compte ajouté par useradd doit être débloqué. Cela peut être fait en remplaçant le mot de passe dans /etc/shadow par un astérique (*) ou en définissant un mot de passe en utilisant sudo passwd limited-user. - Lekensteyn
SFTP fonctionne parce que le serveur SSH exécute le sftp-server commander. Avec ForceCommand, cette commande ne sera plus exécutée. - Lekensteyn
Aussi utile est le from= option dans authorized_keys. Il vous permet de limiter l'utilisation de la clé aux sources ayant une adresse IP ou un nom d'hôte particulier. Exemple, from="1.1.1.1" ou from="10.0.0.?,*.example.com". Voir la section "AUTHORIZED_KEYS FILE FORMAT" dans la page de manuel (linux.die.net/man/8/sshd) pour toutes les options authorized_keys. - Donn Lee
"AllowTcpForwarding local" interdit le transfert à distance. (Je ne sais pas si cela existait quand cette réponse a été écrite.) - Simon Sapin
Notez que ceci est cassé par des connexions ssh persistantes, donc vous ne devriez pas avoir quelque chose comme Host * ControlMaster auto dans ton ~/.ssh/config fichier lors de la connexion avec ssh -N. Si vous en avez besoin, utilisez ssh -N -o ControlMaster=no - nh2


Je suis sûr qu'il y a beaucoup de solutions à cela, et beaucoup plus robustes que celle que je propose. Cependant, cela peut suffire à vos besoins. Pour ce faire, je suppose que l'utilisateur est capable de faire une authentification basée sur la clé ssh (putty ou n'importe quel ssh unix devrait le supporter).

  • Ajoutez un utilisateur comme vous le feriez normalement ("adduser" ou tout autre outil)

  • Créez les utilisateurs .ssh dir et .ssh / authorized_keys

your_user $ sudo -Hu ssh_forwarder /bin/bash

ssh_forwarder $ cd ~
ssh_forwarder $ mkdir .ssh
ssh_forwarder $ ( umask 066 && cat > .ssh/authorized_keys ) <<EOF
no-agent-forwarding,no-X11-forwarding,command="read a; exit" ssh-rsa AAAB3NzaC1y....2cD/VN3NtHw== smoser@brickies
EOF
  • Désactiver l'accès par mot de passe à ce compte.
your_user $ sudo usermod --lock ssh_forwarder

Maintenant, la seule façon pour l'utilisateur d'accéder à votre système est d'accéder à la clé ssh appropriée, et ssh exécutera "/ bin / bash -c 'read a'" pour eux, peu importe ce qu'ils tentent d'exécuter. 'read a' lira simplement jusqu'à une nouvelle ligne, puis le shell quittera, de sorte que l'utilisateur doit simplement appuyer sur "enter" pour tuer la connexion.

Vous pouvez faire beaucoup d'autres choses dans 'command ='. Voir man authorized_keys et recherchez «commande» pour plus d'informations.

Si vous n'aimez pas le fait que frapper enter tue la connexion, vous pouvez utiliser quelque chose comme ceci pour l'entrée "command =":

command="f=./.fifo.$$ && mkfifo $f && trap \"rm -f $f\" EXIT && read a <$f && echo $a; exit;"

Cela crée juste un fifo temporaire dans le répertoire personnel de l'utilisateur, puis essaie de le lire. Rien ne va écrire dans ce fichier, donc cela va rester indéfiniment. De plus, si vous souhaitez mettre fin à cette connexion avec force, vous pouvez faire quelque chose comme:

 your_user$ echo GOODBYE | sudo tee ~ssh_forwarder/.fifo.*

Cela devrait utiliser très peu de ressources, et rien ne devrait aller mal dans ce script qui ne se terminerait pas par la fin du shell.

sleep 1h; echo You have been here too long. Good bye.

Je n'ai pas vu par vous-même comment vous pouviez permettre à l'utilisateur de transférer à distance (ssh -R) mais limite (ssh -L). Peut-être que «allowopen» pourrait être utilisé. Googler n'était pas très utile. Il semblerait que quelque chose comme 'no-port-forwarding, allowremoteopen = 10001' serait utile pour permettre ssh -R 6901:localhost:6901.

C'est une Solution. Il est certain que cela peut être amélioré et que toute ouverture de ports distants doit être examinée. Si mon objectif était de permettre à ma grand-mère de se connecter à mon réseau local afin que je puisse utiliser vnc pour voir son écran, et que l'accès à ces clés se limitait à elle, je me sentirais raisonnablement en sécurité. Si c'était pour une entreprise, une enquête plus approfondie serait nécessaire. Une chose à savoir est ssh -N ne demande pas de shell du tout, le code 'command =' ne s'exécute donc pas.

D'autres mécanismes, peut-être plus sécurisés, peuvent inclure la création d'un shell personnalisé pour l'utilisateur et même le verrouiller avec apparmour.


2
2018-06-21 13:09



Cela semble très piraté, il n'est même pas nécessaire d'avoir un shell car aucune commande ne doit être exécutée. Voir la page de manuel de ssh pour le -N option. Il doit y avoir un moyen plus propre d'y parvenir. - Lekensteyn
C'est vrai. J'espère voir aussi une solution plus propre. Je pense que author_keys en conjonction avec no-port-forwarding serait une très bonne solution s'il y avait une option 'allowremoteopen'. - smoser
J'ai fait de la recherche (voir ci-dessus). Depuis ssh -N ne pas exécuter une commande du tout, ce n'est pas un problème que command="something" ferme la session. - Lekensteyn