SSH geht nicht richtig

[Luke1]

Ja, indem Du den gewünschten hostname in der Datei /etc/hostconfig fest einträgst.

HOSTNAME=host.domain.dom

...ach ja, ich vergaß: Wie benutzt man denn diesen Befehl. Ist das ein file? Mit cd etc/hostconfig kann ich jedenfalls nicht in diesen file wechseln.

Luke1

 

[ratti]

Nicht, wenn DHCP auf dem PPP konfiguriert wird und kein Ethernet angeschlossen ist.
Aber es gibt noch ein anderes Problem. Wie soll denn die Antwort des DHCP Servers zurück kommen?

dhcp-relay.

Bin gespannt auf Deine diesbezügliche Theorie.
(Mal ganz abgesehen davon, dass der SMTP Server der Uni kein DHCP anbietet).

Das weiss ich natürlich nicht.

 

[maceis]

dhcp-relay.

Woher soll den Luke1 plötzlich einen relay Agent auf seinem Rechner haben, der die nicht existenten DHCP DISCOVERs ausgerechnet in den Tunnel schiebt?
Abgesehen davon sitzen DHCP Relay Agent üblicherweise auf Routern.

Dass ein SMTP Server auf port 25 (das ist doch das Ende des Tunnels) keine DHCP OFFER Nachrichten verschickt, solltest Du eigentlich wissen .

 

[ratti]

Woher soll den Luke1 plötzlich einen relay Agent auf seinem Rechner haben, der die nicht existenten DHCP DISCOVERs ausgerechnet in den Tunnel schiebt?
Abgesehen davon sitzen DHCP Relay Agent üblicherweise auf Routern.

Dass ein SMTP Server auf port 25 (das ist doch das Ende des Tunnels) keine DHCP OFFER Nachrichten verschickt, solltest Du eigentlich wissen .

Der DHCP-Relay braucht doch nicht auf Lukes Rechner zu laufen, sondern auf der Gegenstelle. Durch den Tunnel gerät der Client "in Reichweite", sprich: Ins gleiche Netzwerk.

