Errore di autenticazione senza password SSH

0

Sto provando a ssh due macchine e preferirei usare le chiavi generate per l'autenticazione piuttosto che la password. Questo mi permetterà di automatizzare il port forwarding e molte altre cose.

Nota: il mio server è debian.

Di seguito è quello che ho fatto.

Ho generato la chiave:
```
ssh-keygen -t dsa
```
Copiato id_dsa.pub sul ~ / .ssh del server remoto
ssh-add -D per cancellare le vecchie chiavi. Ragazzi, non ne avevo bisogno
ssh-add ~ / .ssh / id_dsa per aggiungere l'id privato 5. provato a connettersi al server esterno come

ssh root @ remote-ip
Ho ancora accettato la password anche dopo la mia accettazione da aggiungere su host noti.
Ho provato ssh -vvv root @ remote-ip e log ottenere di seguito.

OpenSSH_5.8p1 Debian-7ubuntu1, OpenSSL 1.0.0e 6 set 2011
debug1: lettura dei dati di configurazione / etc / ssh / ssh_config
debug1: applicazione delle opzioni per *
debug2: ssh_connect: needpriv 0
debug1: connessione alla porta 18765 184.154.191.58 [184.154.191.58].
debug1: connessione stabilita.
debug1: file di identità /home/eclipse/.ssh/id_rsa tipo -1
debug1: file di identità /home/eclipse/.ssh/id_rsa-cert tipo -1
debug1: file di identità /home/eclipse/.ssh/id_dsa tipo 2
debug1: Verifica del file della blacklist /usr/share/ssh/blacklist.DSA-1024
debug1: Verifica del file della blacklist /etc/ssh/blacklist.DSA-1024
debug1: file di identità /home/eclipse/.ssh/id_dsa-cert tipo -1
debug1: file di identità /home/eclipse/.ssh/id_ecdsa tipo -1
debug1: file di identità /home/eclipse/.ssh/id_ecdsa-cert tipo -1
debug1: protocollo remoto versione 2.0, versione software remota OpenSSH_4.3
debug1: match: OpenSSH_4.3 pat OpenSSH_4 *
debug1: abilitazione della modalità di compatibilità per il protocollo 2.0
debug1: stringa di versione locale SSH-2.0-OpenSSH_5.8p1 Debian-7ubuntu1
debug2: impostazione fd 3 O_NONBLOCK
debug3: put_host_port: [184.154.191.58]: 18765
debug3: load_hostkeys: caricamento voci per host "[184.154.191.58]: 18765" dal file "/home/eclipse/.ssh/known_hosts"
debug3: load_hostkeys: trovato il tipo di chiave RSA nel file /home/eclipse/.ssh/known_hosts:3
debug3: load_hostkeys: caricato 1 chiavi
debug3: order_hostkeyalgs: preferisci hostkeyalgs: ssh-rsa-cert-v01 @ openssh.com, ssh-rsa-cert-v00 @ openssh.com, ssh-rsa
debug1: SSH2_MSG_KEXINIT inviato
debug1: SSH2_MSG_KEXINIT ricevuto
debug2: kex_parse_kexinit: ecdh-sha2-nistp256, ecdh-sha2-nistp384, ecdh-sha2-nistp521, diffie-hellman-group-exchange-sha256, diffie-hellman-group-exchange-sha1, diffie-hellman-group14-sha1, Diffie-Hellman-Gruppo 1-SHA1
debug2: kex_parse_kexinit: ssh-rsa-cert-v01 @ openssh.com, ssh-rsa-cert-v00 @ openssh.com, ssh-rsa, ecdsa-sha2-nistp256-cert-v01 @ openssh.com, ecdsa-sha2- nistp384-cERT-V01 @ openssh.com, ECDSA-SHA2-nistp521-cERT-V01 @ openssh.com, ssh-dss-cERT-V01 @ openssh.com, ssh-dss-cERT-V00 @ openssh.com, ecdsa- SHA2-nistp256, ECDSA-SHA2-nistp384, ECDSA-SHA2-nistp521, ssh-dss
debug2: kex_parse_kexinit: aes128-ctr, aes192-ctr, aes256-ctr, arcfour256, arcfour128, aes128-cbc, 3des-cbc, blowfish-cbc, cast128-cbc, aes192-cbel-ab25c lysator.liu.se
debug2: kex_parse_kexinit: aes128-ctr, aes192-ctr, aes256-ctr, arcfour256, arcfour128, aes128-cbc, 3des-cbc, blowfish-cbc, cast128-cbc, aes192-cbel-ab25c lysator.liu.se
debug2: kex_parse_kexinit: hmac-md5, hmac-sha1, umac-64 @ openssh.com, hmac-ripemd160, hmac-ripemd160 @ openssh.com, hmac-sha1-96, hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5, hmac-sha1, umac-64 @ openssh.com, hmac-ripemd160, hmac-ripemd160 @ openssh.com, hmac-sha1-96, hmac-md5-96
debug2: kex_parse_kexinit: nessuno, zlib @ openssh.com, zlib
debug2: kex_parse_kexinit: nessuno, zlib @ openssh.com, zlib
debug2: kex_parse_kexinit: 
debug2: kex_parse_kexinit: 
debug2: kex_parse_kexinit: first_kex_follows 0 
debug2: kex_parse_kexinit: riservato 0 
debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha1, diffie-hellman-group14-sha1, diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa, ssh-dss
debug2: kex_parse_kexinit: aes128-ctr, aes192-ctr, aes256-ctr, arcfour256, arcfour128, aes128-cbc, 3des-cbc, blowfish-cbc, cast128-cbc, aes192-cbel-ab25c lysator.liu.se
debug2: kex_parse_kexinit: aes128-ctr, aes192-ctr, aes256-ctr, arcfour256, arcfour128, aes128-cbc, 3des-cbc, blowfish-cbc, cast128-cbc, aes192-cbel-ab25c lysator.liu.se
debug2: kex_parse_kexinit: hmac-md5, hmac-sha1, hmac-ripemd160, hmac-ripemd160 @ openssh.com, hmac-sha1-96, hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5, hmac-sha1, hmac-ripemd160, hmac-ripemd160 @ openssh.com, hmac-sha1-96, hmac-md5-96
debug2: kex_parse_kexinit: nessuno
debug2: kex_parse_kexinit: nessuno
debug2: kex_parse_kexinit: 
debug2: kex_parse_kexinit: 
debug2: kex_parse_kexinit: first_kex_follows 0 
debug2: kex_parse_kexinit: riservato 0 
debug2: mac_setup: trovato hmac-md5
debug1: kex: server-> client aes128-ctr hmac-md5 nessuno
debug2: mac_setup: trovato hmac-md5
debug1: kex: client-> server aes128-ctr hmac-md5 nessuno
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST (1024-1024-8192) inviato
debug1: in attesa di SSH2_MSG_KEX_DH_GEX_GROUP
debug2: dh_gen_key: bit chiave priv impostati: 125/256
debug2: bit impostati: 518/1024
debug1: SSH2_MSG_KEX_DH_GEX_INIT inviato
debug1: in attesa di SSH2_MSG_KEX_DH_GEX_REPLY
debug1: chiave host del server: RSA 5d: ce: fb: 75: de: 6f: 52: f9: ad: 41: e3: 92: 9a: 53: ee: f0
debug3: put_host_port: [184.154.191.58]: 18765
debug3: put_host_port: [184.154.191.58]: 18765
debug3: load_hostkeys: caricamento voci per host "[184.154.191.58]: 18765" dal file "/home/eclipse/.ssh/known_hosts"
debug3: load_hostkeys: trovato il tipo di chiave RSA nel file /home/eclipse/.ssh/known_hosts:3
debug3: load_hostkeys: caricato 1 chiavi
debug3: load_hostkeys: caricamento voci per host "[184.154.191.58]: 18765" dal file "/home/eclipse/.ssh/known_hosts"
debug3: load_hostkeys: trovato il tipo di chiave RSA nel file /home/eclipse/.ssh/known_hosts:3
debug3: load_hostkeys: caricato 1 chiavi
debug1: l'host '[184.154.191.58]: 18765' è noto e corrisponde alla chiave host RSA.
debug1: chiave trovata in /home/eclipse/.ssh/known_hosts:3
debug2: bit impostati: 514/1024
debug1: ssh_rsa_verify: firma corretta
debug2: kex_derive_keys
debug2: set_newkeys: mode 1
debug1: SSH2_MSG_NEWKEYS inviato
debug1: in attesa di SSH2_MSG_NEWKEYS
debug2: set_newkeys: mode 0
debug1: SSH2_MSG_NEWKEYS ricevuto
debug1: roaming non consentito dal server
debug1: SSH2_MSG_SERVICE_REQUEST inviato
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT ricevuto
debug2: chiave: /home/eclipse/.ssh/id_rsa ((zero))
debug2: chiave: /home/eclipse/.ssh/id_dsa (0x21b20e18)
debug2: chiave: /home/eclipse/.ssh/id_ecdsa ((zero))
debug1: autenticazioni che possono continuare: password, tastiera interattiva
debug3: ricominciare, ha passato una password di elenco diversa, interattiva da tastiera
debug3: gssapi-keyex preferito, gssapi-con-mic, chiave pubblica, tastiera interattiva, password
debug3: authmethod_lookup tastiera-interattivo
debug3: rimanendo preferito: password
debug3: authmethod_is_enabled tastiera-interattivo
debug1: metodo di autenticazione successivo: tastiera interattiva
debug2: userauth_kbdint
debug2: abbiamo inviato un pacchetto interattivo da tastiera, attendere la risposta
debug2: input_userauth_info_req
debug2: input_userauth_info_req: num_prompts 1
Parola d'ordine:

