Falschrum aufgebaute Verbindung übernehmen?

[dirk11]

Hi Leute,

ich hoffe, dies ist überhaupt das richtige Unterforum...

Also, ich habe seit Ende der Woche ein Problem, für welches ich nach einer Lösung suche:
ich administriere einige Rechner im Familienverbund, die stehen also nicht lokal bei mir. Im Normalfall genügt mir dazu eine ssh-Verbindung. Debian Stable läuft auch auf dem Desktop ausreichend stabil, meist kann ich mich mit Paket-Updates begnügen, und bei schwierigen Fällen kann ich notfalls noch ein VNC durch den ssh-tunnel schieben.

Jetzt hat ein Familienmitglied seit Ende der Woche einen Unitymedia-Anschluss. Dazugekriegt hat er so ein kastriertes "Technicolor TC7200U". In der (offenbar absichtlich verkrüppelten) Firmware kann man doch tatsächlich kein port-forwarding einrichten. Grrrr.

Nur - was mache ich jetzt? Umgekehrt (also von seinem Laptop zu mir) klappt eine Verbindung natürlich tadellos.

Gibt es eine Möglichkeit, eine Verbindung "falschherum" aufzubauen? Sprich ich richte ihm ein Icon o.ä. ein, auf der er nur klicken muss, und ich kann die aufgebaute Verbindung dann hier bei mir irgendwie "übernehmen"? Eine andere Möglichkeit sehe ich nicht, da der Endkunde das Scheissding von Unitymedia nicht austauschen kann: UM rückt die Anmeldedaten nicht heraus, außerdem war es zumindest mal so, dass die Anmeldung MAC-gebunden stattfindet, soll heißen keine UM-Hardware=kein Connect, kein Telefon, kein Internet.

Ich brauche da dringend eine Lösung...

[syssi]

Du solltest noch wissen, dass es sich bei dem Unitymedia-Anschluss um einen reinen IPv6-Anschluss handelt. Und ja, du kannst SSH-Tunnel in beiden Richtungen aufbauen. Zum Beispiel kann dein Familien-Mitglied sich zu dir verbinden:

Code: Alles auswählen

ssh -R 2222:localhost:22 user@dein-erreichbarer-rechner

Damit wird der lokale Port 22 herausgereicht und an *deinen* localhost auf Port 2222 gebunden. Du kannst also den entfernten SSH-Daemon per

Code: Alles auswählen

ssh -p2222 localhost

erreichen. Man kann auch per autossh dafuer sorgen, dass sich eine entfernte Maschine schon beim Booten mit einem Remote-System verbindet und Ports raus reicht.

Gruss syssi

[uname]

Ich setze auch Remote-SSH-Forwarding ein. Das spart bei den Fernzuwartenden das Weiterleiten am Router und vor allem ist ein Zugriff nur nach Aktivierung vom Fernzuwartenden möglich. Das schafft Vertrauen, vor allem in Verbindung mit einer Screen- bzw.Tmux-Sitzung zur aktiven Teilnahme. So braucht man nicht mal die Passwörter wissen (ok, könnte man mitsniffen )

[dirk11]

Du solltest noch wissen, dass es sich bei dem Unitymedia-Anschluss um einen reinen IPv6-Anschluss handelt.

Ja, einige Recherche in der Zwischenzeit hat in mir den Verdacht reifen lassen, das es dieses DS-Lite ist. Ich hab noch jemandem im Familienkreis, da besteht das Problem nicht. Kann aber irgendwann kommen.

Und ja, du kannst SSH-Tunnel in beiden Richtungen aufbauen. Zum Beispiel kann dein Familien-Mitglied sich zu dir verbinden:

Code: Alles auswählen

ssh -R 2222:localhost:22 user@dein-erreichbarer-rechner

Damit wird der lokale Port 22 herausgereicht und an *deinen* localhost auf Port 2222 gebunden. Du kannst also den entfernten SSH-Daemon per

Code: Alles auswählen

ssh -p2222 localhost

erreichen.

