L'aggiunta della chiave pubblica a ~/.ssh/autorizzata_keys non mi accede automaticamente

Question

Ho aggiunto la chiave SSH pubblica al file autorizzato_keys. ssh localhost Dovrei accedere senza chiedere la password.

L'ho fatto e ho provato a digitare ssh localhost, ma mi chiede ancora di digitare la password. C'è qualche altra impostazione che devo passare per farlo funzionare?

Ho seguito le istruzioni per la modifica delle autorizzazioni:

Di seguito è riportato il risultato se lo faccio ssh -v localhost

debug1: Reading configuration data /home/john/.ssh/config
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to localhost [127.0.0.1] port 22.
debug1: Connection established.
debug1: identity file /home/john/.ssh/identity type 1
debug1: identity file /home/john/.ssh/id_rsa type -1
debug1: identity file /home/john/.ssh/id_dsa type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_4.7p1 Debian-8ubuntu3
debug1: match: OpenSSH_4.7p1 Debian-8ubuntu3 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_4.7p1 Debian-8ubuntu3
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-cbc hmac-md5 none
debug1: kex: client->server aes128-cbc hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host 'localhost' is known and matches the RSA host key.
debug1: Found key in /home/john/.ssh/known_hosts:12
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
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: Offering public key: /home/john/.ssh/identity
debug1: Server accepts key: pkalg ssh-rsa blen 149
debug1: PEM_read_PrivateKey failed
debug1: read PEM private key done: type <unknown>

Quindi chiede passphase dopo il registro sopra. Perché non mi accede senza password?

Answer 1

È necessario verificare le autorizzazioni del authorized_keys File e le cartelle della cartella / parente in cui si trova.

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

Per ulteriori informazioni, vedere questa pagina.

Potrebbe anche essere necessario modificare/verificare le autorizzazioni della tua home directory per rimuovere l'accesso alla scrittura per il gruppo e altri.

chmod go-w ~

Answer 2

Selinux può anche causare il funzionamento di Authorized_Keys. Soprattutto per la radice in CentOS 6 e 7. Non è necessario disabilitarlo. Dopo aver verificato le autorizzazioni sono corrette, puoi risolverlo così:

chmod 700 /root/.ssh
chmod 600 /root/.ssh/authorized_keys
restorecon -R -v /root/.ssh

Answer 3

ambientazione ssh autorizzato_keys sembra essere semplice ma nasconde alcune trappole che sto cercando di capire

-- SERVER --

in /etc/ssh/sshd_config impostare passwordAuthentication yes Per consentire al server temporaneo accettare l'autenticazione della password

-- CLIENTE --

ritenere Cygwin Come emulazione Linux e installa e esegui OpenSsh

1. generare chiavi private e pubbliche (lato cliente)# ssh-keygen

Qui premendo, basta entrare PREDEFINITO2 file "id_RSA" e "ID_RSA.PUB" in ~/.ssh/ Ma se dai un name_for_the_key I file generati vengono salvati nel tuo PWD

2. posiziona il your_key.pub alla macchina di destinazione ssh-copy-id user_name@host_name

Se non hai creato la chiave predefinita, questo è il primo passo per andare storto ... dovresti usare

ssh-copy-id -i path/to/key_name.pub user_name@host_name

3. registrazione ssh user_name@host_name Funzionerà solo per l'ID_RSA predefinito, quindi ecco la seconda trappola per essere necessario ssh -i path/to/key_name user@host

(uso ssh -v ... Opzione per vedere cosa sta succedendo)

Se Il server richiede ancora la password Poi hai dato Smth. a Inserisci passphrase: Quando hai creato le chiavi (quindi è normale)

Se SSH non ascolta la porta predefinita 22 deve utilizzare ssh -p port_nr

-- SERVER -----

4. modificare /etc/ssh/sshd_config avere

RSAAuthentication yes
PubkeyAuthentication yes
AuthorizedKeysFile  %h/.ssh/authorized_keys

(Caso insolito se)

Questo dice a SSH di accettare Authorized_keys e cercare nella home directory utente per Key_name Sting scritto nel file .ssh/autorizzato_keys

5 Imposta le autorizzazioni nella macchina target

chmod 755 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

Anche spegnere il passaggio autentico

passwordAuthentication no

Per chiudere il cancello a tutti i tentativi di root/admin/#@ your_domain

6 Garantire la proprietà e la proprietà del gruppo di tutte le directory di case non root siano appropriate.

chown -R ~ usernamehere
chgrp -R ~/.ssh/ user 

===============================================

7. Considera l'eccezionale http://www.fail2ban.org

8. extratunnel ssh Per accedere a un mysql (bind = 127.0.0.1)

Answer 4

Assicurati anche che la tua home directory non sia scrivibile da altri

