OpenSSH Public Key klappt nicht

Hi,
irgendwie bekomme ich das mit dem OpenSSH Public Key nicht hin. Es wird immer nach einem PW gefragt.
Der Key wurde erfolgreich übetragen mit ssh-copy-id -i .ssh/key_rsa.pub root@abc.myfritz.net -p 2222
Der Server ist eine FreeNAS und der Client eine Debian Blech. Von anderen Blechen mit Debain klappt es .....merkwürdig...

Hat eine eine Idee ?

root@test:~/.ssh# ssh -v -p 2222 root@abc.myfritz.net
OpenSSH_7.4p1 Debian-10+deb9u7, OpenSSL 1.0.2u  20 Dec 2019
debug1: Reading configuration data /root/.ssh/config
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: Connecting to abc.myfritz.net [xx.xxx.xxx.xxx] port 2222.
debug1: Connection established.
debug1: permanently_set_uid: 0/0
debug1: identity file /root/.ssh/id_rsa type 1
debug1: key_load_public: No such file or directory
debug1: identity file /root/.ssh/id_rsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /root/.ssh/id_dsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /root/.ssh/id_dsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /root/.ssh/id_ecdsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /root/.ssh/id_ecdsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /root/.ssh/id_ed25519 type -1
debug1: key_load_public: No such file or directory
debug1: identity file /root/.ssh/id_ed25519-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_7.4p1 Debian-10+deb9u7
debug1: Remote protocol version 2.0, remote software version OpenSSH_8.0-hpn14v15
debug1: match: OpenSSH_8.0-hpn14v15 pat OpenSSH* compat 0x04000000
debug1: Authenticating to abc.myfritz.net:2222 as 'root'  
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: curve25519-sha256
debug1: kex: host key algorithm: ecdsa-sha2-nistp256
debug1: kex: server->client cipher: aes128-ctr MAC: umac-64-etm@openssh.com compression: none
debug1: kex: client->server cipher: aes128-ctr MAC: umac-64-etm@openssh.com compression: none
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ecdsa-sha2-nistp256 SHA256:aFJFYO85BcmZG3rG0YnqbiKH8oLJDz3Eo3G+piPPJ9I
debug1: Host '[abc.myfritz.net]:2222' is known and matches the ECDSA host key.  
debug1: Found key in /root/.ssh/known_hosts:5
debug1: rekey after 4294967296 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: rekey after 4294967296 blocks
debug1: SSH2_MSG_EXT_INFO received
debug1: kex_input_ext_info: server-sig-algs=<ssh-ed25519,ssh-rsa,rsa-sha2-256,rsa-sha2-512,ssh-dss,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521>
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /root/.ssh/id_rsa
debug1: Authentications that can continue: publickey,password
debug1: Trying private key: /root/.ssh/id_dsa
debug1: Trying private key: /root/.ssh/id_ecdsa
debug1: Trying private key: /root/.ssh/id_ed25519
debug1: Next authentication method: password

Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben

Content-ID: 569837

Url: https://administrator.de/contentid/569837

Ausgedruckt am: 13.11.2024 um 08:11 Uhr

10 Kommentare

Neuester Kommentar

Hallo,

hast Du überprüft, ob der Schlüssel wirklich erfolgreich übertragen wurde? Also die Schlüsseldateien mit den Einträgen in authorized_key vergleichen.

Grüße

lcer

Zitat von @lcer00:

Hallo,

hast Du überprüft, ob der Schlüssel wirklich erfolgreich übertragen wurde? Also die Schlüsseldateien mit den Einträgen in authorized_key vergleichen.

Und stimmen die Berechtigungen am Ziel auf ~/.ssh und den Dateien da drin? Da darf nur der Eigentümer Zugriff drauf haben.

lks

liegt es daran, das es über root läuft, sollte doch egal sein, oder ?

root@freenas[~/.ssh]# ls -al
total 7
drwxr-xr-x 2 root wheel 4 May 6 09:27 .
drwxr-xr-x 7 root wheel 19 May 6 09:28 ..
-rw------- 1 root wheel 4506 May 6 08:37 authorized_keys
-rw-r--r-- 1 root wheel 533 Apr 13 20:04 known_hosts

jau, die Schlüssel stimmen

es wird ja nur der Inhalt von xxx.pub übetragen, oder ?
In meinem Fall sieht free.pub und free ( der RSA Private Key ) anders aus vom Inhalt

Moin,

Zitat von @achim22:
root@freenas[~/.ssh]# ls -al
total 7
drwxr-xr-x 2 root wheel 4 May 6 09:27 .
drwxr-xr-x 7 root wheel 19 May 6 09:28 ..

Wie der Kollege @Lochkartenstanzer schon bemerkte, darf das .ssh-Verzeichnis nur für den Owner lesbar sein. Bei Dir darf das aber auch die Gruppe und die Welt.

-rw------- 1 root wheel 4506 May 6 08:37 authorized_keys
-rw-r--r-- 1 root wheel 533 Apr 13 20:04 known_hosts

jau, die Schlüssel stimmen

Es sind die Dateien da. Ob da auch das richtige drin steht, verrät uns ein

cat authorized_keys

Liebe Grüße

Erik

Zitat von @achim22:

es wird ja nur der Inhalt von xxx.pub übetragen, oder ?
In meinem Fall sieht free.pub und free ( der RSA Private Key ) anders aus vom Inhalt

Wie muss man das verstehen?

Zitat von @achim22:

es wird ja nur der Inhalt von xxx.pub übetragen, oder ?
In meinem Fall sieht free.pub und free ( der RSA Private Key ) anders aus vom Inhalt

Wäre ja bei asymmetrischer Verschlüsselung auch komisch, wenn private key und public key denselben Inhalt hätten.

Zitat von @lcer00:

In meinem Fall sieht free.pub und free ( der RSA Private Key ) anders aus vom Inhalt

Wie muss man das verstehen?

Daß er nicht verstanden hat, daß pivate und publich key zwei verschiedene Teile des Schlüssels sind, die eben nicht gleich aussehen.

lks

Und wieso eigentlich free.pub/free ?

Wessen Schlüssel ist das und wer soll sich da anmelden? Du versuchst einen Login auf root mit dem User free?

Grüße

lcer