Fernwartungslösung (Remote SSH Port Forwarding)

[uname]

Ich habe vor einiger Zeit schon mal eine Fernwartungslösung auf screen-Basis geschrieben. Diese habe ich nun ein wenig optimiert und vor allem minimiert. Wer Lust hat kann ja mal drüberlesen.

Die SSH-Fernwartung soll nur aus Initiative vom Benutzer stattfinden und von ihm überwachbar sein.
Der Benutzer benötigt einen installierten SSH-Server, der jedoch nur auf "localhost" horchen muss. Der Einsatz von NAT ist kein Problem. Beim Benutzer ist keine Portweiterleitung auf dem Router notwendig. Die Administration klappt an jedem Anschluss.
Der Administrator muss dem Benutzer nur einen SSH-Tunnel-Zugang im Internet (echter Server, vServer, DynDNS...) bereitstellen. Ich habe einen SSH-Key ausgetauscht und diesen per
~/.ssh/authorized_keys

Code: Alles auswählen

command="/bin/false" ssh-rsa ....

nur für /bin/false (und damit für TCP-Forwarding) auf meinem Server berechtigt. Zusätzlich kann für den Benutzer die Shell /bin/false in /etc/passwd eingetragen werden. Eine Shell ist auf keinen Fall nötig und würde ein Sicherheitsrisiko darstellen.

Für die Optik sollte man die Screen-Statuszeile beim Benutzer einblenden.

Code: Alles auswählen

/home/benutzer/.screenrc
hardstatus alwayslastline '[%H] %Lw%=%u %d.%m.%y %c '

Folgendes sehr kurzes Programm stellt man nun dem Benutzer auf seinem Rechner z.B. unter /usr/local/bin/fernwartung zur Verfügung:

Code: Alles auswählen

ssh -t -t -N -R 2222:localhost:22 user@adminrechner-erreichbar-ueber-internet &
pid=$!
/usr/bin/screen -xRR
kill $!