chmod g-w,o-w /home/USERNAME

La risposta viene rubata da qui

Answer 5

Il disperato potrebbe anche assicurarsi di non avere neotine extra nel file Authorized_Keys a causa della copia del testo ID_RSA.PUB da un terminale confuso.

Answer 6

La quotazione di una chiave pubblica in .ssh/Authorized_keys è necessaria ma non sufficiente per SSHD (server) per accettarla. Se la tua chiave privata è protetta da passphrase, dovrai dare ogni volta SSH (client) la passphrase. Oppure puoi usare SSH-agent o un equivalente gnome.

La tua traccia di aggiornamento è coerente con una chiave privata protetta da passphrase. Vedi ssh-agent o ssh-keygen -p.

Answer 7

Fai attenzione che anche Selinux possa attivare questo errore, anche se tutte le autorizzazioni sembrano essere OK. Disabilitarlo ha fatto il trucco per me (inserire i soliti disclaimer sulla disabilitazione).

Answer 8

L'utente è il tuo nome utente

mkdir -p /home/user/.ssh
ssh-keygen -t rsa
touch /home/user/.ssh/authorized_keys
touch /home/user/.ssh/known_hosts
chown -R user:user /home/user/.ssh
chmod 700 /home/user/.ssh
chmod 600 /home/user/.ssh/id*
chmod 644 /home/user/.ssh/id*.pub
chmod 644 /home/user/.ssh/authorized_keys
chmod 644 /home/user/.ssh/known_hosts

Answer 9

La cosa che ha fatto il trucco per me finalmente era assicurarsi che il Proprietario/gruppo non erano root ma utente:

chown -R ~/.ssh/ user
chgrp -R ~/.ssh/ user 

Answer 10

Comando scrivi:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

Dopo averlo fatto, assicurati che il tuo dir sia così:

drwx------ 2 lab lab 4.0K Mar 13 08:33 .
drwx------ 8 lab lab 4.0K Mar 13 08:07 ..
-rw------- 1 lab lab  436 Mar 13 08:33 authorized_keys
-rw------- 1 lab lab 1.7K Mar 13 07:35 id_rsa
-rw-r--r-- 1 lab lab  413 Mar 13 07:35 id_rsa.pub

Answer 11

Prova "SSH-ADD" che ha funzionato per me.

Answer 12

Un altro consiglio da ricordare. Da V7.0 OpenSsh disabilita DSS/DSA SSH Keys per impostazione predefinita a causa della loro debolezza ereditaria. Quindi, se hai OpenSsh v7.0+, assicurati che la chiave non lo sia ssh-dss.

Se sei bloccato con le chiavi DSA, puoi riaccendere il supporto a livello locale aggiornando il tuo sshd_config e ~/.ssh/config file con righe come così: PubkeyAcceptedKeyTypes=+ssh-dss

Answer 13

Nel mio caso avevo bisogno di mettere il mio authorized_keys file in .openssh.

Questa posizione è specificata in /etc/ssh/sshd_config sotto l'opzione AuthorizedKeysFile %h/.ssh/authorized_keys.

Answer 14

Assicurarsi che l'utente di destinazione abbia una password impostata. Correre passwd username per impostarne uno. Questo era necessario per me anche se l'accesso SSH password era disabilitato.

Answer 15

Questo risolve il mio problema

SSH-Agent Bash

ssh-add

Answer 16

Un altro problema che devi prenderti cura. Se il tuo file generato non è predefinitoid_rsa e id_rsa.pub

È necessario creare file .ssh/config e definire manualmente quale file ID si utilizza con la connessione.

L'esempio è qui:

host remote_host_name
hostname 172.xx.xx.xx
user my_user
IdentityFile /home/my_user/.ssh/my_user_custom.pub

Answer 17

Ho emesso sudo chmod 700 ~/.ssh e chmod 600 ~/.ssh/authorized_keys e chmod go-w $HOME $HOME/.ssh Dall'alto e ha risolto il mio problema su una scatola CentOS7 su cui avevo incasinato le autorizzazioni mentre cercavo di far funzionare le condivisioni di Samba. Grazie

Answer 18

Sembra un problema di autorizzazione. Di solito accade se l'autorizzazione di alcuni file/directory non è impostata correttamente. Nella maggior parte dei casi lo sono ~/.ssh e ~/.ssh/*. Nel mio caso lo sono /home/xxx.

È possibile modificare il livello di registro di SSHD modificando /etc/ssh/sshd_config(ricerca LogLevel, impostalo su DEBUG), quindi controlla l'output /var/log/auth.log Per vedere cosa è successo esattamente.

Answer 19

Il mio problema era un ModifiedKeyysfile, quando l'automazione per popolare/etc/ssh/autorized_keys non era ancora stata eseguita.

