SSH-Login dauert zu lange

esbmm

Neues Mitglied
Thread Starter
Dabei seit
28.07.2005
Beiträge
6
Reaktionspunkte
0
Hallo zusammen,

vielleicht hat jemand von Euch das gleiche Problem [gelöst ???] :

Beim SSH-Login am Mac OS X - Server muß man richtig Geduld haben, denn der SSH-Daemon (sshd) wird serverseitig jedesmal neu gestartet. Die Wartezeit ist dabei offensichtlich unabhängig von der CPU - Geschwindigkeit des Servers.

Abhilfe sollte das automatische Starten des Daemons beim Systemstart bringen - denkste ! Nach dem Eintrag in /etc/rc.local wird sshd gestartet und beendet sich gleich wieder, obwohl die Manpage etwas anderes verspricht.

Offensichtlich wird seit 10.4 der SuperDaemon xinetd nicht mehr verwendet, denn das entsprechende Konfigurationsverzeichnis ist jetzt leer. Es existiert allerdings eine "alte Version" mit einigen Einträgen auf meinem iMac, den ich von 10.3 aus upgegradet habe (tolles Neudeutsch).

Wäre toll, wenn jemand eine Lösung dafür hätte. :confused:

MfG
Manfred
 
launchctl load -w ssh
oder so ähnlich kann auch ssh.plist oder /System/Library/LaunchDaemons/ssh.plist

mit 10.4 hielt der launchd einzug...
 
oneOeight schrieb:
launchctl load -w ssh
...
Das wird nicht klappen.
Wenn, dann muss man den kompletten Pfad mit angeben:
Code:
sudo launchctl load -w /System/Library/LaunchDaemons/ssh.plist
Einfacher, aber im Prinzip das selbe:
Code:
sudo service ssh start
Damit wird allerdings nur sshd (= "Entfernte Anmeldung" im Sharing Panel) grundsätzlich aktiviert.
Es bleibt aber dabei, dass sshd nur bei Bedarf gestartet wird.
Will man das ändern, muss man die Datei /System/Library/LaunchDaemons/ssh.plist editieren und entsprechend ändern.
----
Das Problem von Manfred hat aber IMO damit gar nichts zu tun, weil das starten von sshd sehr schnell geht.
Ich erhalte einen loginPrompt innerhalb von max. 5 Sekunden.

Das Problem mit den langen Wartezeiten ist bekannt und wird u. a. hier ausgiebig diskutiert.
 
maceis schrieb:
Es bleibt aber dabei, dass sshd nur bei Bedarf gestartet wird.
Will man das ändern, muss man die Datei /System/Library/LaunchDaemons/ssh.plist editieren und entsprechend ändern.

rate mal was launchctl load -w macht?
das entfernt das disabled bzw setzt es, wenn es nicht da ist...
 
Da muss ich nicht raten, ich weiss es ;).

Ich empfehle Dir die manpages zu launchctl, launchd, launchd.plist und sshd zu lesen.
Wenn disabled auf true steht, wird der Dienst auch nicht "on demand" gestartet.
 
maceis schrieb:
Da muss ich nicht raten, ich weiss es ;).

Ich empfehle Dir die manpages zu launchctl, launchd, launchd.plist und sshd zu lesen.
Wenn disabled auf true steht, wird der Dienst auch nicht "on demand" gestartet.

und wo bleibt die fundamentale logik der aussage?...
was passiert denn wenn man mit -w das disabled entfernt?

oder meintest du, man braucht auch noch das RunAtLoad?
 
Zuletzt bearbeitet:
hm
also wenns nicht mit dem launchctl getan ist.

hm
haste die ip deines clients in die hosts datei geschrieben
denn wenn das nicht der fall ist kennste jetzt das problem
 
