Côté serveur, vous pouvez limiter cela en définissant leur shell utilisateur sur /bin/true . Cela leur permettra de s'authentifier, mais pas d'exécuter quoi que ce soit puisqu'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 souhaiterez 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 une fois la partie authentification terminée. Merci aux commentateurs d'avoir signalé cela.
Ce qui suit a l'avantage que les transferts de socket d'agent X11 et SSH sont également interdits, ce qui pourrait toujours être autorisé à la manière de Calebs. Un autre avantage est que si l'utilisateur peut changer son shell par défaut de toute autre manière, cela limitera toujours son accès SSH aux seuls transferts TCP.
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 autoriser l'utilisateur that-restricted-guy pour transférer toutes les connexions TCP via votre machine compatible SSH (connexion à cette machine, également à localhost et même la connexion de cette machine à d'autres machines).
Si vous le souhaitez encore plus restrictif (ce qui est une bonne idée), vous pouvez également procéder comme suit :
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-guy pour transférer uniquement les connexions vers le port TCP 127.0.0.1 12345 (tel qu'il est visible sur votre machine compatible SSH).
Lorsque l'utilisateur se connecte normalement, il sera désormais instantanément déconnecté car le /bin/false La commande sera déclenchée et ne fera rien d'autre que se terminer instantanément avec un code de 1. Si vous voulez éviter cela et garder votre connexion de transfert ouverte, ajoutez le -N drapeau au ssh commande. Cela n'essaiera pas d'exécuter une commande mais permet toujours de configurer les transferts TCP.
Un exemple de commande de transfert qui devrait fonctionner dans cette dernière configuration :
ssh -L 12345:127.0.0.1:12345 -N [email protected]
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 récente pour le prendre en charge (openssh 5.x+).
Fondamentalement, nous les traitons comme s'ils étaient des utilisateurs sftp, mais autorisons le transfert tcp et éventuellement spécifier les destinations vers lesquelles ils peuvent être renvoyés. Si vous leur donnez un répertoire personnel mais que vous ne créez aucun répertoire sous celui-ci, ils ne pourront transférer aucun fichier car ils n'auront pas l'autorisation de 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 Match Group blocs pour chaque groupe auquel vous souhaitez fournir un comportement ou des restrictions différents.
Vous pouvez contrôler davantage où cette personne peut aller sur le réseau en utilisant 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 GID du groupe "nicepeople" est 500.
Certaines des options ssh ci-dessus sont disponibles dans les anciennes versions d'opensh, mais pas dans la section Match Group. Match Group est très limité dans OpenSSH 4.x et versions antérieures.