Moment - das heisst, ich muss bei mir noch Port 2222 öffnen und darauf einen sshd lauschen lassen? Geht das nicht, ohne das ich bei mir noch irgendeinen Port durchreichen muss? Ich muss das port-forwarding bei mir ja genauso machen.

Man kann auch per autossh dafuer sorgen, dass sich eine entfernte Maschine schon beim Booten mit einem Remote-System verbindet und Ports raus reicht.

Interessant, war aber bisher nicht notwendig.

Das schafft Vertrauen

Nö. Das Vertrauen muss vorher vorhanden sein (ist es auch), sonst darf man sowas gar nicht erst angehen.

[uname]

Port 2222 muss nur für localhost erlaubt sein. Evtl. musst du aber generell noch SSH-Port-Forwarding aktivieren.

[syssi]

Port 2222 muss nur für localhost erlaubt sein. Evtl. musst du aber generell noch SSH-Port-Forwarding aktivieren.

Ich glaube Dirk hat noch nicht verstanden, was die Zeilen bewirken. Deshalb noch einmal im Detail: Wir gehen davon aus, dass du eine IPv4-Adresse besitzt, Port-Forwarding funktioniert und du einen SSH-Server laufen hast, der von aussen erreichbar ist. Dein Familienmitglied kann sich also mit deinem SSH-Server verbinden. (-> "ssh user@dein-erreichbarer-rechner)

Darueber hinaus bin ich davon ausgegangen, dass dein Familienmitglied auch mit einem Linux-Rechner arbeitet und ebenfalls auf Port 22 (lokal!) einen SSH-Daemon laufen hat, der von Extern nicht so einfach erreichbar ist. Jedoch ist er in der Lage mit besagtem SSH-Aufruf seinen lokalen Port 22 raus zu reichen und ihn auf den entfernten Maschine (dein Rechner) auf Port 2222 zu binden.

Ein "ssh -p2222 localhost" verbindet sich also nicht mit deinem lokalen SSH-Daemon, sondern dem, welchen dein Familienmitglied von "zu Hause" mitgebracht hat.

Folglich uebernimmst du keine SSH-Verbindung, sondern ihr nutzt die Verbindung in deine Richtung fuer den Aufbau eines Tunnels aus. Durch diesen Tunnel kannst du eine neue SSH-Verbindung aufbauen, um dich in "die richtige Richtung" zu verbinden. Das Problem mit dem fehlenden Port-Forwarding/IPv4 ist damit umgangen.

[dirk11]

Ich glaube Dirk hat noch nicht verstanden, was die Zeilen bewirken.

Stimmt

Deshalb noch einmal im Detail: Wir gehen davon aus, dass du eine IPv4-Adresse besitzt, Port-Forwarding funktioniert und du einen SSH-Server laufen hast, der von aussen erreichbar ist. Dein Familienmitglied kann sich also mit deinem SSH-Server verbinden. (-> "ssh user@dein-erreichbarer-rechner)

Jupp.

Darueber hinaus bin ich davon ausgegangen, dass dein Familienmitglied auch mit einem Linux-Rechner arbeitet und ebenfalls auf Port 22 (lokal!) einen SSH-Daemon laufen hat, der von Extern nicht so einfach erreichbar ist.

Exakt.

Jedoch ist er in der Lage mit besagtem SSH-Aufruf seinen lokalen Port 22 raus zu reichen und ihn auf den entfernten Maschine (dein Rechner) auf Port 2222 zu binden.

Aha.

Folglich uebernimmst du keine SSH-Verbindung, sondern ihr nutzt die Verbindung in deine Richtung fuer den Aufbau eines Tunnels aus. Durch diesen Tunnel kannst du eine neue SSH-Verbindung aufbauen, um dich in "die richtige Richtung" zu verbinden. Das Problem mit dem fehlenden Port-Forwarding/IPv4 ist damit umgangen.

Hmm. Ich hab mal umgebaut:

Ein "ssh -p2222 localhost" verbindet sich also nicht mit deinem lokalen SSH-Daemon, sondern dem, welchen dein Familienmitglied von "zu Hause" mitgebracht hat.

Den Teil kapiere ich immer noch nicht. Er verbindet sich sozusagen "normal" mit meinem aus dem Netz erreichbaren sshd auf Port 22, und mein sshd spuckt diesen Tunnel dann lokal auf meinem Rechner auf 2222 wieder aus? So?

Und da stellt sich noch eine andere Frage für mich:
meldet der entfernte User sich damit an meinem sshd an? Oder "bietet" er nur an, sozusagen login-frei, so dass ich dann mit meinem login "übernehmen" kann? Es geht mir dabei jetzt primär um die Passwort-Frage. Ich kenne das PW des Users zwar (ich habe den Rechner ja aufgesetzt, und der User ist zufrieden, PW ist sicher und merkbar), aber ich mache normalerweise nichts als "anderer" Account - andererseits gebe ich mein eigenes User-PW natürlich nicht weiter. Root-Anmeldungen sind nicht möglich, und die anmeldbaren User stehen auch in der allow-Liste des sshd, darum geht es.

[syssi]

Ein "ssh -p2222 localhost" verbindet sich also nicht mit deinem lokalen SSH-Daemon, sondern dem, welchen dein Familienmitglied von "zu Hause" mitgebracht hat.

Den Teil kapiere ich immer noch nicht. Er verbindet sich sozusagen "normal" mit meinem aus dem Netz erreichbaren sshd auf Port 22, und mein sshd spuckt diesen Tunnel dann lokal auf meinem Rechner auf 2222 wieder aus? So?

Genau richtig. Dein Familienmitglied benoetigt dazu einen Account auf deinem Rechner. Er loggt sich mit obigem Befehl ein und landet in einer Shell auf deinem Rechner. Dieses Verhalten kann man noch optimieren (Shell auf /bin/false setzen) aber fuer den Anfang: Er loggt sich bei dir ein und wartet dann einfach. So lange die Verbindung besteht, besteht auch der Tunnel.

Und da stellt sich noch eine andere Frage für mich:
meldet der entfernte User sich damit an meinem sshd an? Oder "bietet" er nur an, sozusagen login-frei, so dass ich dann mit meinem login "übernehmen" kann?

Beides ist moeglich. Login-frei ist es aber nie. Du kannst lediglich verbieten, dass sich der zusaetzliche Benutzer in einer Shell wieder findet.

Es geht mir dabei jetzt primär um die Passwort-Frage. Ich kenne das PW des Users zwar (ich habe den Rechner ja aufgesetzt, und der User ist zufrieden, PW ist sicher und merkbar), aber ich mache normalerweise nichts als "anderer" Account - andererseits gebe ich mein eigenes User-PW natürlich nicht weiter. Root-Anmeldungen sind nicht möglich, und die anmeldbaren User stehen auch in der allow-Liste des sshd, darum geht es.

Du kannst dir auch einen Dummy-Benutzer einlegen und das Passwort regelmaessig aendern etc. SSHd sprechen nur mit authentifzierten Benutzern. Wer sich nicht authentifizieren kann, der bleibt draussen.

[uname]

Hier meine Lösung:
Du installierst tmux (würde auch mit screen irgendwie gehen) und legst einen Benutzer an und gibst ihm die Shell /usr/bin/restricted in /etc/passwd. Die Shell musst du in /etc/shells erlauben.

/usr/local/bin/restricted (Datei muss ausführbar sein):

Code: Alles auswählen

#!/bin/sh
if [ -z $TMUX ];   then                 
  /usr/bin/tmux attach || /usr/bin/tmux new
else                                                                           
  read -p "ssh localhost -l "
  /usr/bin/ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no localhost -l $REPLY;
fi  

Der Eintrag in der read-Zeile dient dazu, dass die restricted-Shell nicht für andere Dinge genutzt wird. Leider weiß ich nicht ob man durch Backspace bzw. Sonderzeichen diese Sicherheitsfunktion umgehen kann. Alternativ kann man natürlich auch gleich auf eine Eingabe verzichten und es vollständig fest kodieren. Sicherer als ein normaler Benutzer ist das jedoch allemal.

automatische Version, nicht probiert:

Code: Alles auswählen

else
  /usr/bin/ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no localhost -l user -p 2222;
fi

Vorteil bei beiden Lösungen ist nun egal wie oft sich nun der restricted-Benutzer anmeldet, dass das Terminal immer gleich ist. Somit könnt ihr euch gemeinsam anmelden (beide mit dem restricted-Benutzer, du ohne -R usw.). Bei automatischer Ausführung des SSH-Befehls ist es jedoch wichtig, dass der Fernzuwartende sich erst anmeldet, da sonst beim Aufruf der Tunnel noch nicht vorhanden wäre. Das Benutzerpasswort der zweiten SSH-Sitzung kann der Fernzuwartende selbst eingeben ... könnte aber von dir per strace mitgelesen werden.

[dirk11]

So, bin jetzt endlich mal dazu gekommen, das auszuprobieren und - es funktioniert nicht

Code: Alles auswählen

ssh -R 2222:localhost:22 user@dein-erreichbarer-rechner

Damit wird der lokale Port 22 herausgereicht und an *deinen* localhost auf Port 2222 gebunden. Du kannst also den entfernten SSH-Daemon per

Code: Alles auswählen

ssh -p2222 localhost

erreichen.

Und zwar besteht das Problem schon in der ersten Zeile. Ich bin auf einem entfernten Rechner, mache dort

Code: Alles auswählen

ssh -R 2222:localhost:22 user2@dyndns.org -v

Das klappt auch so weit.
Gebe ich dann aber lokal an meinem zu erreichenden Rechner

Code: Alles auswählen

ssh -p2222 user2@localhost

ein, so bekomme ich:

Code: Alles auswählen

ssh_exchange_identification: Connection closed by remote host

und am entfernten Rechner (also eigentlich auf meinem, aber der entfernten Konsole) kann ich lesen:

Code: Alles auswählen

~$ debug1: client_input_channel_open: ctype forwarded-tcpip rchan 5 win 2097152 max 32768
debug1: client_request_forwarded_tcpip: listen localhost port 2222, originator 127.0.0.1 port 50400
debug1: connect_next: host localhost ([127.0.0.1]:22) in progress, fd=7
debug1: channel 1: new [127.0.0.1]
debug1: confirm forwarded-tcpip
debug1: channel 1: connection failed: Connection refused
connect_to localhost port 22: failed.
debug1: channel 1: free: 127.0.0.1, nchannels 2

Lasse ich die erste Zeile hingegen

Code: Alles auswählen

ssh -R 2222:startrechner.dyndns.org:22 user@dein-erreichbarer-rechner

lauten und mache dann auf meinem lokalen Rechner ssh -p2222 user2@localhost, dann geht es. Problem nur: der in Zukunft fernzuwartende Rechner hat keine dyndns-Adresse.

[syssi]

Sicher, dass auf allen beteiligten Maschinen ein SSH-Server laeuft und nicht nur ein SSH-Client installiert ist? Es sieht danach aus, als ob du zwar Port 22 "raus reichst" aber hinter Port 22 garkein Dienst laeuft.

[dirk11]

Sicher, dass auf allen beteiligten Maschinen ein SSH-Server laeuft und nicht nur ein SSH-Client installiert ist?

Äh, ja!? Ich bin zwar keine 20 mehr, aber nicht blöd. Und da ich zwei von drei der Rechner selbst aufgesetzt habe und der dritte derjenige ist, auf den ich mich selbst für Tests per ssh verbinde...

[syssi]

Das sollte kein Vorwurf sein. Ich kann nur widergeben, was man aus deinen Debug-Meldungen lesen kann:

Code: Alles auswählen

...
debug1: confirm forwarded-tcpip
debug1: channel 1: connection failed: Connection refused
connect_to localhost port 22: failed.

Ein "telnet localhost 22" wuerde ein "Connection refused" liefern. Teste es ruhig mal haendisch. Es lauscht also entweder der SSH-Server der entsprechenden Maschine nicht auf Port 22 oder er ist nicht aktiv.

Gruss syssi

[dirk11]

Ok. Selbstverständlich läuft auf jedem dieser Rechner ein sshd, wie soll ich mich wohl sonst direkt darauf anmelden können. Ich zeige es mal Schritt für Schritt:

Rechner A: mein Desktop
Rechner B: mein Server im selben Netzwerk. Dieser Server soll später erreicht werden und hat eine Dyndns-Domain.
Rechner C: ein Rechner im Internet, erreichbar auf vielerlei Wegen, darunter auch ssh. Der Rechner hat eine eigene feste Domain.
Rechner D: der Client, von welchem aus später ein Tunnel zu Rechner B aufgebaut werden soll. Dieser Client hat keine Dyndns-Domain (dies nur zur Vervollständigung, momentan steht der Rechner D nicht zur Verfügung!).

Auf Rechner A habe ich zwei Gnome-Terminalreiter auf, in einem läuft eine ssh-Verbindung auf meinen Server B, im anderen baue ich eine ssh-Verbindung zu Rechner C auf. Jetzt baue ich von Rechner C eine Tunnelverbindung zu Server B mit der folgenden Zeile auf. Der verwendete Username für den Tunnel ist selbstverständlich einer, der auf dem Tunnel-Zielrechner existiert.


Von Rechner C zu Server B:

Code: Alles auswählen

cccc@rechner_c:~$ ssh -R 2222:localhost:22 dddd@rechner_b.dyndns.org -v

funktioniert und gibt mir mein login-Prompt auf dem Ziel Server B.

Jetzt will ich auf Server B diesen Tunnel übernehmen:

Code: Alles auswählen

aaaa@server_b:~$ ssh -p2222 cccc@localhost
ssh_exchange_identification: Connection closed by remote host

ergibt auf Rechner C:

Code: Alles auswählen

dddd@server_b:~$ debug1: client_input_channel_req: channel 0 rtype keepalive@openssh.com reply 1
debug1: client_input_channel_open: ctype forwarded-tcpip rchan 5 win 2097152 max 32768
debug1: client_request_forwarded_tcpip: listen localhost port 2222, originator 127.0.0.1 port 41399
debug1: connect_next: host localhost ([127.0.0.1]:22) in progress, fd=7
debug1: channel 1: new [127.0.0.1]
debug1: confirm forwarded-tcpip
debug1: channel 1: connection failed: Connection refused
connect_to localhost port 22: failed.
debug1: channel 1: free: 127.0.0.1, nchannels 2

Ändere ich die Tunnelzeile in

Code: Alles auswählen

cccc@rechner_c:~$ ssh -R 2222:rechner_c.de:22 dddd@rechner_b.dyndns.org -v

so funktioniert ein

Code: Alles auswählen

aaaa@server_b:~$ ssh -p2222 cccc@localhost

sofort!
Output auf Rechner C:

Code: Alles auswählen

dddd@server_b:~$ debug1: client_input_channel_open: ctype forwarded-tcpip rchan 5 win 2097152 max 32768
debug1: client_request_forwarded_tcpip: listen localhost port 2222, originator 127.0.0.1 port 41430
debug1: connect_next: host rechner_c.de ([183.167.441.212]:22) in progress, fd=7
debug1: channel 1: new [127.0.0.1]
debug1: confirm forwarded-tcpip
debug1: channel 1: connected to rechner_c.de port 22

(die IP wurde von mir fiktiv geändert!).
Hoffentlich war das jetzt nicht zu kompliziert...
Leitztlich scheint es aber was mit dem 2222:localhost:22 zu tun zu haben, das ist wohl doch nicht so ganz richtig.

Immerhin habe ich jetzt aber gelernt, dass für die ssh-Verbindung immer ein Username gewählt werden muss, welcher auf dem Zielrechner der ssh-Verbindung existiert. Die Usernamen können in dieser Betrachtung also vernachlässigt werden.

[dirk11]

EDITH sagt:

vergesst mein voriges posting! Auf den Rechner, welchen ich zum Testen benutzt habe, haben noch mehrere andere Leute Zugriff, und aus irgendeinem Grund (ein anderer Test) hatte jemand per ListenAddress den sshd auf eine Adresse beschränkt, so dass er auf localhost nicht gelauscht hat. Nachdem ich das geändert habe, geht es zumindest dort sofort.
Jetzt muss ich nur noch herausfinden, warum es auf dem Laptop von meinem Bruder nicht geht, aber dafür muss ich selbst Zugriff haben...

[uname]

Ich habe den Fehler in der ganzen Diskussion gefunden. Leider war mein Beitrag nicht ganz richtig:

Port 2222 muss nur für localhost erlaubt sein. Evtl. musst du aber generell noch SSH-Port-Forwarding aktivieren.

Richtig wäre gewesen:
Port 22 muss nur für localhost erlaubt sein. Evtl. musst du aber generell noch SSH-Port-Forwarding aktivieren.

[syssi]

Ich notiere einfach nochmal den Weg der funktionieren *muss*, wenn alle Voraussetzungen erfuellt sind. Begeb dich einmal zu Rechner D. Dort machst du folgendes:

Code: Alles auswählen

apt-get install openssh-server
ssh -R 2222:localhost:22 user@rechner_b
# einloggen!

Diese Verbindung laesst du nun so stehen und gehst zu Standort von "Rechner B". Dort gibst du auf dem lokalen System ein:

Code: Alles auswählen

ssh -p2222 user@localhost

Nun landest du nach dem Login in einer Shell auf Rechner B. Voraussetzung ist, dass auf Rechner D ein sshd installiert ist *und* ein Loopback-Device ("ifconfig lo") aktiv ist. Ich vermute, dass letzteres dein Rechner C nicht erfuellt, weshalb eine Verbindung zum sshd ueber "localhost:22" nicht mit Erfolg gekroehnt ist. Ist die fiktiv WAN-IP (183.167.441.212) auf einer der Netzwerkkarten deines Servers konfiguriert oder handelt es sich um die IP eines Gateways, welches Port-Weiterleitung macht?

Gruss syssi

[dirk11]

Moin syssi, das weiss ich doch. Wie oft soll ich denn noch schreiben, dass der sshd dort von Anfang an (also seit ca. 5 Jahren) drauf ist und auch funktioniert!? Und natürlich läuft dort auch ein loopback-device. Es geht mir ausschließlich um den Tunnelaufbau, weil wg. DSLite kein Zugriff von außen mehr möglich ist.
Und wie gesagt, auf dem Testrechner C war das Problem eine fest eingetragene ListenAddress (die fiktive IP, die ich geschrieben habe) in der sshd_config. Also vergiss das obige letze posting von mir einfach komplett. Da hätte ich auch eher drauf kommen können. Na ja, jetzt weiß ich's...

Es hilft alles nix, so lange ich auf das Laptop keinen physischen Zugriff habe, kann ich nicht erklären, warum das Terminal "einfach so zu geht" und muss hier also auch nicht weiter spekulieren. Das ist ja genau mein Problem: ich habe momentan keinen Fernzugriff und muss für jeden Mist dorthin fahren, weil ich ja noch nichtmal in ein Log schauen kann... Falls das Problem noch weiter besteht, wenn ich es mir vor Ort anschaue, melde ich mich hier natürlich nochmal

[syssi]

Du kennst nun immerhin alle Voraussetzungen, welche du erfuellen musst. Postings nachtraeglich editieren ist keine gute Idee. Ich habe deine Problemloesung gerade erst gefunden, da man Threads selten rueckwaerts liest.

[dirk11]

Postings nachtraeglich editieren ist keine gute Idee. Ich habe deine Problemloesung gerade erst gefunden, da man Threads selten rueckwaerts liest.

Öhm, genau deshalb habe ich auch nicht nachträglich editiert, sondern mein "Edith" als neues posting untendrangeklatscht.