Das ist genau meine Config: Der Router ist Router, er ist "DHCP-Server" (In Anführungsstrichen, weil er in Wirklichkeit bloss DHCP-Relay ist", und er ist "SMTP-Server" (Auch das ist er nicht wirklich, weil er im Paketfilter auf den echten SMTP redirected).

Ich behaupte mal: Eine Allerweltsconfig für ein Drei-Zonen-Netzwerk.

Natürlich verschickt nicht der SMTP-Server die DHCP-Offers, sondern der DHCPD/DHCP-Relay auf dem gleichen Rechner.

Gruß,
Ratti

 

[maceis]

Der DHCP-Relay braucht doch nicht auf Lukes Rechner zu laufen, sondern auf der Gegenstelle. Durch den Tunnel gerät der Client "in Reichweite", sprich: Ins gleiche Netzwerk.
...

Der DHCP Relay muss über Layer 2 Broadcasts erreichbar sein. richtig? Und die Antwort des DHCP-Servers wird auch über Broadcasts zurückkommen können. richtig?

...
Das ist genau meine Config: Der Router ist Router, er ist "DHCP-Server" (In Anführungsstrichen, weil er in Wirklichkeit bloss DHCP-Relay ist", und er ist "SMTP-Server" (Auch das ist er nicht wirklich, weil er im Paketfilter auf den echten SMTP redirected).
...

... und der Router befindet sich im selben logischen Subnetz wie die DHCP Clients, oder? Damit erreichen die Broadcasts der Clients den Relay Agent und werden von den Broadcasts, die der Relay in dieses logische Netzt aussendet, erreicht.
Genau das ist bei Luke1 IMO nicht der Fall (schon gar nicht, wenn der Relay Agent im entfernten Netz sitzt).

...
Natürlich verschickt nicht der SMTP-Server die DHCP-Offers, sondern der DHCPD/DHCP-Relay auf dem gleichen Rechner.
...

Der Tunnel beginnt doch auf dem lokalen Rechner auf Port 1080 (Layer 4) und endet auf dem entfernten Rechner auf Port 25 (Layer 4), oder?
Das ist mW eine Ende zu Ende Verbindung. Wie um Himmels Willen soll da ein Layer 2 Broadcast durchgehen?

Und selbst wenn ich den Braodcast reinstecken könnte.
Alles was ich auf localhost:1080 (Layer 4) reinstecke, wird verschlüsselt an $sshserver:22 (Layer 4) gesendet (über Router!) und von $sshserver (entschlüsselt) an $remotehost:25 (Layer 4) weitergeleitet.
An Port 25 horcht aber kein DHCP Server, mal abgesehen davon, dass allerspätestens der erste Router zwischen localhost und $sshserver bzw. $smtpserver die Broadcasts verwerfen würde.
Und selbst wenn auch das nicht zuträfe; der DHCP Server würde an $sshserver:beliebiger_port antworten und dieser würde die Antwort wieder verschlüsseln und an localhost zurücksenden.
Dort würde die Antwort wieder entschlüsselt werden und an Port 1080 (Layer 4) herauskommen, wo aber kein DHCP-Client auf Antwort wartet.

Welche Komponente (wenn nicht der Relay selbst) könnte die Unicasts wieder als Broadcasts versenden?

Hab ich was übersehen?

 

[Luke1]

...sehr interessante Diskussion, glaube ich. Aber was haltet Ihr denn von meiner laienhaften Analyse des Problems?

Gruß,
Luke1

 

[oneOeight]

schichten modelle sind doch toll

du hättest aber lieber das iso/osi modell nehmen sollen, da ist das ganze ein bisschen differenzierter

 

[ratti]

Hab ich was übersehen?

Nein, ich habe was übersehen. Ich habe die ganze Zeit im Hinterkopf, er hätte einen vpn-Tunnel - und über den kann gebroadcasted werden. Hat er ja aber gar nicht. Er hat ein ssh-Portforwarding, und daher nix Broadcast. Ich habe Zeug geredet.

Gruß,
Ratti

 

[ratti]

...sehr interessante Diskussion, glaube ich. Aber was haltet Ihr denn von meiner laienhaften Analyse des Problems?

Da es inzwischen doch recht kreuz und quer gweht, versuche ich nochmal zusammenzufassen:

Du gibt deinen ssh Befehl ein, der lokal:1080 auf remote:25 tunnelt bzw. eigentlich tunneln sollte.
Wenn du dann in einem anderen Terminalfenster "telnet localhost 1080" eingibt, dann erscheint NICHT die Meldung der Gegenstelle, sondern "Connection refused"?

Richtig?

Dann funktioniert der Tunnel nicht.

Hm... du könntest mal -vvv anhängen und die Ausgabe von 10.3 und 10.4 vergleichen.

Gruß,
Ratti

 

[maceis]

schichten modelle sind doch toll
du hättest aber lieber das iso/osi modell nehmen sollen, da ist das ganze ein bisschen differenzierter

An welcher Stelle siehst Du Abweichungen (mal abgesehen davon, dass eine differenziertere Betrachtung IMO gar nicht notwendig ist)?
MAC-Broadcast -> Layer 2
IP Adressen -> Layer 3
Ports (Ende zu Ende Verbindung)-> Layer 4
Alles ISO/OSI
Darüber befinden sich die Anwendungsschichten, auf denen besipielsweise die Verschlüsselung stattfindet, die ich im Vorpost noch keinem Layer zugeordnet hatte.

 

[Luke1]

Da es inzwischen doch recht kreuz und quer gweht, versuche ich nochmal zusammenzufassen:

Du gibt deinen ssh Befehl ein, der lokal:1080 auf remote:25 tunnelt bzw. eigentlich tunneln sollte.
Wenn du dann in einem anderen Terminalfenster "telnet localhost 1080" eingibt, dann erscheint NICHT die Meldung der Gegenstelle, sondern "Connection refused"?

Richtig?

Also ich habe das nach diesen Vorgaben gemacht:
1. Tunnel aufgebaut mit ssh-Befehl, und dann
2. den telnet Befehl ausgeführt.

Und siehe da, der Tunnel existiert:

Welcome to Darwin!
dhcphg-80072:~ user$ telnet localhost 1080Trying ::1...
Connected to localhost.
Escape character is '^]'.
220 XXX.XXX.de ESMTP Sendmail 8.12.11/8.12.11; Fri, 15 Jul 2005 14:58:56 +0200 (CEST)

Also kann Mail aus irgendeinem Grund den Tunnel nicht benutzen. Habe das eben noch mal ausprobiert. Weder localhost noch iBookG4.local funktionieren.

Mail sagt immer, die Mail könne über den Server nicht verschickt werden. Also ich verzweifle jetzt bald. Für mich sieht es ganz so aus, dass Mail den lokalen Server, also den localhost oder iBookG4.local, nicht erkennt. Denn das kleine Drehsymbol dreht eine ganze Weile, bis die Nachricht kommt.

Ich bin bei meiner Suche noch auf diese http://discussions.info.apple.com/webx?14@25.fEPkaLDaZAs.2@.68aed9df Diskussion im Apple Forum gestoßen. Obwohl ich nicht so ganz verstehe wovon die da genau sprechen, scheint mir, dass mein Problem damit irgendwie zusammenhängt. Was meint Ihr?

Gruß,
Luke1

 

[ratti]

dhcphg-80072:~ user$ telnet localhost 1080Trying ::1...
Connected to localhost.
Escape character is '^]'.
220 XXX.XXX.de ESMTP Sendmail 8.12.11/8.12.11; Fri, 15 Jul 2005 14:58:56 +0200 (CEST)

Also kann Mail aus irgendeinem Grund den Tunnel nicht benutzen. Habe das eben noch mal ausprobiert. Weder localhost noch iBookG4.local funktionieren.

Es gibt Licht am Ende des Tunnels. ))