$sudo grep AuthorizedKeysFile /etc/ssh/sshd_config
#AuthorizedKeysFile .ssh/authorized_keys
AuthorizedKeysFile  /etc/ssh/authorized_keys/%u

Answer 20

Basta guardare /var/log/auth.log sul server. Impostazione della verbosità aggiuntiva con -vv Sul lato client non aiuterà, perché è improbabile che il server offra troppe informazioni a un possibile attaccante.

Answer 21

Assicurati di aver copiato l'intera chiave pubblica authorized_keys; il ssh rsa Il prefisso è necessario per la chiave di lavoro.

Answer 22

È necessario verificare le proprietà dei file. Per assegnare l'uso della proprietà richiesto:

$ chmod 600 ~/.ssh/sshKey
$ chmod 644 ~/.ssh/sshKey.pub

Answer 23

In quella nota, assicurati che la configurazione sshd abbia -;

PermitRootLogin without-password

Impostare come sopra, quindi riavviare sshd (/etc/init.d/ssshd riavvio)

Accedi e prova di nuovo accedi!

predefinito credo sia -;

PermitRootLogin no

Answer 24

Nel mio caso è perché il gruppo dell'utente non è impostato nei gruppi di consumo del file di configurazione/etc/ssh/sshd_config. Dopo averlo aggiunto, tutto funziona bene.

Answer 25

Ho la directory home in una posizione non standard e in sshd registri ho questa riga:

Could not open authorized keys '/data/home/user1/.ssh/authorized_keys': Permission denied

Anche se tutte le autorizzazioni andavano bene (vedi le altre risposte).

Ho trovato una soluzione qui: http://arstechnica.com/civis/viewtopic.php?p=2581319191&sid=0876f069ec2aa5fdcd691a2e2e7242c2#p25813191

Nel mio caso particolare:

• ha aggiunto una nuova riga in /etc/selinux/targeted/contexts/files/file_contexts.homedirs:

  • Questa è la linea originale per le normali directory di case:

    /home/[^/]*/\.ssh(/.*)? unconfined_u:object_r:ssh_home_t:s0

  • Questa è la mia nuova riga:

    /data/home/[^/]*/\.ssh(/.*)? unconfined_u:object_r:ssh_home_t:s0

• seguito da a restorecon -r /data/ e a sshd ricomincia

Answer 26

Ho avuto questo problema e nessuna delle altre risposte lo ha risolto, anche se ovviamente le altre risposte sono corretta.

Nel mio caso, ha scoperto che il /root directory stessa (non ad esempio /root/.ssh) aveva le autorizzazioni sbagliate. Avevo bisogno:

chown root.root /root
chmod 700 /root

Certo, quelle autorizzazioni dovrebbero essere qualcosa del genere (forse chmod 770) indipendentemente. Tuttavia, ha impedito specificamente sshd dal lavoro, anche se /root/.ssh e /root/.ssh/authorized_keys Entrambi avevano autorizzazioni e proprietari corretti.

Answer 27

Guarda a /var/log/auth.log sul server per sshd errori di autenticazione.

Se tutto il resto fallisce, esegui il sshd server in modalità debug:

sudo /usr/sbin/sshd -ddd -p 2200

Quindi connettiti dal client:

ssh user@host -p 2200

Nel mio caso ho trovato la sezione di errore alla fine:

    debug1: userauth_pubkey: test whether pkalg/pkblob are acceptable for RSA SHA256:6bL+waAtghY5BOaY9i+pIX9wHJHvY4r/mOh2YaL9RvQ [preauth]
==> debug2: userauth_pubkey: disabled because of invalid user [preauth]
    debug2: userauth_pubkey: authenticated 0 pkalg ssh-rsa [preauth]
    debug3: userauth_finish: failure partial=0 next methods="publickey,password" [preauth]
    debug3: send packet: type 51 [preauth]
    debug3: receive packet: type 50 [preauth]

Con queste informazioni mi sono reso conto che il mio sshd_config stava limitando gli accessi ai membri del ssh gruppo. Il comando seguente ha risolto questo errore di autorizzazione:

sudo usermod -a -G ssh NEW_USER

Answer 28

Ho avuto questo problema quando ho aggiunto il gruppo dell'utente di accesso a un altro utente. Diciamo che esiste un utente SSH-Login chiamato USERA e un utente Utente non SSH-Login. Usera ha anche il gruppo usera. Ho modificato UserB per avere anche il gruppo USERA. Il vantaggio al comportamento descritto, in modo che USERA non sia stato in grado di accedere senza un prompt. Dopo aver rimosso il gruppo USERA da UserB, l'accesso senza prompt ha funzionato di nuovo.