oneOeight schrieb:
und wo bleibt die fundamentale logik der aussage?...
was passiert denn wenn man mit -w das disabled entfernt?
...
Wenn Disabled auf <true/> steht, ist der Dienst ganz abgschaltet.
Wenn man es ohne -w entfernt, wird der Job jetzt geladen.
Wenn man es mit -w entfernt, wird der Job jetzt und bei jedem künfigen Systemstart geladen. Wohlgemerkt der Job, nicht der Dienst, der durch den Job konfiguriert und überwacht wird.
man launchctl schrieb:
load [-w] paths ...
Load the specified configuration files or directories of config-
uration files.

-w Remove the disabled key and write the configuration
files back out to disk.

man launchd.plist schrieb:
Disabled <boolean>
This optional key is used to disable your job. The default is false.
oneOeight schrieb:
...
oder meintest du, man braucht auch noch das RunAtLoad?
Nein, das erfüllt einen anderen Zweck (z. B. im Zusammenhang mit zeitgesteuerten Jobs).
man launchd.plist schrieb:
RunAtLoad <boolean>
This optional key is used to control whether your job is launched once at
the time the job is loaded. The default is false.

Die fundamentale Logik?
Ganz einfach: Lies die manpages und probier es aus, wenn Du verstehen möchtest, wie es funktioniert ;).
 
wäre nett wenn sich Manfred alias "esbmm" mal melden würde.
vielleicht hat ja schon irgendwas geholfen :)
 
maceis schrieb:
Nein, das erfüllt einen anderen Zweck (z. B. im Zusammenhang mit zeitgesteuerten Jobs).

na komisch, ich hab das mit einer selbstgebastelten plist für throttled benutzt und komischerweise verhilft das dazu, dass der dienst beim booten gestartet wird... ;)
 
Ja, aber geladen wird der Job doch ohnehin.
Kuck Dir doch mal die anderen Jobs an:
Code:
grep -r RunAtLoad /System/Library/LaunchDaemons
/System/Library/LaunchDaemons/com.vix.cron.plist:       <key>RunAtLoad</key>
Heist das jetzt, das alle anderen Jobs in "/System/Library/LaunchDaemons" beim Booten nicht geladen werden?
Sicher nicht, oder?

Ob RunAtLoad notwendig ist oder nicht, hängt von dem einzelnen Job ab.
Bei ssh.plist ist es definitv nicht notwendig.
 
Zuletzt bearbeitet:
maceis schrieb:
Heist das jetzt, das alle anderen Jobs in "/System/Library/LaunchDaemons" beim Booten nicht geladen werden?
Sicher nicht, oder?

geladen werden sie (spricht die plist wird abgearbeitet), aber nicht gestartet ;)

maceis schrieb:
Ob RunAtLoad notwendig ist oder nicht, hängt von dem einzelnen Job ab.
Bei ssh.plist ist es definitv nicht notwendig.

in dem fall schon, die ursprungsfrage war ja, wie man den dienst automatisch zum starten kriegt beim booten, um auf den angenommenen on demand delay zu verzichten...
 
Hallo zusammen,

da hab' ich wohl in ein Wespennest gestochen ?

Zunächst vielen Dank für Euren Einsatz. Ich mußte erst 'mal nach Hause kommen, um mit meinen Äpfeln spielen zu können - und das dauerte heute extrem lange, denn ich mußte die Autobahn meiden und bin ca. 85 km durch die Pampa gedonnert.

Aktueller Zwischenstand:
Ich teste mit einem iMac G5/20"/1,8 unter Mac OS X 10.4.2 (upgegradet von 10.3.9 wie schon gesagt) und einem MacMini/1,42/1GB unter Mac OS X Server 10.4.2 (seinerzeit frisch installiert).

Netzwerk-Probleme sind aus mehreren Gründen völlig auszuschließen. Die Rechner sind alle in einem lokalen Netz und kennen sich anhand der /etc/hosts. ARD, beispielsweise, ist sofort da und AFP und Server-Administration klappern reibungslos, als wäre man lokal angemeldet.

1. Erkenntnisse:
Auf dem iMac im Terminal: ssh localhost - reagiert in 1 sec.
Auf dem Mini im Terminal (via ARD) - warten bis zum "Connection closed by 127.0.0.1" - keine Verbindung
Vom iMac aus (ssh g4mac) - Verhalten wie auf dem Mini.

