SSH überspringt immer wieder meinen Pubkey und fragt nach einem Passwort

Jedes Mal, wenn ich auf meinem Remote-Server ssh bin, muss ich das Passwort angeben. Ich habe meinen öffentlichen Schlüssel (id_dsa.pub) mit folgendem Befehl auf den Remote-Server kopiert:

ssh-copy-id -i id_dsa.pub user@server

Ich habe überprüft, ob es zu authorized_keys hinzugefügt wurde. Alle Datei- / Verzeichnisberechtigungen sind korrekt:

~user 755
~user/.ssh 700
~user/.ssh/authorized_keys 640
~user/.ssh/id_dsa.pub 644

Das PasswordAuthentication-Feld in / etc / ssh / sshd_config ist auf yes gesetzt. Ich versetzte den sshd in den Debug-Modus und fügte dem ssh-Befehl den verbose-Schalter hinzu. Ich habe den Eindruck, dass der Server wegen der Leitung nicht versucht hat, id_pub.dsa zu verwenden

Skipping ssh-dss key: ........... not in PubkeyAcceptedKeyTypes

Auf der Serverseite ist keine verschlüsselte Disc vorhanden. Irgendwelche Ideen, wie man weiterkommt? Hier ist die Debug-Info zum ssh-Daemon:

sudo /usr/sbin/sshd -d
====
debug1: sshd version OpenSSH_6.6.1, OpenSSL 1.0.1f 6 Jan 2014
debug1: key_parse_private2: missing begin marker
debug1: read PEM private key done: type RSA
debug1: private host key: #0 type 1 RSA
debug1: key_parse_private2: missing begin marker
debug1: read PEM private key done: type DSA
debug1: private host key: #1 type 2 DSA
debug1: key_parse_private2: missing begin marker
debug1: read PEM private key done: type ECDSA
debug1: private host key: #2 type 3 ECDSA
debug1: rexec_argv[0]='/usr/sbin/sshd'
debug1: rexec_argv[1]='-d'
Set /proc/self/oom_score_adj from 0 to -1000
debug1: Bind to port 22 on 0.0.0.0.
Server listening on 0.0.0.0 port 22.
debug1: Bind to port 22 on ::.
Server listening on :: port 22.
debug1: Server will not fork when running in debugging mode.
debug1: rexec start in 5 out 5 newsock 5 pipe -1 sock 8
debug1: inetd sockets after dupping: 3, 3
Connection from xxx port 63521 on yyy port 22
debug1: Client protocol version 2.0; client software version OpenSSH_7.1
debug1: match: OpenSSH_7.1 pat OpenSSH* compat 0x04000000
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.6.1p1 Ubuntu-2ubuntu2.3
debug1: permanently_set_uid: 115/65534 [preauth]
debug1: list_hostkey_types: ssh-rsa,ssh-dss,ecdsa-sha2-nistp256 [preauth]
debug1: SSH2_MSG_KEXINIT sent [preauth]
debug1: SSH2_MSG_KEXINIT received [preauth]
debug1: kex: client->server chacha20-poly1305@openssh.com <implicit> none [preauth]
debug1: kex: server->client chacha20-poly1305@openssh.com <implicit> none [preauth]
debug1: expecting SSH2_MSG_KEX_ECDH_INIT [preauth]
debug1: SSH2_MSG_NEWKEYS sent [preauth]
debug1: expecting SSH2_MSG_NEWKEYS [preauth]
debug1: SSH2_MSG_NEWKEYS received [preauth]
debug1: KEX done [preauth]
debug1: userauth-request for user damian service ssh-connection method none [preauth]
debug1: attempt 0 failures 0 [preauth]
debug1: PAM: initializing for "damian"
debug1: PAM: setting PAM_RHOST to "freebox-server.local"
debug1: PAM: setting PAM_TTY to "ssh"
Connection closed by xxxx [preauth]
debug1: do_cleanup [preauth]
debug1: monitor_read_log: child log fd closed
debug1: do_cleanup

Hier ist die ausführliche Ausgabe von ssh:

