it-swarm.com.de

Wie erstelle ich einen eingeschränkten SSH-Benutzer für die Portweiterleitung?

ændrük schlug eine umgekehrte Verbindung vor um eine einfache SSH-Verbindung mit jemand anderem herzustellen (für Remote-Hilfe). Damit dies funktioniert, ist ein zusätzlicher Benutzer erforderlich, um die Verbindung zu akzeptieren. Dieser Benutzer muss in der Lage sein, seinen Port über den Server weiterzuleiten (der Server fungiert als Proxy).

Wie erstelle ich einen eingeschränkten Benutzer, der nicht mehr als die oben beschriebenen Aktionen ausführen kann?

Der neue Benutzer darf nicht in der Lage sein:

  • shell-Befehle ausführen
  • auf Dateien zugreifen oder Dateien auf den Server hochladen
  • verwenden Sie den Server als Proxy (z. B. Webproxy)
  • zugriff auf lokale Dienste, die ansonsten aufgrund einer Firewall nicht öffentlich zugänglich waren
  • töte den Server

Zusammengefasst, wie erstelle ich einen eingeschränkten SSH-Benutzer, der nur ohne Berechtigungen eine Verbindung zum SSH-Server herstellen kann, damit ich über diese Verbindung eine Verbindung mit seinem Computer herstellen kann?

105
Lekensteyn

TL; DR - gehe zum Ende der Antwort "Anwenden der Einschränkungen"

Das Hinzufügen eines eingeschränkten Benutzers besteht aus zwei Teilen: 1. Erstellen des Benutzers 2. Konfigurieren des SSH-Dämons (sshd)

Sshd konfigurieren

Der beste Ort, um sich mit den Möglichkeiten von SSH vertraut zu machen, ist das Lesen der entsprechenden Handbuchseiten:

Wo kann der SSH-Client Aktionen ausführen?

Bevor Sie etwas einschränken können, müssen Sie die Funktionen von SSH kennen. Das Durchblättern der Manualseiten ergibt:

  • Ausführung von Shell-Befehlen
  • Datei-Upload über SFTP
  • Port-Weiterleitung
    • Der Client leitet einen (nicht) genutzten Port an den Server weiter
    • Der Server leitet seinen Port an den Client weiter
    • Der Server leitet einen Port eines anderen Hosts an den Client weiter (Proxy-ish)
  • X11-Weiterleitung (Display-Weiterleitung)
  • Weiterleitung des Authentifizierungsagenten
  • Weiterleitung eines Tunnelgerätes

Aus dem Abschnitt Authentication der Manualpage von sshd (8) :

Wenn der Client sich erfolgreich authentifiziert hat, wird ein Dialogfeld zum Vorbereiten der Sitzung aufgerufen. Zu diesem Zeitpunkt fordert der Client möglicherweise Folgendes an: Zuweisen einer Pseudotty, Weiterleiten von X11-Verbindungen, Weiterleiten von TCP-Verbindungen oder Weiterleiten der Authentifizierungsagentenverbindung über den sicheren Kanal.

Danach fordert der Client entweder eine Shell an oder führt einen Befehl aus. Die Seiten wechseln dann in den Sitzungsmodus. In diesem Modus kann jede Seite jederzeit Daten senden, und diese Daten werden an die Shell oder an den Befehl auf der Serverseite und an das Benutzerterminal auf der Clientseite weitergeleitet.

Optionen zum Einschränken von SSH-Funktionen