"launchctl load -w /System/Library/LaunchDaemons/ssh.plist" habe vorher ich auf beiden Äpfeln ausgeführt.

Ich hole jetzt noch meinen PB (Mac OS X 10.4.2) zum Testen, wie es zwischen PB und iMac funktioniert.

Bis gleich
Manfred
 
Sei doch nicht so hartnäckig ;).
Du hast nicht Recht, und wenn Du Deine eigenen Aussagen überprüfen würdest, könntest Du das sehr leicht selbst feststellen
oneOeight schrieb:
geladen werden sie (spricht die plist wird abgearbeitet), aber nicht gestartet ;)
...
Die Jobs können nicht "gestartet" werden; beim "Abarbeiten der plist" werden bestimmte Kommandos unter bestimmten Kriterien ausgeführt. Ob damit ein Dienst gestartet wird, hängt von den Kommandos und den Kriterien ab, die in der plist Datei festgelegt sind.
launchd macht übrigens noch viel mehr (z. B. laufende Überwachung von Diensten), aber das gehört jetzt nicht hierher.
oneOeight schrieb:
maceis schrieb:
Ob RunAtLoad notwendig ist oder nicht, hängt von dem einzelnen Job ab.
Bei ssh.plist ist es definitv nicht notwendig.
in dem fall schon, die ursprungsfrage war ja, wie man den dienst automatisch zum starten kriegt beim booten, um auf den angenommenen on demand delay zu verzichten...
Und eben das wird man mit RunAtLoad nicht erreichen.
Hast schon mal einen Blick in die ssh.plist geworfen und _verstanden_, was die einzelnen Zeilen bedeuten?
Füg doch mal einen RunAtLoad-key ein, starte Deinen Rechner neu, und prüfe ob Du dann einen laufenden Prozess sshd hast.
Ich kenne das Ergebnis, Du offensichtlich nicht ;).
Wenn Du mir nicht glauben möchtest (was ich nur begrüßen würde :D), probier es doch einfach aus.

Übrigens wird man den delay mit großer Wahrscheinlichkeit auch nicht wegbekommen, dadurch, dass der Dienst dauernd läuft, da das Starten des Dienstes innerhalb von Sekunden passiert.
Auch das kann man sehr leicht prüfen, indem man am Server 'top' laufen lässt, während amn eine ssh Verbindung initiiert.

Das Problem liegt meiner Vermutung nach entweder aktiviertem IPv6 und/oder bei der nicht möglichen Reverse Auflösung von Client und/oder Server
 
Nachtrag:

Verhalten auf dem Powerbook G4/17"/1,5 wie auf dem iMac - alles ok:
-> ssh localhost : ca. 1 sec.
-> ssh g5mac : ca. 1 sec.

Test mit dem Server:
-> ssh g4mac : es dauert ca. 2 min. bis zum RSA key fingerprint (weil 1. Kontakt), dann Passwort-Eingabe - und dann verliessen sie ihn, bis zum "Connection closed ..."

Habe während der Tests auf allen Rechnern die Aktivitäts-Anzeige an: 91 - 100% inaktiv !

PS: Auf dem Powerbook bisher kein Aufruf von launchctl. "Entfernte Anmeldung" ist auf allen Rechnern aktiviert.

MfG
Manfred
 
@Manfred
Mein Tip:
Schalte IPv6 auf allen Rechnern aus.
 
IPv6 ist überall deaktiviert (seit der Konfiguration)
 
Funktioniert die Rückwärts Auflösung sämtlicher beteiligter IP Adressen (Server und Clients)?
Hast mal beim connecten "ssh -vvv" verwendet?
Kannst mal den Output posten?
 
@maceis:

Sehr guter Tip, doch der Output ist zu lang, um ihn hier zu posten. Ich werde die Fehlermeldungen herausfiltern.

Seit ca. 3 min. steht der Prozeß bei: "debug3: packet_send2: adding 32 (len 21 padlen 11 extra_pad 64)"

MfG
Manfred
 
Zurück
Oben Unten