PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : Zugriff auf Rechner ohne "eigene" öffentliche IP



mirkux
06.03.05, 18:59
Hallo!

Ich versuche seit Tagen krampfhaft einen Weg zu finden, einen entfernten Linux-Rechner zu erreichen, um ihn administrieren zu können. Früher war das duch die dyn. IP des ISDN-Providers kein Problem über ssh. Nun allerdings wurde dort ein Kabelmodem "aufgerüstet". D.H. die User des Kabelnetzbetreibers verschwinden alle hinter Routern (ca. 50 User pro Router) und haben nur noch interne IPs. :confused:
Weiterleitungen sind laut Kabelnetzbetreiber NICHT möglich :mad:
Heisst: ich komme natürlich mit ssh ip-adresse nicht mehr auf den Rechner.

Wie kann man das anstellen, dass vielleicht der entfernte Rechner der Client ist und zu mir connected und ich dadurch Zugriff auf ihn habe? FTP usw geht ja schliesslich auch. Heisst: Daten-Pakete finden schon irgendwie ihren Weg zum Rechner.

Wäre sehr dankbar für Tipps, weil mir die Lösung langsam sehr wichtig wäre und die Zeit brennt. An dem Rechner sitzt jemand, der sich auf mich "verlässt" und selbst keine Ahnung hat. :ugly:

vG
Mirko

Terran Marine
06.03.05, 19:17
Wie kann man das anstellen, dass vielleicht der entfernte Rechner der Client ist und zu mir connected und ich dadurch Zugriff auf ihn habe? FTP usw geht ja schliesslich auch. Heisst: Daten-Pakete finden schon irgendwie ihren Weg zum Rechner.


Genau dieser Ansatz ist richtig,

erstelle vom Client aus einen SSH-Tunnel auf deinen Rechner, und du kannst auf auf beliebige Ressourcen zugreifen (z.b. auf den SSH-Server, welcher auf dem Client läuft)

Gruß
Terran

canis_lupus
06.03.05, 19:31
Es wird Dir nichts anderes übrigbleiben, als das der Client im Netz eine Verbindung zu Dir aufbaut. Verpass deinem Rechner den den dynDNS-Eintrag (oder gib deinem Gegenüber deine IP telefonisch) und lass den Client einen Tunnel zu Dir aufbauen:

ssh -R 2222:localhost:22 user@<dein_rechner>

Du kannst dich dann mit:

ssh user@localhost -p 2222

auf seinen Rechner verbinden.

mirkux
06.03.05, 20:32
ssh -R 2222:localhost:22 user@<dein_rechner>
Du kannst dich dann mit:
ssh user@localhost -p 2222
auf seinen Rechner verbinden.

Ja, prima. Das hat soweit (nur local erstmal zum Test) bei mir zu Hause geklappt. Allerdings hatte ich in sshd-conf den Port umgebogen (Sicherheit und so). muss ich nur die 22 gegen den neuen Port austauschen? Das ging so nämlich nicht. Wenn ich aber alles wieder auf "normal" stelle" scheint es zu funktionieren. :)

Terran Marine
06.03.05, 20:47
Ja, prima. Das hat soweit (nur local erstmal zum Test) bei mir zu Hause geklappt. Allerdings hatte ich in sshd-conf den Port umgebogen (Sicherheit und so). muss ich nur die 22 gegen den neuen Port austauschen? Das ging so nämlich nicht. Wenn ich aber alles wieder auf "normal" stelle" scheint es zu funktionieren. :)

Das sollte ausreichen, ja.

Du kannst, sshd übrigens auch auf mehreren Ports laufen lassen, einfach mehrere angeben in der sshd_config.

Gruß
Terran

mirkux
07.03.05, 10:12
So, ich habe das jetzt mit Standardports auf den entfernten Rechner in dem Kabelnetz probiert.
Der konnte sich bestens verbinden mit mir, was ein "who" bestätigte. Mein Gegenversuch scheiterte aber mit
ssh_exchange_identification: Connection closed by remote host
Ich habe darauf die FW des entfernten Rechners runterfahren lassen ... das gleiche.
Nun bin ich ratlos.
Was habe ich noch nicht beachtet?

vG
Mirko

canis_lupus
07.03.05, 10:22
Was sagt der SSH-Server des Clients? Versuch mal die Option -v beim ssh-Aufruf, um ein genaues Protokoll zu bekommen. Welche Distribution nutz der Client? Könnten Sicherheitseinstellungen (z.B. tcpwrapper -> /etc/hosts.allow oder /etc/hosts.deny) der Grund sein?

mirkux
07.03.05, 10:35
Was sagt der SSH-Server des Clients? Versuch mal die Option -v beim ssh-Aufruf, um ein genaues Protokoll zu bekommen. Welche Distribution nutz der Client? Könnten Sicherheitseinstellungen (z.B. tcpwrapper -> /etc/hosts.allow oder /etc/hosts.deny) der Grund sein?

Beide Rechner auf SuSE 9.2.
host.allow ist alles auskommentiert
host.deny ist auf allow all

das -v soll bei dem entfernten Rechner dazu? Langsam verlier ich den Überblick, wer hier wer ist. ;)

mirkux
07.03.05, 11:39
Was sagt der SSH-Server des Clients? Versuch mal die Option -v beim ssh-Aufruf, um ein genaues Protokoll zu bekommen. Welche Distribution nutz der Client? Könnten Sicherheitseinstellungen (z.B. tcpwrapper -> /etc/hosts.allow oder /etc/hosts.deny) der Grund sein?

Sorry, Kommando zurück!
Es funktioniert. Die Gegenstelle war in der Tat so blöd und hat anstatt localhost localhorst geschrieben. LOL Hab ich im -v-Modus gesehen.

Vielen Dank für die nette und flinke Hilfe!

vG
mirko

canis_lupus
08.03.05, 10:15
Keine Ursache