Dateien und ihre Optionen, die das Verhalten ändern, sind:

  • ~/.ssh/authorized_keys - enthält Schlüssel, die eine Verbindung herstellen dürfen und denen Optionen zugewiesen werden können:
    • command="command" - Der vom Benutzer eingegebene Befehl (falls vorhanden) wird ignoriert. Beachten Sie, dass der Client die Weiterleitung von TCP und/oder X11 festlegen kann, sofern dies nicht ausdrücklich untersagt ist. Beachten Sie, dass diese Option für die Ausführung von Shell-, Befehls- oder Subsystemen gilt.
    • no-agent-forwarding - Verbietet die Weiterleitung von Authentifizierungsagenten, wenn dieser Schlüssel für die Authentifizierung verwendet wird.
    • no-port-forwarding - Verbietet die Weiterleitung von TCP, wenn dieser Schlüssel für die Authentifizierung verwendet wird
    • no-X11-forwarding - "Verbietet X11-Weiterleitung, wenn dieser Schlüssel zur Authentifizierung verwendet wird."
    • permitopen="Host:port" - Begrenzen Sie die lokale 'ssh-L'-Portweiterleitung so, dass nur eine Verbindung zum angegebenen Host und Port hergestellt werden kann.
  • ~/.ssh/environment - Diese Datei wird bei der Anmeldung in die Umgebung eingelesen (falls vorhanden). Die Umgebungsverarbeitung ist standardmäßig deaktiviert und wird über die Option PermitUserEnvironment gesteuert
  • ~/.ssh/rc - Enthält Initialisierungsroutinen, die ausgeführt werden müssen, bevor auf das Basisverzeichnis des Benutzers zugegriffen werden kann.
  • /etc/ssh/sshd_config - die systemweite Konfigurationsdatei
    • AllowAgentForwarding - Gibt an, ob die Weiterleitung von ssh-agent (1) zulässig ist.
    • AllowTcpForwarding
    • ForceCommand - "Erzwingt die Ausführung des von ForceCommand angegebenen Befehls, wobei alle vom Client bereitgestellten Befehle und ~/.ssh/rc (falls vorhanden) ignoriert werden. Der Befehl wird mithilfe der Anmeldeshell des Benutzers mit der Option -c aufgerufen. "
    • GatewayPorts - "Gibt an, ob Remotehosts Verbindungen zu für den Client weitergeleiteten Ports herstellen dürfen. Standardmäßig bindet sshd (8) Remoteportweiterleitungen an die Loopback-Adresse. Dadurch wird verhindert, dass andere Remotehosts Verbindungen zu weitergeleiteten Ports herstellen. GatewayPorts kann verwendet werden, um anzugeben, dass sshd Remoteportweiterleitungen ermöglichen soll, sich an Nicht-Loopback-Adressen zu binden, sodass andere Hosts eine Verbindung herstellen können. "
    • PermitOpen:

      Gibt die Ziele an, an die die Portweiterleitung TCP zulässig ist. Die Speditionsspezifikation muss eine der folgenden Formen haben:

      PermitOpen Host:port
      PermitOpen IPv4_addr:port
      PermitOpen [IPv6_addr]:port
      

      Mehrere Weiterleitungen können durch Leerzeichen getrennt angegeben werden. Ein Argument von 'any' kann verwendet werden, um alle Einschränkungen zu entfernen und Weiterleitungsanforderungen zuzulassen. Standardmäßig sind alle Portweiterleitungsanforderungen zulässig.

    • PermitTunnel - Gibt an, ob die Weiterleitung von tun (4) -Geräten zulässig ist. Der Standardwert ist "Nein".
    • X11Forwarding - Gibt an, ob die X11-Weiterleitung zulässig ist. Der Standardwert ist "Nein".

Anwenden der Einschränkungen

Durch Ändern der systemweiten Konfigurationsdatei /etc/ssh/sshd_config kann die Konfiguration angewendet werden, auch wenn die kennwortbasierte Authentifizierung angewendet wird oder wenn die Einschränkungen in ~/.ssh/authorized_keys versehentlich entfernt wurden. Wenn Sie die globalen Standardeinstellungen geändert haben, sollten Sie die Optionen entsprechend auskommentieren.

Match User limited-user
   #AllowTcpForwarding yes
   #X11Forwarding no
   #PermitTunnel no
   #GatewayPorts no
   AllowAgentForwarding no
   PermitOpen localhost:62222
   ForceCommand echo 'This account can only be used for [reason]'

Fügen Sie nun einen Benutzer hinzu:

Sudo useradd -m limited-user

Die Option ForceCommand kann weggelassen werden, wenn die Shell auf eine Nicht-Shell wie /bin/false (oder /bin/true) eingestellt ist, da /bin/false -c [command] nichts bewirkt.

Jetzt kann der Client nur über SSH eine Verbindung zu Port 62222 über die Loopback-Adresse des Servers herstellen (die öffentliche IP-Adresse wird nicht überwacht).

Das Deaktivieren von AllowTcpForwarding würde auch die Verwendung von -R verhindern und somit die Verwendung eines solchen eingeschränkten Kontos zum Weiterleiten eines einzelnen Ports verhindern. PermitOpen localhost:62222 geht davon aus, dass der Port 62222 auf dem Server niemals verwendet wird, da der Client sich problemlos mit ihm verbinden und ihn auch überwachen kann.

Wenn die Weiterleitung von TCP in der systemweiten Konfiguration zulässig ist und die kennwortbasierte Authentifizierung deaktiviert ist, können Sie auch Einstellungen pro Schlüssel verwenden. Bearbeiten Sie ~/.ssh/authorized_keys und fügen Sie die nächsten Optionen vor ssh- hinzu (mit einem Leerzeichen zwischen den Optionen und ssh-):

command="echo 'This account can only be used for [reason]'",no-agent-forwarding,no-X11-forwarding,permitopen="localhost:62222"

Überprüfen

Um sicherzustellen, dass es wie erwartet funktioniert, müssen einige Testfälle ausgeführt werden. In den folgenden Befehlen sollte Host durch das tatsächliche Login ersetzt werden, wenn es nicht in ~/.ssh/config festgelegt ist. Hinter dem Befehl wird ein Befehl angezeigt, der entweder auf dem Client oder auf dem Server ausgeführt werden soll (wie angegeben).

