Comment restreindre un utilisateur SSH pour autoriser uniquement la tunnelisation SSH?

Comment puis-je restreindre un utilisateur sur le serveur SSH pour ne lui accorder que les privilèges de SSH TUNNELING ? c'est-à-dire qu'ils ne peuvent pas exécuter de commandes même s'ils se connectent via SSH.

Mes serveurs Linux sont Ubuntu 11.04 et OpenWrt.

linux ssh account-restrictions

— LanceBaynes
source

Réponses:

Côté serveur, vous pouvez limiter cela en définissant leur shell utilisateur sur /bin/true. Cela leur permettra de s'authentifier, mais de ne rien exécuter car ils n'ont pas de shell pour l'exécuter. Cela signifie qu'ils seront limités à tout sous-ensemble de choses que SSH est en mesure de leur offrir. S'il propose une redirection de port, ils pourront toujours le faire.

Côté client, vous voudrez probablement vous connecter avec le -N. Cela empêche le client de DEMANDER une commande à distance telle qu'un shell, il s'arrête juste après que la partie d'authentification soit terminée. _{Merci aux commentateurs de l'avoir signalé.}

— Caleb
source

Je vais essayer celui-ci: P thx!

— LanceBaynes

Pour compléter la réponse de Caleb, vous devrez peut-être également dire au client de ne pas exécuter un shell. Avec la ligne de commande openssh, cela se fait avec l'indicateur -N. Il existe une option similaire dans PuTTY, mais je ne me souviens pas du nom exact.

— Bill B

hmm, c'est essentiellement la sécurité côté client, non? Je recherche un paramètre de sécurité côté serveur, mais merci!

— LanceBaynes

Désolé, je n'étais pas clair - je voulais dire en combinaison avec le paramètre du serveur. D'après mon expérience dans le passé, si vous définissez le shell sur quelque chose qui n'est pas un shell, vous ne pouvez pas vous connecter du tout car il essaie d'ouvrir un shell mais ne le peut pas. La sécurité est donc appliquée côté serveur (en utilisant la méthode de Caleb) mais si vous rencontrez des problèmes de connexion après cela, vous devrez peut-être définir le commutateur côté client.

— Bill B

Vous créez un tel utilisateur avec useradd sshtunnel -m -d /home/sshtunnel -s /bin/true.

— fracz

Ce qui suit présente l'avantage que les redirections de socket d'agent X11 et SSH sont également interdites, ce qui pourrait toujours être autorisé à la manière de Calebs. Un autre avantage est que si l'utilisateur est capable de changer son shell par défaut de toute autre manière, cela limitera toujours son accès SSH aux transferts TCP uniquement.

Mettez ce qui suit dans votre /etc/ssh/sshd_config:

Match User that-restricted-guy
  AllowTcpForwarding yes
  X11Forwarding no
  AllowAgentForwarding no
  ForceCommand /bin/false

pour permettre à l'utilisateur that-restricted-guyde transférer toutes les connexions TCP via votre machine compatible SSH (connexion à cette machine, également localhostet même connexion de cette machine à d'autres machines).

Si vous le souhaitez encore plus restrictif (ce qui est une bonne idée), vous pouvez également effectuer les opérations suivantes:

Match User even-more-restricted-guy
  PermitOpen 127.0.0.1:12345
  X11Forwarding no
  AllowAgentForwarding no
  ForceCommand /bin/false

Cela permettra à l'utilisateur even-more-restricted-guyde ne jamais transférer que les connexions vers le port TCP 127.0.0.1 12345 (comme cela est visible sur votre machine compatible SSH).

Lorsque l'utilisateur se connecte normalement, il sera désormais instantanément déconnecté car la /bin/falsecommande sera déclenchée, ce qui ne fera que sortir instantanément avec un code de 1. Si vous voulez éviter cela et garder votre connexion de transfert ouverte, ajoutez le -Ndrapeau à la sshcommande. Cela n'essaiera pas d'exécuter aucune commande, mais permet tout de même de configurer les transferts TCP.

Un exemple de commande directe qui devrait fonctionner dans cette dernière configuration:

ssh -L 12345:127.0.0.1:12345 -N even-more-restricted-guy@insert-your-machine

— aef
source

J'ai reformulé la réponse comme une solution améliorée par rapport à la réponse de Calebs.

— 2017

Sûr. J'ai aussi nettoyé. C'est bon de voir le malentendu résolu. Bonne nuit.

— Jakuje

Vous pouvez contrôler ce que les gens peuvent faire dans ssh en faisant correspondre les groupes en supposant que votre version de ssh est suffisamment nouvelle pour la prendre en charge (openssh 5.x +).

Fondamentalement, nous les traitons comme s'ils étaient des utilisateurs sftp, mais autorisons le transfert tcp et spécifions éventuellement les destinations vers lesquelles ils peuvent transférer. Si vous leur donnez un répertoire personnel mais que vous ne créez aucun répertoire sous celui-ci, ils ne peuvent transférer aucun fichier car ils ne seront pas autorisés à le faire.

Match Group                     nicepeople
    PubkeyAuthentication        yes
    PasswordAuthentication      yes
    PermitEmptyPasswords        no
    GatewayPorts                no
    ChrootDirectory             /opt/dummy_location/%u
    ForceCommand                internal-sftp
    AllowTcpForwarding          yes
        PermitOpen              192.168.0.8:22
        PermitOpen              192.168.0.5:8080
    # Or leave out the PermitOpen to allow forwarding to anywhere.
    HostbasedAuthentication     no
    RhostsRSAAuthentication     no
    AllowAgentForwarding        no
    Banner                      none

Vous pouvez répéter ces blocs Match Group pour chaque groupe auquel vous souhaitez attribuer un comportement ou des restrictions différents.

Vous pouvez contrôler davantage où cette personne peut aller sur le réseau à l'aide d'iptables

/sbin/iptables -I OUTPUT -m owner --gid-owner 500 -j REJECT
/sbin/iptables -I OUTPUT -m owner --gid-owner 500 -m tcp -p tcp -d 192.168.0.0/24 -j ACCEPT

Cela suppose que le groupe "nicepeople" GID est 500.

Certaines des options ssh ci-dessus sont disponibles dans les anciennes versions de openssh, mais pas dans la section Match Group. Match Group est très limité dans OpenSSH 4.x et versions antérieures.

— Aaron
source