Gentilmente qualcuno mi aiuti.

— Felix Cheruiyot
fonte

1

Metti la chiave pubblica nel posto sbagliato. Sul server, le chiavi consentite sono memorizzate nel file ~/.ssh/authorized_keys, una chiave per riga. Il server SSH ignora tutti gli altri file in ~/.ssh.

(È possibile utilizzare per autorizzare facilmente la chiave.)ssh-copy-id <server>

Secondo, hai davvero corso sshd -De sshd id_dsa? Il comando è ssh-add:

ssh-add -D
ssh-add ~/.ssh/id_dsa

— grawity
fonte

Ci scusiamo per il fuorviante sul ssh-add. L'ho corretto. Ho eliminato e aggiunto bene.

— Felix Cheruiyot,

Forse wrong_keys sbagliato. Posso ssh-copy-id con l'opzione port.

— Felix Cheruiyot,

Non ho accesso alla porta 22 del server remoto. Ho provato ssh-copy-id xxx.xxx.xxx.xxx -p 18765. È falso tornare alla porta 22

— felix cheruiyot,

aggiornato

— le_proprietà

1

Nel corso degli anni ho passato troppo tempo a eseguire il debug di ssh auth senza chiave pubblica senza password, quindi volevo pubblicare alcuni suggerimenti per gli altri che si presentano:

