SSH geht nicht richtig

Wolfsbein

Aktives Mitglied
Thread Starter
Dabei seit
10.11.2003
Beiträge
616
Reaktionspunkte
9
Hallo

SSH unter Tiger geht nicht so richtig. Ich sitze hinter einer FritzBox aber unter Windows mit Cygwin geht alles wunderbar. Ich starte mit ssh user@domain.tld, wie unter Windows auch. Nur dauert es dann ca. zwei Minuten bis die Passwortabfrage kommt. An was kann das liegen?
 
Bei mir funktioniert SSH unter Tiger einwandfrei.
Möglicherweise hast Du ein DNS Problem.
Mit "user@domain.tld" meinst Du sicher "user@host.domain.tld".

Folgendes sollte funktionieren:
nslookup host.domain.tld > Ausgabe der IP Adresse
nslookup <IP Adresse> > Ausgabe des Hostes

Wenn der Reverse Lookup nicht funktioniert, kann es zu dem von Dir geschilderten Verhalten kommen.

HTH
 
Wenn ich über nslookup anfrage, kommt die Antwort sofort, in beiden Fällen. Es muss also was anderes sein. Es macht übrigens auch keinen Unterschied, ob ich name@host.domain.tld, oder nur host.domain.tld über ssh anspreche.
 
Wolfsbein schrieb:
Wenn ich über nslookup anfrage, kommt die Antwort sofort, in beiden Fällen. Es muss also was anderes sein.
...
Ja, das ist wahr.
Mir fällt aber jetzt spontan auch nichts mehr ein.
Gibt es andere Dienste auf dem SSH Server?
Falls ja, dauert da die Verbindung ähnlich lange?

Wolfsbein schrieb:
...
Es macht übrigens auch keinen Unterschied, ob ich name@host.domain.tld, oder nur host.domain.tld über ssh anspreche.
Das ist immer dann egal, wenn Der lokal angemeldete Benutzername mit dem auf dem SSH Server identisch ist.
 
