Hallo Liste,
ich habe hier ein sehr eigenartiges Problem mit ssh. Mein iBook (mit OSX 10.3.7) weigert sich von den Rechnern in meinem Heimnetzwerk ssh Verbindungen anzunehmen. Gleichzeitig dauern ssh Verbindungen vom ibook auf die anderen Rechner (SuSE Linux 9.0 und 9.2) sehr lange (1m31). Das komische ist, daß es mit den Rechnern im Firmennetzwerk klappt -- in beide Richtungen und es dauert auch nicht so lange, bis die Verbindung steht ...
Ein Protokoll des ssh Versuchs vom Linux Rechner auf das iBook
OpenSSH_3.9p1, OpenSSL 0.9.7d 17 Mar 2004 debug1: Reading configuration data /etc/ssh/ssh_config debug1: Applying options for * debug1: Connecting to ibook [192.168.0.33] port 22. debug1: Connection established. debug1: identity file /home/koloska/.ssh/identity type -1 debug1: identity file /home/koloska/.ssh/id_rsa type -1 debug1: identity file /home/koloska/.ssh/id_dsa type -1 debug1: Remote protocol version 1.99, remote software version OpenSSH_3.6.1p1+CAN-2004-0175 debug1: match: OpenSSH_3.6.1p1+CAN-2004-0175 pat OpenSSH* debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_3.9p1 debug1: SSH2_MSG_KEXINIT sent
*** an dieser Stelle bleibt die Ausgabe erstmal für eine ganze Weile
debug1: SSH2_MSG_KEXINIT received debug1: kex: server->client aes128-cbc hmac-md5 none debug1: kex: client->server aes128-cbc hmac-md5 none debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP debug1: SSH2_MSG_KEX_DH_GEX_INIT sent debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY debug1: Host 'ibook' is known and matches the RSA host key. debug1: Found key in /home/koloska/.ssh/known_hosts:2 debug1: ssh_rsa_verify: signature correct debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug1: SSH2_MSG_NEWKEYS received debug1: SSH2_MSG_SERVICE_REQUEST sent debug1: SSH2_MSG_SERVICE_ACCEPT received
*** und auch hier wieder eine ganze Weile Warten
Connection closed by 192.168.0.33
Gleichzeitig meldet das iBook: sshd: fatal: Timeout before authentication for 192.168.0.90
Die Firewall auf beiden Rechnern ist ausgeschaltet und andere Verbindungen funktionieren reibungslos: - ping in beide Richtungen - Apache auf ibook von den Linux Rechnern abfragen
die Nameserver (die für die Rechnernamen nicht gebraucht werden) sind zwar nicht erreichbar (offline), doch auch ein Entfernen der Nameserver aus der iBook Netzwerkkonfiguration ergab keinen Unterschied im Verhalten.
Die ganze Konfiguration lief schon (allerdings waren die Wartezeiten schon immer relativ lang) -- allerdings war das vor dem Update auf OSX 10.3.7. Aber die Verbindung zum und vom iBook klappt ja in einem Netzwerk, daß sich eigentlich nur durch den Adressbereich unterscheidet -- ich bin ratlos.
Habt ihr eine Idee, was das für ein Problem sein könnte? Und vor allem, wie ich es beheben kann?
Danke Uwe
Hi Uwe,
On Wed, Dec 22, 2004 at 01:22:02 +0100, Uwe Koloska wrote:
ich habe hier ein sehr eigenartiges Problem mit ssh. Mein iBook (mit OSX 10.3.7) weigert sich von den Rechnern in meinem Heimnetzwerk ssh Verbindungen anzunehmen. Gleichzeitig dauern ssh Verbindungen vom ibook auf die anderen Rechner (SuSE Linux 9.0 und 9.2) sehr lange (1m31). Das komische ist, da? es mit den Rechnern im Firmennetzwerk klappt -- in beide Richtungen und es dauert auch nicht so lange, bis die Verbindung steht ...
[...]
die Nameserver (die f?r die Rechnernamen nicht gebraucht werden) sind zwar nicht erreichbar (offline), doch auch ein Entfernen der Nameserver aus der
Fuer Reverse Lookup werden sie doch gebraucht. Ich weiss nicht, ob der sshd unter OSX sowas wie TCP-Wrapper benutzt, aber unter Linux ist es normalerweise so. Wenn in /etc/hosts.deny die Zeile ALL: PARANOID drinsteht, dann lehnt der TCP-Wrapper alle Verbindungen von Rechnern ab, deren Hostname nicht zu ihrer IP-Adresse passt (Aufloesung in beide Richtungen, dann Vergleich).
bye, Chris
Christian Perle wrote:
[Uwe schrieb]
die Nameserver (die für die Rechnernamen nicht gebraucht werden) sind zwar nicht erreichbar (offline), doch auch ein Entfernen der Nameserver aus der
Die Rechnernamen können aufgelöst werden (/etc/hosts bzw. netinfo)
Fuer Reverse Lookup werden sie doch gebraucht. Ich weiss nicht, ob der sshd unter OSX sowas wie TCP-Wrapper benutzt, aber unter Linux ist es normalerweise so. Wenn in /etc/hosts.deny die Zeile ALL: PARANOID drinsteht, dann lehnt der TCP-Wrapper alle Verbindungen von Rechnern ab, deren Hostname nicht zu ihrer IP-Adresse passt (Aufloesung in beide Richtungen, dann Vergleich).
Es muß irgendeine paranoide Einstellung mit dem letzten Backup gekommen sein -- anders kann ich mir das auch nicht erklären. Komisch ist aber, daß es in einem anderen (ähnlich gestrickten) Netzwerk ohne Probleme funktioniert.
Uwe
On Wed, Dec 22, 2004 at 11:43:47AM +0100, Uwe Koloska wrote:
Komisch ist aber, daß es in einem anderen (ähnlich gestrickten) Netzwerk ohne Probleme funktioniert.
ist eines der beiden Netze ipv6-enabled, das andere nicht? ist die domain des langsamen Netzes zufällig ".local"?
Am Mittwoch, 22. Dezember 2004 20:29 schrieb Stefan Seyfried:
On Wed, Dec 22, 2004 at 11:43:47AM +0100, Uwe Koloska wrote:
Komisch ist aber, daß es in einem anderen (ähnlich gestrickten) Netzwerk ohne Probleme funktioniert.
ist eines der beiden Netze ipv6-enabled, das andere nicht?
beide Netzwerke sind eigentlich nicht ipv6-enabled. Wobei ich im "langsamen" Netz auch explizit die Einstellungen für ipv6 auf dem iBook ausgeschaltet habe.
ist die domain des langsamen Netzes zufällig ".local"?
ja und nein. Eingetragen ist jeweils eine bestimmte andere Domain (nennen wir sie ".home") allerdings benutzt OSX wohl trotzdem für einige Anfragen ".local".
Der einzige Unterschied, der mir konkret einfällt (außer dem sicher irrelevanten Netzwerk 192.168.0.255 statt 192.168.13.255) ist, daß im "schnellen" Netz ein Nameserver arbeitet.
Es gibt für sshd (bei OSX 10.3.7) eine Option "VerifyReverseMapping" und wenn die ausgeschaltet ist, bekomme ich nach einiger Zeit (Vermutung: DNS Lookup timeout) auch einen Prompt. Allerdings dauert das immer noch ziemlich lange. Wenn die Nameserver zu finden sind, geht es aber schnell. Die Frage ist also, warum will der sshd eine Nameserveranfrage machen?
Verschiedene Merkwürdigkeiten habe ich dabei festgestellt: - wenn kein Netzwerkkabel steckt, gibt es auch keine /etc/resolv.conf - eigentlich läuft die Namensauflösung für alles mögliche (z.B. Hosts) über einen eigenen Dienst (lookupd) und dem kann man die Reihenfolge der Abfrage vorschreiben. Aber selbst die Reihenfolge FF (flat files), NI (netinfo), DNS mit einer garantierten Auflösung der Anfrage in FF ergibt die Wartezeit. - eine Abfrage des lookupd nach den in NI konfigurierten Adressen schlägt fehl, die FF konfigurierten treffen aber obwohl z.B. ping den Namen auch auflösen kann, wenn er nur im NI gesetzt ist ...
Alles sehr mysteriös -- vielleicht muß ich mal bei den BSD Leuten nachfragen. Und vor allem einen DNS Server für mein Heimnetz aufsetzen; am besten direkt mit DHCP.
Einen Workaround habe ich jetzt aber gefunden: - wenn keine (unerreichbaren) Nameserver konfiguriert sind, gibt es nur die Wartezeit, die durch das Erzeugen der Schlüssel (ssh wird von xinetd gestartet) hervorgerufen wird.
Allen die mitgedacht haben "Vielen Dank!" und auch allen anderen ein gesegnetes Christfest und guten Rutsch!
Uwe Koloska
lug-dd@mailman.schlittermann.de
-
Christian Perle -
Stefan Seyfried -
Uwe Koloska -
Uwe Koloska