Ich bin bei meiner Suche noch auf diese http://discussions.info.apple.com/webx?14@25.fEPkaLDaZAs.2@.68aed9df Diskussion im Apple Forum gestoßen. Obwohl ich nicht so ganz verstehe wovon die da genau sprechen, scheint mir, dass mein Problem damit irgendwie zusammenhängt. Was meint Ihr?

Was passiert, wenn du, wie vorgeschlagen, 127.0.0.1 statt localhost verwendest? Sowohl bei ssh als auch in Mail?

Eigentlich sollte beides das gleiche sein, aber der Thread lässt vermuten, dass da ipv4 vs ipv6 irgendwie rumspackt. Das "Trying ::1" oben deutet auf ipv6 hin, während dein Portforwarding ipv4-Syntax verwendet. Eigentlich sollte das nicht machen. Nunja.

Wenn das immer noch nicht klappt, musst du glaubich wirklich mal deine Einstellungen in Mail screenshotten. Du kannst ja die IP und den Usernamen abändern, solange es nicht sinnentstellend ist.

Gruß,
Ratti

 

[Luke1]

Es gibt Licht am Ende des Tunnels. ))



Was passiert, wenn du, wie vorgeschlagen, 127.0.0.1 statt localhost verwendest? Sowohl bei ssh als auch in

Hi Ratti,

ja ich habe mich sehr gefreut, dass wenigstens der Tunnel funktioniert.

Ich habe nun auch noch mal probiert, ob es mit 127.0.0.1 funktioniert. Dazu habe ich in Mail unter "SMTP-Server" 127.0.0.1 eingetragen. Bei ssh weis ich ich leider nicht so genau wo da der localhost, in welcher Form auch immer, eingetragen werden soll. Der Befehl lautet ja wie folgt:

ssh -N -L 1080:smtp.XXX.de:25 meinbenutzername@dererreichbareserver.XXX.de

Eine Möglichkeit hier 127.0.0.1 einzutragen sehe ich da nicht.

Gruß,
Luke1

 

[maceis]

...
Eine Möglichkeit hier 127.0.0.1 einzutragen sehe ich da nicht.
...

Das ist nur dann relevant, wenn der Server, den Du erreichen möchtest (in Deinem Fall ein smtp Server) auf dem selben host läuft, wie der ssh Server.
In diesem Fall, könnte der ssh Server den Mailserver mit dem Namen localhost erreichen.
Das ist aber bei Dir offensichtlich nicht der Fall.

HTH

 

[ratti]

ja ich habe mich sehr gefreut, dass wenigstens der Tunnel funktioniert.

Eine Möglichkeit hier 127.0.0.1 einzutragen sehe ich da nicht.

Man kann bei -L noch eine zu bindene Adresse voranstellen, siehe "man ssh" an der Konsole, aber je mehr ich drüber nachdenke, bleibt eigentlich nur noch "Mail" als Problem übrig. Der telnet-Befehl beweist ja, das der Tunnel klappt. Und du sagst ja, du hast auch schon per telnet eine richtige Mail versendet?

Ehrlich gesagt ist das jetzt ein Punkt, an dem mir nichts mehr einfällt.

Bist du sicher, dass in "mail" alles richtig konfiguriert ist?

Hast du den Preferences-Dialog geschlossen? Erst dann werden Account-Einstellungen gesichert.

Funktioniert testweise ein anderes Mailprogramm (Thunderbird)?

In Tiger-Mail gibt es doch diesen Connection-Tester oder wie das Ding heisst. Liefert der eine vernünftige Info?

Hast du in Mail dieses kleine Status-Fenster aktiviert, in dem man etwas mehr sehen kann?