maceis schrieb:
...
Das ist immer dann egal, wenn Der lokal angemeldete Benutzername mit dem auf dem SSH Server identisch ist.
Der Nutzername ist unterschiedlich! Ich meinte von der Geschwindigkeit. Leider laufen keine anderen Dienste. Aber ich weiß, dass es bei anderen Leuten, auch unter Tiger, nicht so lange dauert. Es muss irgendwas an meinem System sein :(.
 
Ich musste vor kurzem ein paar mal pingen, bevor ssh ging, aber es geht wieder, ohne das ich was gemacht habe...
 
Wolfsbein schrieb:
Wenn ich über nslookup anfrage, kommt die Antwort sofort, in beiden Fällen. Es muss also was anderes sein.

Bist du sicher? Ich hääte nämlich auch auf reverse DNS getippt. Nur noch mal zur Klarstellung: Du musst auf dem SERVER die Abfrage starten, und dabei die IP des CLIENTS verwenden. Der Server möchte nämlich wissen, wer da so auf ihn verbindet, und wenn er das nciht rauskriegt, kommt es zu diesen Verzögerungen.

Alternativ kannst du bei ssh mal den -v Switch verwenden, gerne auch mehrfach (-vvv), dann bekommst du debugging Infos.

Gruß,
Ratti
 
Natürlich bin ich mir sicher. Ich habe bereits geschrieben, dass ich hinter einem Router hänge, der nach außen die gleiche IP hat. Und mit dem Windowsrechner gehts tadellos.
 
Wolfsbein schrieb:
Natürlich bin ich mir sicher. Ich habe bereits geschrieben, dass ich hinter einem Router hänge, der nach außen die gleiche IP hat. Und mit dem Windowsrechner gehts tadellos.

Es ist möglich, dass der Windows-Rechner noch mit SSH1 connected. Unter Linux ist SSH2 Standard. Deswegen ist das schlecht zu vergleichen.

Was ergibt denn der verbose-switch?

Was steht in /var/log/auth.log ?
Was steht in /var/log/syslog ?
Was steht in /var/log/messages ?

Du könntest mit tcpdump mitsniffen, wenn du eine zweite Session aufmachst.

Kannst du in Windows ssh2 erzwingen - ist das Problem dann auch dort?

Du kannst du in OS X vermutlich mit "-1" ssh1 erzwingen - ist das Problem dann noch da? (Nur zum testen! ssh1 ist weak!)

GRuß,
Ratti
 
Mit ssh -1 gehts in der Tat sofort. Unter Windows nutze ich cygwin mit Open SSL. Da sollte eigentlich auch 2 Standard sein. Wie ich 2 unter Windows erzwingen könnte weiß ich nicht, mit ssh -2 gehts aber genau so schnell. Die genannten Logfiles sind allesamt nicht da!?
 
Wolfsbein schrieb:
Mit ssh -1 gehts in der Tat sofort. Unter Windows nutze ich cygwin mit Open SSL. Da sollte eigentlich auch 2 Standard sein. Wie ich 2 unter Windows erzwingen könnte weiß ich nicht, mit ssh -2 gehts aber genau so schnell. Die genannten Logfiles sind allesamt nicht da!?

Möglicherweise kommt da IPv6 ins Spiel, insbesondere bei der Reversauflösung.

Hm. Vieleicht hilft dir das hier weiter, insbesondere die Deaktivierung der Namensauflösung:
openssh.org/faq.html#3.3

Aber ehrlich gesagt, ohne detailliertes rumwühlen und mitsniffen fällt mir jetzt nicht viel ein. Den Verbose-Switch solltest du aber wirklich nochmal ausprobieren.

Gruß,
Ratti
 
ich hatte ebenfalls dieses problem mit apples' ssh-version. das is'n bug. hab dann unteranderem den bericht [1] gelesen und ssh aus pkgsrc installiert. fink sollte natuerlich auch gehn. seither rennt's wieder.

[1] http://www.liquidx.net/node/875
 
keeney schrieb:
ich hatte ebenfalls dieses problem mit apples' ssh-version. das is'n bug. hab dann unteranderem den bericht [1] gelesen und ssh aus pkgsrc installiert. fink sollte natuerlich auch gehn. seither rennt's wieder.

[1] http://www.liquidx.net/node/875

Das ist alles etwas verwunderlich, denn ich connecte von Tiger aus dauernd auf mindetsnes drei verschiedene Kisten gleichzeitig.

Der Artikel spricht davon, dass eine merkwürdige telnet-Abfrage gestartet wird. Das würde mich noch auf eine Idee bringen: Wenn man seinen Server asozial konfiguriert hat und die Firewall DROPt Pakete statt sie zu REJECTen, dann könnte sowas eine Abfrage lange Zeit ausbremsen.

Ich schicke dem OP mal per PM eine IP, auf die du mal einen Verbindungsversuch unternehmen kannst. Login gibt es natürlich nicht, aber die Wartezeit wäre interessant. Das ist mein Router, und der rejected telnet sauber.

Gruß,
Ratti
 
@ratti: Leider haut das auch nicht hin. Wenn das wirklich ein Bug ist werde ich mal das oben beschriebene probieren.
 
ratti schrieb:
Möglicherweise kommt da IPv6 ins Spiel, insbesondere bei der Reversauflösung.

Hm. Vieleicht hilft dir das hier weiter, insbesondere die Deaktivierung der Namensauflösung:

Gruß,
Ratti

Hallo,

umm, ich will da ja niemanden zu nahe treten, aber könntest Du mir verraten, was DNS PTR Einträge mit SSH zu tun haben sollen ?
Das ist einfach quatsch ... tut mir Leid. Ich habe mehrere Server ohne ReverseEintrag (oder anderem als verwendeten A Rec) und auch die lassen sich über ihren A Record erreichen.
SSH nutzt ja auch kein DNS ... mal ganz logisch gedacht ... du connectest von einem Rechner auf einen Rechner, Port 22. Wo soll denn da jetzt irgendwie etwas reverse aufgelöst werden müssen ?

Und umm ... IP6 reverse ? Wie soll das denn ins Spiel kommen ? Auf die Theorie wäre ich gespannt ...

Nichts für ungut,
Case

--
G3 BW 400 Mhz
 
case schrieb:
...
SSH nutzt ja auch kein DNS ...
...
Nein?
Da bin ich anders informiert; auf die Schnelle hab' ich mal das hier gefunden:
http://publib.boulder.ibm.com/infocenter/pseries/index.jsp?topic=/com.ibm.aix.doc/aixbman/security/openssh.htm schrieb:
...
If UseDNS is set to yes, the ssh server does a reverse host lookup to find the name of the connecting client. This is necessary when host-based authentication is used or when you want last login information to display host names rather than IP addresses.
Note:
Some ssh sessions stall when performing reverse name lookups because the DNS servers are unreachable. If this happens, you can skip the DNS lookups by setting UseDNS to no. If UseDNS is not explicitly set in the /etc/ssh/sshd_config file, the default value is UseDNS yes.
...
oder an anderer Stelle:
http://anoncvs.openbsd.lt/cgi-bin/viewcvs.cgi/www/openssh/de/faq.html?rev=1.47 schrieb:
...
Große Verzögerungen (mehr als 10 Sekunden) werden normalerweise durch Probleme mit der Namensauflösung verursacht:
...
Du kannst die meisten Lookups server-seitig durch das Hinzufügen von UseDNS no in sshd_config deaktiveren
...
 
Hallo,

zum ersten Punkt:
Sehr interessant, daß wußte ich in der Tat nicht. SSH kann Reverse DNS als Authentifikationszusatz(!!!) nutzen.
Dann wäre aber der PTR Eintrag des Client von Interesse ...

zum zweiten Punkt:
Vollkommen logisch, wenn es lange dauert die IP für einen Host zu ermitteln dauert es auch lange bis der Verbindungsaufbau beginnen kann. Das hat aber nichts mit SSH an sich zu tun ... auch ein FTP wird dann lange dauern.

Das führt uns dann ja wieder zum Ausgangspunkt ... ein mit Defaultwerten aufgesetzter SSH Server (unter Tru64, OpenVMS, Debian Linux, Cygwin und natürlich OS X (evtl auch anderen)), den man versucht über die IP zu connecten wird sofort antworten.

Es grüßt,
case

__
G3 BW 400 Mhz
 
Ich war heute in der Uni und habe dort einen Netzwerkanschluss benutzt. Die Einwahl erfolgt bei uns über den Cisco VPN Client. Interessant ist jetzt, dass dort ssh sofort funktioniert. Ich habe außerdem erfahren, dass wir an der Uni einen eigenen DNS Server haben. Allerdings bin ich wohl der einzige PB Nutzer der von dem Problem betroffen ist :(.
 
case schrieb:
...
zum zweiten Punkt:
Vollkommen logisch, wenn es lange dauert die IP für einen Host zu ermitteln dauert es auch lange bis der Verbindungsaufbau beginnen kann. Das hat aber nichts mit SSH an sich zu tun ... auch ein FTP wird dann lange dauern.
...
Sorry, aber das ist Unfug!
Der Server kennt die IP; die steht doch im TCP Header.
Er versucht den DNS Namen herauszufinden (darum reverse lookup).
Einfach nochmal durchlesen und auf der Zunge (oder im Hirn) zergehen lassen.
Und sei bitte etwas vorsichtiger beim Aufstellen von Behauptungen, wenn Du keine Ahnung hast ;).
 
maceis schrieb:
Sorry, aber das ist Unfug!
Der Server kennt die IP; die steht doch im TCP Header.
Er versucht den DNS Namen herauszufinden (darum reverse lookup).
Einfach nochmal durchlesen und auf der Zunge (oder im Hirn) zergehen lassen.
Und sei bitte etwas vorsichtiger beim Aufstellen von Behauptungen, wenn Du keine Ahnung hast ;).

