L'accesso SSH tramite la chiave pubblica non è riuscito

Sul servizio sshd di localhost. Creato due paia di rsa chiavi per root e user1 usando ssh-keygen. Copiato da root / .ssh / id_rsa.pub a user1 / .ssh / id_rsa.pub. Permessi modificati a 600. Provato ssh -l user1 localhost e ssh -l root localhost ma entrambi sono falliti con Permission denied (publickey, keyboard-interactive). . Devo copiare la chiave pubblica nella cartella ~/.ssh per entrambi gli utenti? Cosa non va nella configuration? Perché non riesco a connettersi a localhost?

File /etc/ssh/sshd_config :

 RSAAuthentication yes PubkeyAuthentication yes PasswordAuthentication yes UsePAM no AllowUsers user1 root PermitRootLogin yes 

Nel file /etc/ssh/ssh_config sono righe non commentate:

  RSAAuthentication yes PasswordAuthentication no ForwardX11 no SendEnv LANG LC_* HashKnownHosts yes GSSAPIAuthentication yes GSSAPIDelegateCredentials no PubkeyAuthentication yes 

EDIT 1

Sto cercando di connettersi a localhost. Devo essere in grado di accedere all'utente1 utilizzando solo la chiave pubblica mentre è ansible accedere come root con chiave pubblica e / o password.


EDIT 2

Ho copiato cp ~/.ssh/id_rsa.pub /home/user1/.ssh/authorized_keys . Modificato le autorizzazioni chmod -R 700 ~/.ssh e chmod -R 700 /home/user1/.ssh . Riavviato ssh 'servizio ssh restart'. Ma sembra non funzionare.


EDIT 4

 root@ubuntu:~# ssh-copy-id user1@localhost The authenticity of host 'localhost (127.0.0.1)' can't be established. ECDSA key fingerprint is 34:29:b6:1b:fe:84:eb:82:85:77:87:f6:25:39:61:5a. Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added 'localhost' (ECDSA) to the list of known hosts. Permission denied (publickey,keyboard-interactive). root@ubuntu:~# ssh-copy-id root@localhost Permission denied (publickey,keyboard-interactive). 

log:

 # tail /var/log/auth.log ... ubuntu sshd[8476]: User root not allowed because account is locked 