Während "Mail" hängt, in einem Terminal mal "netstat -pn" eintippen, dann sollten wir sehen, wohin "Mail" verbindet. Etwa so:

tcp        0      0 client-69.local:49436   client-222.local:pop3   VERBUNDEN  3944/evolution
tcp        0      0 client-69.local:49435   client-222.local:pop3   TIME_WAIT  -

"evolution" ist mein Mailprogramm, es läuft auf "client-69" und holt per pop3 gerade Mails von "client-222", meinem lokalen Server. Dieses Beispiel ist zum besseren Verständnis ohne "-n" aufgerufen, bei dir sollen nur Zahlen erscheinen.


Oh Mann. Ich hasse "Mail". Mit der heissen Nadel gestrickt und sowas von unkooperativ bei der Fehlersuche.

Gruß,
Ratti

 

[ratti]

Ach so, eins habe ich noch vergessen:
Liefere bitte mal die exakte, komplette Fehlermeldung. "Connection refused" - sagt er da noch eine IP, einen Port oder so an?

Gruß,
Ratti

 

[maceis]

Man kann bei -L noch eine zu bindene Adresse voranstellen, siehe "man ssh" an der Konsole,
...

Da muss man allerdings dazu sagen, dass dies mit dem Schalter -b gemacht wird.
Ein Versuch kann nicht schaden, ich vermute aber nicht wirklich, dass es was bringt.
Ein weiterer "Verzweiflungs"versuch könnte im Abschalten von IPv6 in den Netzwerkeinstellungen bestehen.

 

[Luke1]

Es funktioniert, endlich!

Lieber Ratti, lieber Maceis,

endlich, nicht nur Licht am Ende des Tunnels, sondern auch die volle Funktionalität!

Ratti, Du hattest Recht, es war die Adresse 127.0.0.1, die den entscheidenden Durchbruch brachte. Ich hatte gestern nur vergessen, den Port von 25 (den nutze ich, wenn ich im Uninetz lokal auf den SMTP-Server zugreifen kann) auf 1080 umzustellen. Da konnte Mail natürlich nicht durchkommen. Es waren also die Einstellungen in Mail, wie maceis vermutet hatte.

Also für alle, die auf diesen Thread mit demselben Problem zugreifen. Ändert überall dort, wo Ihr unter OS 10.3.X "localhost", oder wie Euer Rechner auf sonst heißen mag, eingetragen hattet, den Eintrag auf die loop back Adresse "127.0.0.1". Das sollte das Problem beheben.

Lieber Ratti, lieber maceis, ich danke Euch für Eure großartige Hilfe!!!

Der entscheidende Durchbruch kam durch Eure Hinweise. Außerdem habe ich richtig viel über ssh und telnet gelernt.

Gruß,
Luke1

 

[chinese_postman]

Hi,

ich habe ebenfalls die Fritzbox WLAN FON und SSH funktioniert bei mir nicht. Von anderen Rechnern (Windows und Linux) klappt es problemlos.

Output von ssh:

macmini:~ max$ ssh -vvvvvvv xxxx.xxxx.de
OpenSSH_3.8.1p1, OpenSSL 0.9.7b 10 Apr 2003
debug1: Reading configuration data /etc/ssh_config
debug2: ssh_connect: needpriv 0
debug1: Connecting to xxxx.xxxx.de [xxxxxxxxxx] port 22.
debug1: Connection established.
debug1: identity file /Users/xxx/.ssh/identity type -1
debug1: identity file /Users/xxx/.ssh/id_rsa type -1
debug1: identity file /Users/xxx/.ssh/id_dsa type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_3.4p1 Debian_krb5 3.4p1-0woody4
debug1: match: OpenSSH_3.4p1 Debian_krb5 3.4p1-0woody4 pat OpenSSH_3.2*,OpenSSH_3.3*,OpenSSH_3.4*,OpenSSH_3.5*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_3.8.1p1
debug3: Trying to reverse map address xxxxxxxx.

Das Problem ist wohl, daß Reverse Map nicht klappt. Was kann ich nun tun ?

Danke,
Max

 

[maceis]

...
Das Problem ist wohl, daß Reverse Map nicht klappt. Was kann ich nun tun ?
...

Das Reverse Mapping klappt einwandfrei.
[Edit]zumindest von meinem Rechner aus; ich bekomme sofort einen login Prompt[/Edit]

Brichst Du den Befehl dann ab oder kommen noch weitere Meldungen?
Was passiert, wenn Du länger wartest?

[nochmal edit: ]das reversemapping kannst Du so testen:
nslookup 131.xxx.xxx.xxx