Vorgehen:
Der Benutzer hat ein Problem (Internet muss schon gehen und ruft per Terminal (evtl. Shortcut) das Programm "fernwartung" auf. Es wird der Remote-SSH-Tunnel gestartet und der Benutzer landet in der Screen-Sitzung.
Der Admin kann auf seinem System sehen, dass der Remote-Tunnel verfügbar ist (netstat -an) und verbindet sich entsprechend:

Code: Alles auswählen

ssh benutzer@localhost -p 2222

Mit

Code: Alles auswählen

screen -xRR

kann er an der Screen-Sitzung teilnehmen. Aus Sicherheitsgründen könnte ein eigener Fernwartungsbenutzer auf dem Client gewählt werden oder der Admin kennt nicht das root-Passwort. Das würde dann der Benutzer selbst eingeben müssen. Nach dem Ende der Screen-Sitzung wird auch die SSH-Verbindung getrennt.

Theoretisch könnte der Aufruf natürlich auch automatisch und direkt für root erfolgen. So könnte man eine Vielzahl von Systemen auch ohne Benutzer fernwarten und müsste nicht einmal von außen einen SSH-Server für diese Systeme erreichbar machen. Das Screen-Zeug würde dann natürlich wegfallen.

[Cae]

Ein Problem, das ich sehe: $admin bekommt immer die MitM-Warnung von ssh, weil er immer über denselben Server und Port auf verschiedene Systeme zugreift. Das könnte man mit einer know_hosts-Datei pro zu remotenden Host umgehen, die man dann mit ssh -o GlobalKnownHostsFile übergibt.
Übrigens könnte man auch eine Sitzung auf dem Server vermeiden, indem man auch die Verbindung zum Admin weitertunnelt:

Code: Alles auswählen

admin@lokalekiste$ ssh -N -t -L 2222:localhost:2222:localhost user@host &
admin@lokalekiste$ ssh -p 2222 user@localhost

Das hat den Vorteil (oder auch nicht), dass man dem Server in der Mitte nicht wirklich vertrauen muss, da er nur die Ende-zu-Ende verschlüsselte SSH-Sitzung über SSH-Tunnel weiterleitet. Selbst wenn die Tunnel/der Server in der Mitte kompromittiert wäre(n), kann die Vertraulichkeit zwischen beiden Enden gewährleistet werden.

Essentiell ist natürlich, dass $admin den Fingerprint des SSHd-Keys von $user unabhängig (Telefon, im Vorfeld) kontrollieren und vergleichen kann.

Gruß Cae

[uname]

Danke für die Anmerkungen. Werde ich bei Gelegenheit mal ausprobieren.

[uname]

Ich habe es mit dem Tunneln des Tunnels ausprobiert. Die Syntax ist dann aber so für den Admin:

Code: Alles auswählen

ssh -N -t -L 2222:localhost:2222:localhost user@host

und dann

Code: Alles auswählen

ssh -p 2222 user@localhost

Somit kann man auf einem Server im Internet theoretisch recht leicht einen Benutzer mit Shell /bin/false anlegen, den sowohl der Fernzuwartende als auch der Fernwartende zum Umgehen der NAT-Beschränkungen auf DSL-Routern nutzen können. Ob man nun zur Anmeldung einen Key oder ein Passwort nutzt ist eher unwichtig.
Danke für die Anmerkung. Ich hatte auch schon mal versucht Tunnel weiterzutunneln. Irgendwie hatte das früher nicht richtig funktioniert. Keine Ahnung voran das wohl lag.

[Profbunny]

Ich weiß, der Thread ist relativ alt. Allerdings trifft er so ziemlich genau meine Anforderungen. Ich würde gern den Laptop von meiner Mama über diese Art betreuen, viel zu tun ist dabei nicht.
Ginge hauptsächlich um Updates.

Verbindung würde über den Laptop > Internet >DNS Dienst > mein Router > mein Rechner laufen.

Ist die Art und Weise noch zeitgemäß? Warum tunnelt ihr den tunnel? Außerdem verstehe ich den Teil mit der shell /bin/false nicht so recht. Den brauchst du nur, weil der Tunnel zu deinem Server geht und der Benutzer da keine Rechte haben soll?

Micha

[uname]

Grund für Shell /bin/false:
Die Shell /bin/false stellt eine Sicherheitsfunktion dar. Selbst wenn jemand an Benutzer/Passwort bzw. die SSH-Schlüssel gelangt können maximal SSH-Weiterleitungen aufgebaut werden. Da der Aufruf vom Client per Script erfolgt (Parameter -N siehe unten) sollte dem Anwender das nicht stören und es ist die Sache wert sein.

Tunneln von Tunneln:
Ich denke das ist nur notwendig, wenn auch der Admin nicht direkt auf dem Server ist. Kann man somit weglassen. Admin kann sich vorher per ssh verbinden.

Austausch screen durch tmux:
Mittlerweile verwende ich tmux. Hier nun meine vollkommen ungetestete Portierung auf tmux.
Auf dem Server muss SSH-Port-Forwarding erlaubt sein und es muss einen Benutzer fernwartung geben. Neben der Shell /bin/false sollten auch andere Shells funktionieren. Benötigt wird aber nur die Shell /bin/false.


Aufruf Client z.B. /usr/local/bin/fernwartung vom Benutzer benutzer:

Code: Alles auswählen

ssh -N -R 2222:localhost:22 fernwartung@adminserver-über-internet  (Optional mit -p <port>)
pid=$!
/usr/bin/tmux attach || /usr/bin/tmux new
kill $!

Erst anschließend vom Admin auf dem Server:

Code: Alles auswählen

ssh benutzer@localhost -p 2222
tmux attach

Ich finde den screen-Prefix C-a besser als den tmux-Prefix C-b, daher die tmux-Konfiguration auf dem Client bei Bedarf wie folgt ändern:

~/.tmux.conf:

Code: Alles auswählen

set -g prefix C-a

[Profbunny]

Danke erstmal für die Aufklärung, allerdings habe ich die funktinsweise doch noch nicht verstanden.

ssh login per ssh key auf dem remote host funktioniert:

Code: Alles auswählen

debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ecdsa-sha2-nistp256 SHA256:JZvG7dBAKvJX+Yokc2r67F9BGD2GSvk52apfuipJTXM
debug1: Host '192.168.2.105' is known and matches the ECDSA host key.
debug1: Found key in /home/mutti/.ssh/known_hosts:4
debug1: rekey after 134217728 blocks                                                                          16.08.17 22:22 
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: rekey after 134217728 blocks
debug1: client_input_channel_open: ctype forwarded-tcpip rchan 2 win 2097152 max 32768-512,ssh-dss,ecdsa-sha2-nistp256,ecdsa-debug1: client_request_forwarded_tcpip: listen localhost port 2222, originator ::1 port 57876
debug1: connect_next: host localhost ([127.0.0.1]:22) in progress, fd=4
debug1: channel 0: new [::1] can continue: publickey,password
debug1: confirm forwarded-tcpiphod: publickey
debug1: channel 0: connected to localhost port 22/sysiphus_rsa
debug1: Authentication succeeded (publickey).
Authenticated to 192.168.2.105 ([192.168.2.105]:22).
debug1: Remote connections from LOCALHOST:2222 forwarded to local address localhost:22
debug1: Requesting no-more-sessions@openssh.com
debug1: Entering interactive session.
debug1: pledge: network
debug1: client_input_global_request: rtype hostkeys-00@openssh.com want_reply 0
debug1: remote forward success for: listen 2222, connect localhost:22
debug1: All remote forwarding requests processed
apgdebug1: client_input_channel_open: ctype forwarded-tcpip rchan 2 win 2097152 max 32768
debug1: client_request_forwarded_tcpip: listen localhost port 2222, originator ::1 port 57840
debug1: connect_next: host localhost ([127.0.0.1]:22) in progress, fd=4
debug1: channel 0: new [::1]
debug1: confirm forwarded-tcpip
debug1: channel 0: connected to localhost port 22

Die Verbindung zum Remote Host funktioniert und er zeigt auch an, dass ein Verbindungsversuch stattfindet.Aber die Verbindung lokal auf den SSH Server funktioniert nicht, bzw er verlangt ein Password von mir und ich verstehe nicht welches?

Code: Alles auswählen

ssh mdomann@localhost -p 2222
mdomann@localhost's password: 
Permission denied, please try again.
mdomann@localhost's password: 
Permission denied, please try again.
mdomann@localhost's password: 
Permission denied (publickey,password).

Mein Verständnis ist so, der Laptop verbindet sich per SSH auf meinen Desktoprechner. Diese Verbindung ist gesichert per sshkey und somit auch verschlüsselt. Da diese Verbindung auf den richtigen remote user erfolgt, bin ich normalerweise schon autorisiert. Oder muss ich den umgekehrten Fall ebenso mit einem ssh key absichern?!? BIn verwirrt.

@uname: Könntest du nochmal licht ins dunkel bringen?

Danke Micha

[uname]

Der Client hat nicht nur eine SSH-Verbindung (Shell /bin/false) aufgebaut, sondern zusätzlich einen Remote-Tunnel zurück. Diesen kannst du dir auf dem SSH-Server (wohl dein Desktop) anschauen:

Code: Alles auswählen

netstat -an |fgrep 2222

Verbindest du dich nun mit localhost:2222 so ist es so als ob du dich auf dem aufrufenden Client anmeldest quer durch jedes NAT. Fernwartungstrojaner machen das im übrigen ähnlich, nur dass sie nicht das auffällige SSH, sondern eher HTTPS verwenden

Code: Alles auswählen

ssh mdomann@localhost -p 2222

Hiermit versuchst du dich auf dem aufrufenden Client mit dem Benutzer mdomann anzumelden. Du musst natürlich den Benutzer des Clients verwenden. Sollte es weitere Fehler geben kannst du in /var/log/auth.log auf dem Client schauen. Ach fast vergessen. Natürlich musst du auf dem aufrufenden Client einen SSH-Server installiert haben Aber wenn der nicht da gewesen wäre, hättest du wohl einen anderen Fehler erhalten.

Natürlich kannst du für den Rückweg anstatt eines Passwortes auch einen SSH-Key nutzen (generieren auf dem Server (ssh-keygen) und den Public-Key auf den Client für den dort verwendenten Benutzer in ~/.ssh/authorized_keys bereitstellen).

Wichtig ist noch, dass beide Anwender den selben Benutzer (auf dem aufrufenden Client, nicht den Benutzer auf dem Server (weder deiner noch der mit /bin/false)) wählen, da man sich sonst nicht so einfach in einer gemeinsamen tmux-Sitzung treffen kann (falls man sich treffen will). Aber auch dafür gibt es natürlich Alternativen.


Zusammengefasst:
a: Anwender
b: Admin
f: User /bin/false
A: Client
B: Server

1.) a verbindet sich per SSH als Benutzer f auf B: [A:>1023 zu B:22]
2.) A öffnet Remote Tunnel für B [B(localhost):2222 zu A(localhost):22]
3.) a baut eine tmux-Sitzung auf
4.) b nutzt per ssh Tunnel für Zugriff auf a [B:>1023 zu B(localhost):2222 und damit eigentlich zu A(localhost):22]
5.) b nimmt an tmux-Sitzung teil

Für 1.) und 4.) können statt Bentzername/Passwort SSH-Keys verwendet werden
1.) bis 3.) werden über das Script abgedeckt
4.) und 5.) werden vom Admin manuell durchgeführt

[Profbunny]

super, funktioniert. Danke.