$ ssh -v user@server
OpenSSH_7.1p1, OpenSSL 1.0.2d 9 Jul 2015
debug1: Connecting to server [xxxx] port 22.
debug1: Connection established.
debug1: key_load_public: No such file or directory
debug1: identity file /home/user/.ssh/id_rsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/user/.ssh/id_rsa-cert type -1
debug1: identity file /home/user/.ssh/id_dsa type 2
debug1: key_load_public: No such file or directory
debug1: identity file /home/user/.ssh/id_dsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/user/.ssh/id_ecdsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/user/.ssh/id_ecdsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/user/.ssh/id_ed25519 type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/user/.ssh/id_ed25519-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_7.1
debug1: Remote protocol version 2.0, remote software version OpenSSH_6.6.1p1 Ubuntu-2ubuntu2.3
debug1: match: OpenSSH_6.6.1p1 Ubuntu-2ubuntu2.3 pat OpenSSH_6.6.1* compat 0x04000000
debug1: Authenticating to server:22 as 'user'
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client chacha20-poly1305@openssh.com <implicit> none
debug1: kex: client->server chacha20-poly1305@openssh.com <implicit> none
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ecdsa-sha2-nistp256 SHA256:v4BNHM0Q33Uh6U4VHenA9iJ0wEyi8h0rFVetbcXBKqA
debug1: Host 'server' is known and matches the ECDSA host key.
debug1: Found key in /home/user/.ssh/known_hosts:2
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Trying private key: /home/user/.ssh/id_rsa
debug1: Skipping ssh-dss key /home/user/.ssh/id_dsa for not in PubkeyAcceptedKeyTypes
debug1: Trying private key: /home/user/.ssh/id_ecdsa
debug1: Trying private key: /home/user/.ssh/id_ed25519
debug1: Next authentication method: password
user@server's password:

Die neue OpenSh-Version (7.0+) hat DSA-Schlüssel als veraltet eingestuft und verwendet standardmäßig keine DSA-Schlüssel (nicht auf Server oder Client). Die Schlüssel werden nicht mehr bevorzugt verwendet, daher würde ich, wenn möglich, die Verwendung von RSA-Schlüsseln empfehlen .

Wenn Sie wirklich DSA-Schlüssel verwenden müssen, müssen Sie diese explizit in Ihrer Client-Konfiguration mit zulassen

PubkeyAcceptedKeyTypes +ssh-dss

Sollte ausreichen, um diese Zeile ~/.ssh/configeinzufügen, da die ausführliche Meldung versucht, es Ihnen mitzuteilen.

In meinem Fall trat dieses Problem auf, weil ein anderer Benutzer den AuthorizedKeysFileSpeicherort geändert hatte . Da es authorized_keysfür andere Benutzer an diesem Speicherort kein Kennwort gab, wurde für die Anmeldung standardmäßig das Kennwort verwendet, obwohl authorized_keyssie mit den richtigen Berechtigungen im Standardstartverzeichnis vorhanden war.

AuthorizedKeysFile   /etc/ssh/%u/authorized_keys

Kommentierte diese geänderte Zeile aus und startete den sshd-Dienst neu, um zur Standardeinstellung zurückzukehren, die es anderen Benutzern dann ermöglichte, sich mit ihren Schlüsseln zu authentifizieren.

Ich habe es mit Jakujes Antwort versucht. Kein Glück. Aber ich verstehe das Problem von dort. Versucht, Kommentar hinzuzufügen, aber Ruf, warum Hinzufügen von Antwort.

Aber die Konfigurationsdatei für mich / etc / ssh / ssh_config

1. sudo nano /etc/ssh/ssh_config
2. PubkeyAcceptedKeyTypes +ssh-dss Diese Zeile wurde unten hinzugefügt.
3. Speichern und erneut versuchen.

Hat funktioniert!

Nur um zusammenzufassen, was ich getan habe, um SSH Himbeer-Pi .

In Server-Maschine (Himbeer-Pi):

$ ip addr show 

oder einfach ip a, dies zeigt die IP-Adresse der Pi-Maschine an - host_ip

$ mkdir .ssh

Auf dem Client-Computer (Ubuntu):

$ ssh-keygen -t rsa  

Gutschrift an @Jakuje oben. Ich habe anfangs ssh-keygen -t dsa für die Schlüsselgenerierung verwendet, und ssh hat mich immer wieder nach dem Passwort gefragt. ssh -v IP-Adresse gibt mir nicht viele nützliche Informationen, bis ich @ Jakujes Antwort sah

$ cat .ssh/id_rsa.pub | ssh user_id@host_ip 'cat >> ~/.ssh/authorized_keys'  

Ersetzen Sie user_id und host_ip, und geben Sie bei Aufforderung das Kennwort für die Pi-Maschine an

$ ssh user@ip_address

erfolgreich in PI eingeloggt, kein Passwort mehr

dsa hat bei mir nicht funktioniert. rsa tat es.

ssh-keygen -t rsa -P '' -f ~/.ssh/id_rsa
cat /Users/user_name/.ssh/id_dsa.pub >> ~/.ssh/authorized_keys

Und ich kann ohne Passwort ssh.