Come pubblicato da mgorven, assicurarsi che le autorizzazioni dei file siano impostate correttamente sull'host remoto. Questo è il problema più comune nella mia esperienza.

    $ chown -R nome utente: nome utente ~ / .ssh
    $ chmod -R 700 ~ / .ssh

L'esecuzione di ssh dal client con "-v", "-vv" o "-vvv" mi ha dato molto output, ma non mi ha MAI detto quale configurazione sia sbagliata sul computer remoto. Probabilmente è per impedire che h4x0rs malvagi ottengano troppe informazioni o qualcosa del genere.
Se si dispone dell'accesso fisico (non ssh) al computer remoto, è possibile provare a interrompere il servizio sshd ed eseguire sshd manualmente con il flag "-d" per inviare informazioni di debug alla console.
L'impostazione dell'autent senza password per root è un no-no di sicurezza, ma se si desidera ancora farlo, provare prima a impostare un utente non root. Quindi se hai problemi ad abilitarlo per root, saprai che è responsabile un'impostazione specifica per gli account root / sysadmin.
Controlla se SELinux è abilitato. Se lo è, potrebbe interferire. Soprattutto se stai provando a configurare l'autent senza password per un account superutente.

Speriamo che questo salverà le persone del tempo frustrante per la risoluzione dei problemi che ssh ha inflitto al resto di noi.

— RyanHennig
fonte

1

Non dovrebbe essere $ chown -R username:username ~/.ssh?

— user20342

L'accesso senza password per root NON è un no-no, è preferito alle password! È meglio attivare l'accesso con chiave e disattivare l'accesso con password per root.

— Chloe,

0

OpenSSH è molto attento alle autorizzazioni dei file. Assicurati che /root/.sshtutto sia di proprietà dell'utente corretto ed è leggibile e scrivibile solo dal proprietario.

chown -R root:root /root/.ssh
chmod -R u=rwX,g=,o= /root/.ssh

Se il problema persiste, incolla il contenuto /var/log/auth.loge possibilmente /var/log/syslogsul server durante il tentativo di accesso.

— mgorven
fonte

0

provare

ssh-copy-id [user@]hostname

ti verrà richiesta una volta la password dell'utente remoto, inseriscila e dovresti essere sul server remoto, disconnettersi e riconnettersi. Non è richiesta alcuna password.

* controlla anche le autorizzazioni dei file come indicato nelle altre risposte.

spero che sia d'aiuto

— Sean Davey
fonte