Un buon articolo di troubleshoot SSH: Problemi e soluzioni

  • come utilizzare Parallel SSH con le istanze Amazon EC2?
  • L'inoltro della port remota SSH non è riuscito
  • Desktop remoto tramite SSH a Windows 7 box
  • Posso lasciare i collegamenti SSH dopo cinque secondi?
  • ssh su Ubuntu non riesce dopo la prima volta: routes asimmetrici, la connessione SSH non riesce a stabilire correttamente
  • OpenSSH come server SFTP: Trigger i cambiamenti riusciti e difettosi
  • MTU sul server accidentalmente impostato su 0, non può ssh in esso?
  • scp e rsync non funzionano (lavori ssh)
  • 6 Solutions collect form web for “L'accesso SSH tramite la chiave pubblica non è riuscito”

    Mi sono imbattuto in questo problema quando ho cercato di accedere a un account che non ha alcuna password, anche se utilizzo l'authentication dei pacchetti chiave SSH e ho distriggersto l'accesso alla password. La soluzione era quella di impostare una password utilizzando il mio account principale:

     passwd user1 Enter new UNIX password: Retype new UNIX password: passwd: password updated successfully 
    1. Ogni volta che incontri un problema con un server, è sempre meglio aggiungere il flag -v , ad esempio

       $ ssh -v host -l user 
    2. In entrambi i casi precedenti, la chiave pubblica ( id_rsa.pub ) deve essere aggiunta al file ".ssh / authorized_keys" dell'utente remoto. Nel tuo caso sopra, sia per root che user1. Ciò può essere fatto facilmente tramite il command ssh-copy-id .

    3. /var/log/secure terrà indizi su come il login non è riuscito.

    4. Le autorizzazioni di directory dovrebbero essere 700 [rwx] (non 600) [rw-]

    Mi sono imbattuto in un simile problema un po 'di riprova provando a fare

     chmod -R 600 ~/.ssh 

    Apparentemente se le autorizzazioni di file sono corrette, ma le autorizzazioni di directory non sono gli stessi tipi di errori di autorizzazioni possono rivelarsi.

    Ritengo anche che sia necessario rinominare il file da id_rsa.pub a keys_author_.

    Alcune note: poiché hai distriggersto specificamente l'authentication della password, non puoi accedere con la password. Credo che dovrai configurare gli utenti consentiti con un altro (l'utente corrispondente è forse il modo migliore per andare avanti). Inoltre, è necessario specificare specificamente l'utente root (PermitRootLogin impostarlo su sì).

    Sarebbe opportuno fornire ulteriori informazioni sulle impostazioni in /etc/ssh/sshd_config , in particolare StrictModes ( grep StrictModes /etc/ssh/sshd_config ). StrictModes è l'impostazione che regola come sshd sensibile reagisce alle autorizzazioni di file e cartelle dei rispettivi ~/.ssh e ~/.ssh/authorized_keys di ciascun utente. Anche tu non hai dato l'impostazione di AuthorizedKeysFile nel tuo sshd_config . Molto rilevante, se il tuo server SSH sta cercando il file da qualche altra parte di quello che lo metti.

    Ma a parte le risposte finora, ci può essere una moltitudine di ragioni per questo. Il problema è che, anche se hai provato, non ci sono informazioni sufficienti per fare una sicura indovinata cosa è sbagliato.

    Una cosa più importnte può essere le restrizioni PAM ( UsePAM in sshd_config ). Ubuntu ha usato adesso che ad un certo punto. Se l'account utente non ha impostato una password (solo authentication chiave pubblica), non è consentito.

    Ma lasciathemes dare un metodo generico per eseguire il debug di tali problemi.

    Risoluzione dei problemi generali di sshd

    Quello che trovo generalmente molto utile in questi casi è quello di avviare sshd senza lasciarlo demoniare ("andare in background e staccarsi dal terminal"). Spesso i registri non saranno eccessivamente utili, in particolare quando si dispone di un errore di configuration (che non è alless il caso ovvio).

    Lo si avvia dal terminal come quello:

     # $(which sshd) -Ddp 10222 

    Questo ti darà un sacco di output di debug che altrimenti non appariranno (senza il -d ) o finiranno nei registri se sei fortunato.

    NB: il $(which sshd) è il metodo migliore per soddisfare il requisito sshd di un path assoluto. Altrimenti avrai il seguente errore: sshd re-exec requires execution with an absolute path . Il -p 10222 fa sshd ascoltare su quella port alternativa, sovrascrivendo il file di configuration – questo è in modo che non si scontra con le istanze sshd potenzialmente in esecuzione. Assicuratevi di scegliere un porto gratuito qui.

    Questo metodo mi ha aiutato parecchie volte nel trovare problemi, siano esse problemi di authentication, problemi di performance o altri tipi di problemi. Per get l'output verboso a stdout , utilizzare $(which sshd) -Ddddp 10222 (nota l'aggiunta di dd per aumentare la verbosità). Per ulteriori debug di bontà controllare l' man sshd .

    Sul lato client ssh può prendere -v (fino a -vvv ) per essere davvero verboso su ciò che sta facendo.


    La linea di registro

     ... ubuntu sshd[8476]: User root not allowed because account is locked 

    suggerisce che questo è il problema, quindi correre:

     sudo passwd -u root 

    Su CentOS, selinux può bloccare l'authentication. Per risolvere il problema utilizzando il command:

     restorecon -Rv ~ /. ssh 
    Suggerimenti per Linux e Windows Server, quali Ubuntu, Centos, Apache, Nginx, Debian e argomenti di rete.