ssh auf anderen Server per "ssh pub key" aus dem root Account

[pom]

Hallo,

ich habe hier einen FreeBSD Server und einen RaspberryPI.

Auf beiden gibt es einen User "user". id_rsa.pub habe ich vom FreeBSD Server auf den RaspberryPI kopiert.

Ich kann mich problemlos ohne Passwort einloggen wenn ich als "user" auf der FreeBSD Seite angemeldet bin.
Ich konnte mich bisher auch ohne Passwort auf dem PI einloggen wenn ich als root auf dem FreeBSD Server angemeldet war. Dann musste ich halt "ssh user@192.168.6.18" verwenden.

Heute morgen habe ich dann ein "freebsd-update fetch install" gemacht (ssh Thema).

Nun klappt das automatische einloggen nur noch wenn ich als "user" angemeldet bin. Wenn ich vom root Account aus "ssh user@192.168.6.18" aufrufe werde ich immer nach dem PW gefragt.

Woran kann das liegen?

Gruß,
Peter

 

[kmh]

Hi Peter,

hier gibt es eine wunderbare Anleitung wie du dein Problem ausfindig machen kannst:

http://blog.codefront.net/2007/02/28/debugging-ssh-public-key-authentication-problems/

• Getting more debug info when connecting with your ssh client: Add a ‘-v’ option to your ssh command (e.g. ssh chuyeow@remotehost -v -v -v). Add more ‘-v’ for more detailed debug (you can do up to ‘-v -v -v’ I think).
• Debugging on the remote host by running sshd in debug mode: Run ‘/usr/sbin/sshd -d -p 2222′ on the remote host and connect to it. ’2222′ here is the port number of the sshd process you started on the remote host.
• tail the authentication log: Run ‘tail -f /var/log/auth.log’ on the remotehost. You can watch the log as you try to connect via SSH with your key.
• Make sure your ssh key agent is running: Do a ‘ps aux|grep ssh-agent’. Make sure your key agent is running. If you’re not using ssh-agent (I like keychain from Gentoo, or SSHKeyChain for Mac OS X), do whatever you have to do to ensure that your keychain is running.
• Make sure your private key is added to the ssh key agent: Do a ‘ssh-add -l’ to check that ssh-agent has your key. Likewise, if you are using something else, check your keychain application has your private key.
• Check the permissions on your home directory, .ssh directory, and the authorized_keys file: If your ssh server is running with ‘StrictModes on’, it will refuse to use your public keys in the ~/.ssh/authorized_keys file. Your home directory should be writable only by you, ~/.ssh should be 700, and authorized_keys should be 600.

http://blog.codefront.net/2007/02/28/debugging-ssh-public-key-authentication-problems/


Ich vermute einfach mal das dein public key nicht übereinstimmt bei entsprechnder Nutzer-Variante.
Ansonsten hilft mir immer das Tool "ssh-copy-id". Das übernimmt den Schlüsselaustausch voll automatisch.

 

[pom]

Hallo,

ich bekommen folgenden Output:

ebug2: key: /root/.ssh/id_rsa (0x8038410d0),
debug2: key: /root/.ssh/id_dsa (0x0),
debug2: key: /root/.ssh/id_ecdsa (0x0),
debug1: Authentications that can continue: publickey,password
debug3: start over, passed a different list publickey,password
debug3: preferred publickey,keyboard-interactive,password
debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /root/.ssh/id_rsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey,password
debug1: Trying private key: /root/.ssh/id_dsa
debug3: no such identity: /root/.ssh/id_dsa: No such file or directory
debug1: Trying private key: /root/.ssh/id_ecdsa
debug3: no such identity: /root/.ssh/id_ecdsa: No such file or directory
debug2: we did not send a packet, disable method
debug3: authmethod_lookup password
debug3: remaining preferred: ,password
debug3: authmethod_is_enabled password
debug1: Next authentication method: password
pmueller@192.168.6.18's password:

Es scheint so als ob der RSA key nicht akzeptiert würde.
Oder was bedeutet das?

Gruß,
Peter

 

[kmh]

debug3: no such identity: /root/.ssh/id_dsa: No such file or directory
debug3: no such identity: /root/.ssh/id_ecdsa: No such file or directory

Der Nutzer root auf dem Rechner von dem aus du dich anmelden möchtest hat keinen privaten Schlüssel dessen öffentlicher Schüssel auf besagtem Server hinterlegt sein könnte.

Als erstes "ssh-keygen" einen Schlüssel erzeugen.
Anschliessend mit "ssh-copy-id" auf das Ziel-System kopieren.

Dann sollte es klappen!

Das hat aber nichts mit dem gestern veröffentlichten Update für FreeBSD zu tun. Das betrifft nämlich OpenSSL.

 

[pom]

>Der Nutzer root auf dem Rechner von dem aus du dich anmelden möchtest hat keinen privaten Schlüssel

Doch hat er und ich habe den pub Schlüssel auf das Zielsystem übertragen.
Da ich mich per ssh user@host anmelden will: ist dann sowieso nicht der key des users relevant? Da klappt es ja.

ls /root/.ssh
id_rsa id_rsa.pub known_hosts

 

[kmh]

Du schmeißt da glaube ich etwas durcheinander ...

root@localhost hat KEINE "/root/.ssh/id_dsa" das steht ja in deiner Fehlermeldung! Also keinen privaten Schlüssel. Der nutzer root@localhost brauch aber einen seperaten Schlüssel der erst lokal erstellt und dann auf das Zielsystem kopiert werden muss.
Auf dem Zielsystem muss der Schlüssel aber in "authorized_keys" eingetragen sein und die Datei sehe ich oben bei deinem "ls" auf dem Zielsystem nicht.

Hier ist die ganze Prozedur noch einmal ausführlich erklärt ohne die Magie von "ssh-copy-id":

http://www.schlittermann.de/doc/ssh.html

 

[pom]

Hallo,

danke für deine Geduld. Das Problem war, dass ich nur ssh-keygen -t rsa verwendet habe und den public rsa Schlüssel auf das Zielsystem übertragen habe.

Nun habe ich auch ssh-keygen -t dsa ausgeführt und diesen public Schlüssel auch übertragen.

Nun geht es. So ganz klar ist mir das aber nicht. Wieso reicht der public rsa Schlüssel nicht?

Gruß,
Peter

 

[kmh]

Hi Peter,

ich glaube ich sollte so spät einfach keine Antworten mehr posten Meine Antwort war nämlich nicht korrekt!

Du hattest eine Datei "id_rsa" also einen privaten Schlüssel, das Problem war nur dass besagter Schlüssel eben nicht zum öffentlichen Schlüssel passte der hinterlegt war, also genau dass, was ich vermutet hatte, in meinem Post ganz oben.

Du hast jetzt einfach das zweite mögliche Protokoll gewählt und dafür einen Schlüssel erstellt, der nun auch passt. Er prüft jetzt "id_rsa" passt nicht und geht dann weiter zu "id_dsa" die nun übereinstimmt.

Normalerweise schaut der sshd in zwei Dateien nach

~/.ssh/authorized_keys

und

~/.ssh/authorized_keys2

(Siehe http://www.openssh.com/cgi-bin/man.cgi?query=sshd&sektion=8&arch=&apropos=0&manpath=OpenBSD+Current). Die Datei war aber bei dir nicht vorhanden, existiert sie nun? Müsste sie nämlich, außer du hast deine Config entsprechend abgeändert.