# connection closed:
ssh Host
# connection closed (/bin/date is not executed):
ssh Host /bin/date
# administratively prohibited (2x):
ssh Host -N -D 62222 # client: curl -I --socks5 localhost:62222 example.com
ssh Host -N -L 8080:example.com:80 # client: curl -I localhost:8080
sftp Host
# should be possible because the client should forward his SSH server
ssh Host -N -R 8080:example.com:80 # server: curl -I localhost:8080
# This works, it forwards the client SSH to the server
ssh Host -N -R 62222:localhost:22
# unfortunately, the client can listen on that port too. Not a big issue
ssh Host -N -L 1234:localhost:62222

Fazit

Checkliste: Der SSH-Benutzer sollte nicht in der Lage sein:

  • führen Sie die Shell-Befehle aus - done
  • auf Dateien zugreifen oder Dateien auf den Server hochladen - fertig
  • verwenden Sie den Server als Proxy (z. B. Webproxy) - done
  • zugriff auf lokale Dienste, die ansonsten aufgrund einer Firewall nicht öffentlich zugänglich waren - teilweise, der Client kann nicht auf andere Ports als 62222 zugreifen, sondern kann den Port 62222 auf dem Server überwachen und eine Verbindung herstellen
  • server beenden - done (Beachten Sie, dass diese Überprüfungen auf den SSH-Server beschränkt sind. Wenn Sie einen anderen anfälligen Dienst auf dem Computer haben, kann ein möglicher Angreifer Befehle ausführen und den Server beenden.) usw. )
163
Lekensteyn

Ich bin mir sicher, dass es dafür viele Lösungen gibt, die robuster sind als die, die ich vorschlage. Dies kann jedoch für Ihre Bedürfnisse ausreichend sein. Zu diesem Zweck gehe ich davon aus, dass der Benutzer in der Lage ist, SSH-Schlüssel-basierte Authentifizierung durchzuführen (PuTTY oder Unix-SSH sollten dies unterstützen).

  • Fügen Sie einen Benutzer wie gewohnt hinzu ('adduser' oder ein anderes Tool)

  • Erstellen Sie die Benutzer .ssh dir und .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== [email protected]
EOF
  • Deaktivieren Sie den Kennwortzugriff auf dieses Konto.
your_user $ Sudo usermod --lock ssh_forwarder

Jetzt kann der Benutzer nur noch über den Zugriff auf den richtigen SSH-Schlüssel auf Ihr System zugreifen, und SSH führt "/ bin/bash -c 'read a'" für sie aus, unabhängig davon, was sie ausführen möchten. 'read a' liest einfach bis zu einer neuen Zeile und dann wird die Shell beendet, sodass der Benutzer nur die Eingabetaste drücken muss, um die Verbindung zu beenden.

Es gibt viele andere Dinge, die Sie in 'command =' tun können. Weitere Informationen finden Sie unter man authorized_keys und suchen Sie nach 'command'.

Wenn Ihnen die Tatsache nicht gefällt, dass durch Drücken der Eingabetaste die Verbindung getrennt wird, können Sie für den Eintrag 'command =' Folgendes verwenden:

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

Dadurch wird nur ein temporäres FIFO im Home-Verzeichnis des Benutzers erstellt und versucht, daraus zu lesen. Es wird nichts in diese Datei geschrieben, sodass diese auf unbestimmte Zeit hängen bleibt. Wenn Sie diese Verbindung erzwingen möchten, können Sie außerdem Folgendes tun:

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

Dies sollte sehr wenig Ressourcen verbrauchen, und in diesem Skript sollte nichts schief gehen können, das nicht zum Beenden der Shell führen würde.

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

Ich habe nicht sofort gesehen, wie Sie dem Benutzer erlauben können, von einem entfernten Standort aus weiterzuleiten (ssh -R), aber zu begrenzen (ssh -L). Vielleicht könnte 'permitopen' verwendet werden. googeln war nicht sehr hilfreich. Es scheint, als wäre so etwas wie 'Keine Portweiterleitung, permitremoteopen = 10001' nützlich, um ssh -R 6901:localhost:6901 zuzulassen.

Dies ist eine Lösung. Es kann definitiv verbessert werden, und das Öffnen von Remote-Ports sollte überprüft werden. Wenn es mein Ziel wäre, meiner Großmutter die Verbindung zu meinem LAN zu ermöglichen, damit ich mit VNC ihren Bildschirm sehen kann und der Zugriff auf diese Schlüssel auf sie beschränkt ist, würde ich mich persönlich einigermaßen sicher fühlen. Wenn dies für ein Unternehmen wäre, wäre eine gründlichere Untersuchung erforderlich. Beachten Sie, dass ssh -N überhaupt keine Shell anfordert, sodass der 'command =' - Code nicht ausgeführt wird.

Andere, möglicherweise sicherere Mechanismen können das Erstellen einer benutzerdefinierten Shell für den Benutzer und sogar das Sperren dieser Shell mit apparmour umfassen.

3
smoser