Hallo,
ne, ist richtig ... an Deiner Stelle vielleicht auch einfach nochmal nachdenken.
Ich habe wohl verkannt, daß das ursprüngliche Thread von einer bestehenden IPv4 Verbindung ausging. Jedoch nach ein wenig Nachdenken fällt jedem Volltrottel auf von welchem Szenario ich ausgegangen bin.

Und zwar (zum mitdenken :) Client will per SSH auf den Server zugreifen.
Also geben wir auf Clientseite ein :
ssh -l user host.domain.tld

Zu diesem Zeitpunkt kennt er noch keine IP des Servers. Da sind wir uns einig, oder ?
Okay ... also ein nslookup ... dadurch findet er naemlich die IP heraus, deshalb auch lookup.
So, wenn das nun laenger dauert dauert es logischerweise auch laenger bis er die Verbindung aufbauen kann, egal ob der Client nun FTP, ssh, HTTP, ICA oder sonstwas verwendet, richtig ?

Der Reverselookup, mein Bester, kommt erst nachdem du mit dem Server connected bist. Naemlich genau nach der Eingabe des Usernamen.

Hab mir das öfter durchs Hirn gehen lassen, und Du solltest selbiges vielleicht ein wenig mehr benutzen und Dir nicht anmaßen, du könntest nach drei mißverstandenen Postings eines Users beurteilen ob der Ahnung hat, oder nicht.

Wenn ich mir jetzt über Dich ein Urteil fällen müßte von wegen ReverseIPv6 könnte ja dazwischen kommen oder so ... naja, dann kannste Dir sicher vorstellen, wie das ausfallen würde.

Gruß,
case
 
Zurück
Oben Unten