SSH continua a saltare il mio pubkey e chiedere una password


52

Ogni volta che utilizzo SSH sul mio server remoto, devo fornire la password. Ho copiato la mia chiave pubblica (id_dsa.pub) sul server remoto usando:

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

Ho verificato che sia stato correttamente aggiunto a authorized_keys. Tutte le autorizzazioni per file / directory sono corrette:

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

Il campo PasswordAuthentication in / etc / ssh / sshd_config è impostato su yes. Ho messo sshd in modalità debug e ho aggiunto il comando dettagliato al comando ssh. Ho l'impressione che il server non abbia provato a usare id_pub.dsa a causa della linea

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

Non è presente alcun disco crittografato sul lato server. Qualche idea su come progredire? Ecco le informazioni di debug del demone ssh:

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

Ecco l'output dettagliato 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:

1
Vedi anche superuser.com/q/1016989/93541 per lo stesso problema (e sostanzialmente la stessa soluzione).
DW,

Nota che se sshd_config sulla destinazione ha PubkeyAuthentication no , ti verrà sempre richiesta una password. Impostalo su yes e riavvia sshd (sull'host di destinazione) per abilitare l'autenticazione pubkey.
C. Kelly,

Risposte:


84

La nuova versione openssh (7.0+) ha deprecato le chiavi DSA e non utilizza le chiavi DSA per impostazione predefinita (non sul server o sul client). Le chiavi non sono più preferite per essere utilizzate, quindi se possibile, consiglierei di usare le chiavi RSA ove possibile.

Se hai davvero bisogno di usare le chiavi DSA, devi autorizzarle esplicitamente nella configurazione del tuo client usando

PubkeyAcceptedKeyTypes +ssh-dss

Dovrebbe essere sufficiente per inserire quella riga ~/.ssh/config, come il messaggio dettagliato sta cercando di dirti.


5
+1, ma un consiglio migliore sarebbe di usare un altro tipo di chiave, non deprecato, ...
jasonwryan,

@jasonwryan Grazie per il commento. Certamente. Aggiornerò la risposta.
Jakuje,

Grazie Jakuje! Questo ha senso, non mi ero reso conto che dsa era oldhat. Ho generato una nuova coppia di chiavi ssh-keygenrsa è l'impostazione predefinita ora. Proverò ad accedere con questo dall'altra macchina domani.
Damo,

Se ~/.ssh/confignon esisti, crealo. E ricordatevi di impostare le autorizzazioni corect: chmod 600 ~/.ssh/config.
Florian Brucker,

@knb non farlo. Eviterà di utilizzare qualsiasi altro algoritmo in futuro, poiché hai rimosso tutti gli algoritmi della curva ellittica.
Jakuje,

2

Nel mio caso, ho riscontrato questo problema perché un altro utente aveva modificato la AuthorizedKeysFileposizione. Dal momento che non esisteva authorized_keysper altri utenti in questa posizione, per impostazione predefinita il login sarebbe password, anche se authorized_keysesisteva con le autorizzazioni corrette nella home directory predefinita.

AuthorizedKeysFile   /etc/ssh/%u/authorized_keys

Ha commentato questa linea modificata e riavviato il servizio sshd per tornare alle impostazioni predefinite, che hanno poi permesso agli altri utenti di autenticarsi usando le loro chiavi.


Ho appena risolto un problema simile su un sistema RHEL7 in cui il contesto SELinux non era correttamente inizializzato sul homedir dell'utente, quindi ssh non era in grado di leggere il file delle chiavi autorizzato nonostante le autorizzazioni standard. Alla fine ho finito restorecon -Rv /homeper correggerlo per gli altri utenti che erano anche impostati in modo errato sullo stesso sistema.
dannysauer,

1

Ho provato la risposta di Jakuje Nessuna fortuna. Ma capisco il problema da lì. Ho cercato di aggiungere un commento, ma ho bisogno di reputazione per cui l'aggiunta di anwser.

Ma il file di configurazione per me / etc / ssh / ssh_config

  1. sudo nano /etc/ssh/ssh_config
  2. PubkeyAcceptedKeyTypes +ssh-dss Aggiunta questa riga in fondo.
  3. Salva e riprova.

Lavorato!


1

Solo per riassumere quello che ho fatto al fine di SSH a Raspberry Pi .

Nella macchina server (raspberry Pi):

$ ip addr show 

o semplicemente ip a, questo mostrerà l'indirizzo IP della macchina Pi - host_ip

$ mkdir .ssh

Nella macchina client (ubuntu):

$ ssh-keygen -t rsa  

Ringraziamo @Jakuje sopra. Inizialmente stavo usando ssh-keygen -t dsa per la generazione delle chiavi e ssh continuava a chiedermi la password. ssh -v ip-address non mi dà molte informazioni utili, finché non ho visto la risposta di @ Jakuje

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

sostituire user_id e host_ip, quando richiesto, fornire la password per la macchina Pi

$ ssh user@ip_address

accesso riuscito a PI, non più password


0

dsa non ha funzionato per me. rsa ha fatto.

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

E posso ssh senza password.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.