Auf der Serverseite können Sie dies einschränken, indem Sie deren Benutzer-Shell auf /bin/true setzen . Dadurch können sie sich authentifizieren, aber nichts ausführen, da sie keine Shell zum Ausführen erhalten. Das bedeutet, dass sie auf die Teilmenge von Dingen beschränkt sind, die SSH ihnen bieten kann. Wenn es eine Portweiterleitung anbietet, können sie das trotzdem tun.
Auf der Client-Seite möchten Sie sich wahrscheinlich mit -N verbinden . Dies hält den Client davon ab, nach einem Remote-Befehl wie einer Shell zu FRAGEN, er stoppt einfach, nachdem der Authentifizierungsteil abgeschlossen ist. Danke an die Kommentatoren für den Hinweis.
Folgendes hat den Vorteil, dass auch X11- und SSH-Agent-Socket-Forwardings verboten sind, die in Calebs Art vielleicht noch erlaubt sind. Ein weiterer Vorteil ist, dass, wenn der Benutzer seine Standard-Shell auf andere Weise ändern kann, dies seinen SSH-Zugriff immer noch auf TCP-Weiterleitungen beschränkt.
Geben Sie Folgendes in Ihren /etc/ssh/sshd_config ein :
Match User that-restricted-guy
AllowTcpForwarding yes
X11Forwarding no
AllowAgentForwarding no
ForceCommand /bin/false
um dem Benutzer that-restricted-guy zu erlauben um alle TCP-Verbindungen über Ihren SSH-fähigen Rechner weiterzuleiten (Verbindung zu diesem Rechner, auch zu localhost und sogar Verbindung von dieser Maschine zu anderen Maschinen).
Wenn Sie es noch restriktiver haben möchten (was eine gute Idee ist), können Sie auch Folgendes tun:
Match User even-more-restricted-guy
PermitOpen 127.0.0.1:12345
X11Forwarding no
AllowAgentForwarding no
ForceCommand /bin/false
Dies erlaubt dem Benutzer even-more-restricted-guy Verbindungen immer nur an 127.0.0.1 TCP-Port 12345 weiterzuleiten (wie er durch Ihren SSH-fähigen Rechner sichtbar ist).
Wenn sich der Benutzer normal verbindet, wird er jetzt sofort getrennt, weil der /bin/false wird der Befehl ausgelöst, der nichts anderes tut, als sich sofort mit dem Code 1 zu beenden. Wenn Sie dies vermeiden und Ihre Weiterleitungsverbindung offen halten möchten, fügen Sie den -N hinzu Flag auf ssh Befehl. Dies wird nicht versuchen, irgendeinen Befehl auszuführen, ermöglicht aber dennoch die Einrichtung von TCP-Weiterleitungen.
Ein Beispiel für einen Weiterleitungsbefehl, der im letzteren Setup funktionieren sollte:
ssh -L 12345:127.0.0.1:12345 -N [email protected]
Sie können steuern, was Personen in ssh tun können, indem Sie Gruppen zusammenbringen, vorausgesetzt, Ihre ssh-Version ist neu genug, um sie zu unterstützen (openssh 5.x+).
Grundsätzlich behandeln wir sie so, als ob sie sftp-Benutzer wären, erlauben aber TCP-Weiterleitung und optional Geben Sie die Ziele an, an die sie weiterleiten können. Wenn Sie ihnen ein Home-Verzeichnis geben, aber keine Verzeichnisse darunter erstellen, können sie keine Dateien übertragen, da sie dazu keine Berechtigung haben.
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
Sie können diese Match Group wiederholen Blöcke für jede Gruppe, der Sie unterschiedliche Verhaltensweisen oder Einschränkungen zuweisen möchten.
Mit iptables können Sie weiter kontrollieren, wohin diese Person im Netzwerk gehen darf
/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
Dies setzt voraus, dass die GID der Gruppe "nette Leute" 500 ist.
Einige der oben genannten ssh-Optionen sind in den älteren Versionen von openssh verfügbar, jedoch nicht im Abschnitt Match Group. Match Group ist in OpenSSH 4.x und früher sehr eingeschränkt.