SSH/Gateway
SSH-Gateway - vermittelt verschlüsselte Tunnelverbindungen zwischen SSH-Clients
Beschreibung
- Teilnehmer bauen aktiv einen Tunnel zum Gateway auf
- Keine Portweiterleitungen erforderlich
- Keine Namensauflösung der Teilnehmer erforderlich
- Gateway vermittelt den Kontakt
- Gateway ist ein SSH-Server im Internet
- Trennung verschiedener Kunden/Dienstleiter
- Je Tunnel (Kombination aus Kunde/Dienstleiter) ein Zugang
- Szenario
Hostname | Username |
---|---|
gateway.foxtom.de | sshTnlKunde001 |
kunde001 | support |
support | user |
Gateway
Kunden-Zugang
Tunnel-Benutzerkonto
root@gateway# useradd --create-home --groups users --shell /bin/bash --comment "Tunnel-User Kunden001" sshTnlKunde001
Passwort vergeben
root@gateway# passwd sshTnlKunde001 New password: Retype new password: passwd: password updated successfully
Zugang testen
user@support# ssh -p22 sshTnlKunde001@gateway.foxtom.de sshTnlKunde001@gateway's password:
SSH-Server
- UNIX Sockets
Damit sich Kunden nicht mit dem System eines anderen Kunden verbinden können, werden hier UNIX Sockets verwandt.
- Diese besitzen im Gegensatz zu TCP-Ports eine Zugriffssteuerung
Damit der Socket beim Abbau des Tunnels eine neue Socket-Datei erstellt wird, wird die Konfiguration des SSH-Dienstes ergänzt
- ein erneuter Aufbau des Tunnels ist ansonsten mit dem gleichen Socket-Namen nicht möglich
/etc/ssh/sshd_config
# Specifies whether to remove an existing Unix-domain socket file for local or remote port forwarding before creating a new one. StreamLocalBindUnlink yes
Kunden-Rechner
Tunnel-Benutzerkonto
root@kunde001# useradd -m -G users -s /bin/bash kunde001Tnl
SSH-Key erzeugen
root@kunde001# sudo -u support -i support@kunde001$ ssh-keygen -f /home/support/.ssh/gateway -t ecdsa
Keine Passphrase eingeben (Enter)
Public-Key übertragen
support@kunde001$ ssh-copy-id -p22 -i /home/support/.ssh/gateway.foxtom.de.pub sshTnlKunde001@gateway.foxtom.de
Public-Key-Zugang testen
support@kunde001$ ssh -i /home/support/.ssh/gateway.foxtom.de -p22 sshTnlKunde001@gateway.foxtom.de
- Fingerprint vergleichen
- Bestätigung durch Eingabe von "yes"
Fehlermeldung "PTY allocation request failed on channel 0" und die Verbindung wird abgebrochen. Das ist beabsichtigt.
Automatisierung
Systemd konfigurieren
- Systemd-Service-Unit
/etc/systemd/system/ssh-reverse@.service
[Unit] Description=Reverse SSH Tunnel Service ConditionPathExists=|/usr/bin After=network.target [Service] User=support Environment="GWSOCK=40%I" Environment="GWUSER=sshTnlKunde001" Environment="GWHOST=gateway" Environment="SSHKEY=/home/support/.ssh/gateway" ExecStart=/usr/bin/ssh -NTC -o ServerAliveInterval=60 -o ExitOnForwardFailure=yes -o StrictHostKeyChecking=no -i ${SSHKEY} -R ${GWSOCK}:localhost:%I ${GWUSER}@${GWHOST} # Restart every >2 seconds to avoid StartLimitInterval failure RestartSec=3 Restart=always [Install] WantedBy=multi-user.target
Durch das @ im Namen der Unit-Datei können verschiedene Instanzen (also Tunnel) erstellt werden:
root@kunde001# systemctl daemon-reload root@kunde001# systemctl start ssh-reverse@22.service root@kunde001# systemctl start ssh-reverse@443.service
- Der Port des Tunnels auf dem Gateway wird auf "40%I" gesetzt wobei %I dem Instanznamen (hier 22 und 443) entspricht
- Hier ergibt das auf dem Gateway TCP-Sockets mit den Ports 4022 und 40443.
- Parameter für Instanzen
- Drop-In-Files
/etc/systemd/system/ssh-reverse@22.service.d/tunnel.conf
[Service] # Port of the tunnel at the remote gateway Environment="GWSOCK=/home/ssh-kunde1/ziel3-ssh.socket" # User at gateway to create the tunnel Environment="GWUSER=ssh-kunde1" # remote gateway ##Environment="GWHOST=gateway" # Location of the SSH key ##Environment="SSHKEY=/home/support/.ssh/gateway"
/etc/systemd/system/ssh-reverse@443.service.d/tunnel.conf
[Service] # Port of the tunnel at the remote gateway Environment="GWSOCK=/home/ssh-kunde1/ziel3-https.socket" # User at gateway to create the tunnel Environment="GWUSER=ssh-kunde1" # remote gateway ##Environment="GWHOST=gateway" # Location of the SSH key ##Environment="SSHKEY=/home/support/.ssh/gateway"
- Hier werden die auf dem Gateway verwendeten Sockets angepasst, statt den TCP-Ports werden verschiedene UNIX-Sockets verwendet.
- Außerdem wird ein anderer User auf dem Gateway verwendet.
Support-Rechner
Public-Key-Zugang
Public-Key übertragen
user@support# ssh-copy-id -p22 sshTnlKunde001@gateway.foxtom.de
Public-Key-Zugang testen
user@support# ssh -p22 sshTnlKunde001@gateway.foxtom.de sshTnlKunde001@gateway:~$ exit
Anwendung
Public-Key-Zugang
support@kunde001$ ssh -i /home/support/.ssh/gateway.foxtom.de.pub -p22 sshTnlKunde001@gateway.foxtom.de
- Fingerprint vergleichen
- Bestätigung durch Eingabe von "yes"
"PTY allocation request failed on channel 0"
Fehlermeldung und die Verbindung wird abgebrochen, das ist beabsichtigt.
Tunnel starten
user@support$ ssh -nNT -L 10022:localhost:10001 sshTnlKunde001@gateway
Damit wird ein Tunnel vom lokalen Port 10022 zum Port 10001 auf dem Gateway erstellt
Tunnelaufbau
- Manueller Aufbau
support@debian01:~$ ssh -N -T -C -o ServerAliveInterval=60 -o ExitOnForwardFailure=yes -o StrictHostKeyChecking=no -i ${SSHKEY} -R ${GWSOCK}:localhost:${LOCALPORT} ${GWUSER}@${GWHOST}
Optionen | Bedeutung |
---|---|
-N | Keinen Befehl in der Ferne ausführen |
-T | Deaktiviert Pseudo-Terminal-Zuweisung |
-C | Komprimierung sämtlicher Daten |
-o ServerAliveInterval=60 | |
-o ExitOnForwardFailure=yes | |
-o StrictHostKeyChecking=no | |
-i ${SSHKEY} | absoluter Pfad zum SSH-Key, z.B. ~/.ssh/gateway |
-R ${GWSOCK}:localhost:${LOCALPORT} | Reverse Tunnel erstellt, um vom Gateway aus auf den Kundenrechner zugreifen zu können |
Parameter | Bedeutung |
---|---|
${SSHKEY} | Der komplette Pfad zum SSH-Key, z.B. ~/.ssh/gateway |
${GWSOCK} | Der Socket, welcher auf dem Gateway für den Tunnel verwendet wird
|
${LOCALPORT} |
|
${GWUSER} |
|
${GWHOST} |
|
- Beispiel
$ ssh -N -T -C -o ServerAliveInterval=60 -o ExitOnForwardFailure=yes -o StrictHostKeyChecking=no -i ~/.ssh/gateway.foxtom.de -R 227:localhost:22 -p22 sshTnlKunde001@gateway.foxtom.de
Sicherheit
- Angriffsmöglichkeiten
Es wird ein Tunnel durch die Firewall gebohrt, welche das Netzwerk mit dem Zielsystem schützt
- Risiken
Angreifer erlangt Zugriff auf das Gateway
- könnte von dort alle zu managenden Zielsysteme erreichen
- Das Zielsystem und das dahinter liegende Netzwerk ist dann nur noch durch die Sicherheitsmechanismen geschützt, welche die über den Tunnel erreichbare Anwendung auf dem Zielsystem bietet (z.B. SSH- oder Webserver).
- Gateway gut absichern
Das ist gar nicht so anspruchsvoll
- weil es sich beim Gateway um ein Minimalsystem handelt
- welches vergleichsweise einfach upgedatet und sicher konfiguriert werden kann
- Sicherheitsmaßnahmen auf dem Zielsystem
- laufende Updates
- kein root-logins zulassen
- starke Passwörter
- Bewertung
Bei Einhaltung dieser Maßnahmen die Sicherheit im Vergleich zu anderen Varianten (proprietäre Fernwartungstools, Port-Forwarding durch Firewalls) als höher einzuschätzen
- Zusätzliche Absicherung
- fail2ban
- Durch die Supporter benutzte SSH-Schlüssel auf Smartcard ablegen
- Die können z.B., wie unter "SSH-Login mit OpenPGP Card" beschrieben, auf einer Smartcard abgelegt werden
Siehe auch
Dokumentation
RFC
Man-Pages
Info-Pages
Links
Einzelnachweise
Projekt
Weblinks
Testfragen
Testfrage 1
Testfrage 2
Testfrage 3
Testfrage 4
Testfrage 5