Hallo, gibt es "debug"-tools für ssh1, damit ich weiß warum der Client nicht den Eintrag in authorized_keys unbeachtet läßt? Ich bin es leid. Mal geht's , mal nicht. Ich habe ssh1 durch Kopieren des frisch erzeugten identity.pub- Schlüssels in authorized_keys des Server schon mehrmals eingerichtet und es funktioniert. Mehrere andere Male will es aber einfach auch nicht. Es kommt dann immer wieder die passwort-Abfrage. Ich will hier keine Diskussion in Gang setzen, wie ssh1 eingerichtet wird. Davon gibts genug im Archiv. Ich wüßte gerne ob ich um "Neu Installieren" herum komme indem ich ssh debuggen kann. BTW: bei neueren ssh-Clients (2.x) benutze ich -1 um rsa1 zu erzwingen. Das ist mir bekannt. RSA1 soll es sein wegen Abwärtskompatibilität. thx Ekkard
Hi auch: Am Montag, 5. Mai 2003 14:33 schrieb Ekkard Gerlach:
Hallo, gibt es "debug"-tools für ssh1, damit ich weiß warum der Client nicht den Eintrag in authorized_keys unbeachtet läßt?
Weiß nicht, ob gerade für ssh was anderes gilt, aber ssh -v wirft dir im verbose-mode zumindest schonmal was aus. Ansonsten hat mir mal jemand folgenden Tip gegeben: Auf Ziel sshd -p 2222 -D -d ausführen, dort wartet jetzt ein zweiter ssh-Dämon auf port 2222 mit debug. Auf Initiator ssh -p 2222 ziel ausführen, so wird dorthin verbunden. Durch das gesetzte Debug-Flag kommt ein genauerer Output wie bei ssh-v ziel. GL, Bernd -- One OS to rule them all, one OS to find them. One OS to bring them all, and in the darkness bind them In the land of Redmond, where the shadows lie.
Hi! On Mon, 5 May 2003, Ekkard Gerlach wrote:
gibt es "debug"-tools für ssh1, damit ich weiß warum der Client nicht den Eintrag in authorized_keys unbeachtet läßt?
Starte den sshd doch mal mit "sshd -d" (oder "sshd -d -d ...") und schau Dir den Debug-Output an, und/oder rufe auf dem Client mit der Option "-v" (oder "-v -v") auf - dann werden beide wesentlich gesprächiger! (Das gilt für openssh; das "alte" SSH-Paket hat, glaub' ich, ähnliche Optionen.)
Ich bin es leid. Mal geht's , mal nicht. Ich habe ssh1 durch Kopieren des frisch erzeugten identity.pub- Schlüssels in authorized_keys des Server schon mehrmals eingerichtet und es funktioniert. Mehrere andere Male will es aber einfach auch nicht. Es kommt dann immer wieder die passwort-Abfrage.
Stimmen die Rechte der authorized_keys-Datei (rw-r--r--) auf dem Server? Stimmen die Rechte des $HOME/.ssh-Verzeichnisse (rwxr-xr-x) auf Server und Client? Stimmen die Rechte von identity/identity.pub auf dem Client (rw------- bzw. rw-r--r--)?
BTW: bei neueren ssh-Clients (2.x) benutze ich -1 um rsa1 zu erzwingen. Das ist mir bekannt. RSA1 soll es sein wegen Abwärtskompatibilität.
Du weißt, dass Protokoll 1 als wesentlich unsicherer gilt? Gruß Martin
* Martin Köhling schrieb:
gibt es "debug"-tools für ssh1, damit ich weiß warum der Client nicht den Eintrag in authorized_keys unbeachtet läßt?
Starte den sshd doch mal mit "sshd -d" (oder "sshd -d -d ...") und schau
Yupiii! Das wars! Danke. Ursache bei mir war: 1. Server und Host brauchen Einträge in /etc/hosts ... Could not reverse map address 192.168.0.22. ... 2. Server muß auf /home/seppl die Rechte 755 haben, keinesfalls jedoch 775 (was bei mir war) ... debug1: trying public RSA key file /home/david/.ssh/authorized_keys Authentication refused: bad ownership or modes for directory /home/seppl ...
Stimmen die Rechte der authorized_keys-Datei (rw-r--r--) auf dem Server? Stimmen die Rechte des $HOME/.ssh-Verzeichnisse (rwxr-xr-x) auf Server und Client?
rwx------- für beide .ssh sind auch gültig. Hätte mich auch gewundert, wenn jeder da rumwühlen dürfte ...
Stimmen die Rechte von identity/identity.pub auf dem Client (rw------- bzw. rw-r--r--)?
ja.
Du weißt, dass Protokoll 1 als wesentlich unsicherer gilt?
Ja. ssh wird aber nur im 3-Personen Intranet gebraucht. Keine Internet-Verb. Daher egal. Mittel- und langfristig plane ich natürlich ssh2, klar. Aber erstmal überhaupt zum laufen bringen ... Gruss Ekkard
participants (3)
-
Bernd Tannenbaum
-
Ekkard Gerlach
-
Martin Köhling