L'aggiunta di una chiave pubblica a ~ / .ssh / authorized_keys non mi accede automaticamente

Ho aggiunto la chiave SSH pubblica al file authorized_keys . ssh localhostdovrei accedere senza chiedere la password.

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

Ho seguito le istruzioni per modificare le 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 richiede una passphase dopo il registro sopra. Perché non mi sta effettuando l'accesso senza una password?

È necessario verificare le autorizzazioni del authorized_keysfile e delle cartelle / cartelle principali in cui si trova.

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

Per maggiori informazioni vedi questa pagina .

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

chmod go-w ~

SELinux può anche causare il mancato funzionamento di authorized_keys. Soprattutto per root in CentOS 6 e 7. Non è necessario disabilitarlo. Dopo aver verificato che le tue autorizzazioni siano corrette, puoi risolverlo in questo modo:

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

l'impostazione di ssh authorized_keys sembra essere semplice ma nasconde alcune trappole che sto cercando di capire

-- SERVER --

in / etc / ssh / sshd_config impostato passwordAuthentication yesper consentire al server di accettare temporaneamente l'autenticazione della password

-- CLIENTE --

considera cygwin come emulazione di Linux e installa ed esegui openssh

1. genera chiavi private e pubbliche (lato client) # ssh-keygen

qui premendo semplicemente INVIO si ottengono i file DEFAULT 2 " id_rsa " e " id_rsa.pub " in ~ / .ssh / ma se si dà un nome_per_la_chiave i file generati vengono salvati nel pwd

2. posizionare your_key.pub sul computer di destinazionessh-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. la registrazione ssh user_name@host_namefunzionerà solo per id_rsa predefinito, quindi ecco la seconda trap di cui hai bisognossh -i path/to/key_name user@host

(usa l' opzione ssh -v ... per vedere cosa sta succedendo)

Se il server richiede ancora la password, hai fornito smth. a Inserisci la passphrase: quando hai creato le chiavi (quindi è normale)

se ssh non è in ascolto, la porta 22 di default deve usare ssh -p port_nr

-- SERVER -----

4. modifica / etc / ssh / sshd_config per avere

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

(insolito in caso)

Questo dice a ssh di accettare authorized_keys e di cercare nella directory home dell'utente lo sting key_name scritto nel file .ssh / authorized_keys

5 impostare le autorizzazioni nel computer di destinazione

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

Disattiva anche l'autenticazione pass

passwordAuthentication no

per chiudere il gate a tutti i tentativi ssh root / admin /....@ your_domain

6 assicurarsi che la proprietà e la proprietà del gruppo di tutte le home directory non root siano appropriate.

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

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

7. considera l'eccellente http://www.fail2ban.org

8. TUNNEL extra ssh per accedere a un server MySQL (bind = 127.0.0.1)

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

il disperato può anche assicurarsi di non avere nuove righe extra nel file authorized_keys a causa della copia del testo id_rsa.pub da un terminale confuso.

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

Attenzione che SELinux può anche attivare questo errore, anche se tutte le autorizzazioni sembrano essere a posto. Disabilitarlo ha fatto il trucco per me (inserire le solite dichiarazioni di non responsabilità sulla disabilitazione).

È necessario elencare una chiave pubblica in .ssh / authorized_keys , ma non è sufficiente per accettarla da sshd (server). Se la tua chiave privata è protetta da passphrase, dovrai sempre dare a ssh (client) la passphrase. Oppure puoi usare ssh-agent o un equivalente GNOME.

La traccia aggiornata è coerente con una chiave privata protetta da passphrase. Vedi ssh-agent o use ssh-keygen -p.

Comando di scrittura:

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

Dopo aver fatto questo, assicurati che la tua directory 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

La cosa che alla fine mi ha aiutato è stata assicurarmi che il proprietario / gruppo non fosse root ma utente:

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

Prova "ssh-add" che ha funzionato per me.

Un altro consiglio da ricordare. Poiché v7.0 OpenSSH disabilita le chiavi SSH DSS / DSA per impostazione predefinita a causa della loro debolezza ereditaria. Quindi, se hai OpenSSH v7.0 +, assicurati che la tua chiave non lo sia ssh-dss.

Se sei bloccato con le chiavi DSA, puoi riattivare il supporto localmente aggiornando il tuo sshd_confige i ~/.ssh/configfile con linee in questo modo:PubkeyAcceptedKeyTypes=+ssh-dss

Nel mio caso, dovevo inserire il mio authorized_keysfile .openssh.

Questa posizione è specificata /etc/ssh/sshd_configsotto l'opzione AuthorizedKeysFile %h/.ssh/authorized_keys.

Assicurarsi che l'utente di destinazione abbia una password impostata. Corri passwd usernameper impostarne uno. Questo è stato richiesto per me anche se il login SSH con password è stato disabilitato.

questo risolve il mio problema

ssh-agent bash

ssh-add

Un altro problema che devi risolvere. Se il file generato non è predefinito id_rsa e id_rsa.pub

Devi creare il file .ssh / config e definire manualmente quale file id userai 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

Ho emesso sudo chmod 700 ~/.sshe chmod 600 ~/.ssh/authorized_keyse chmod go-w $HOME $HOME/.sshdall'alto ed è risolto il mio problema su una scatola CentOS7 che avevo incasinato i permessi durante il tentativo di ottenere samba azioni di lavoro. Grazie

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

Puoi cambiare il livello di registro di sshd modificando /etc/ssh/sshd_config(cerca LogLevel, impostalo su DEBUG), quindi controlla l'output /var/log/auth.logper vedere cosa è successo esattamente.

Il mio problema era un file AuthorizedKeys modificato, quando l'automazione per popolare / etc / ssh / authorized_keys non era ancora stata eseguita.

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

Basta guardare su /var/log/auth.log sul server . L'impostazione di ulteriori dettagli con -vv sul lato client non aiuta, poiché è improbabile che il server offra troppe informazioni a un possibile aggressore.

Assicurati di aver copiato l'intera chiave pubblica in authorized_keys; il ssh rsaprefisso è necessario affinché la chiave funzioni.

è necessario verificare le proprietà dei file. per assegnare la proprietà richiesta utilizzare:

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

Controlla /var/log/auth.logsul server gli sshderrori di autenticazione.

Se tutto il resto fallisce, quindi eseguire il sshdserver in modalità debug:

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

Quindi connettersi 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 ho capito che il mio sshd_configstava limitando gli accessi ai membri del sshgruppo. Il seguente comando ha corretto questo errore di autorizzazione:

sudo usermod -a -G ssh NEW_USER

su quella nota, assicurati che sshd config abbia -;

PermitRootLogin without-password

impostare come sopra, quindi riavviare sshd (/etc/init.d/sshd restart)

disconnettersi e riprovare ad accedere!

il default credo sia -;

PermitRootLogin no

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

Ho la home directory in una posizione non standard e nei sshdregistri ho questa linea:

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=25813191&sid=0876f069ec2aa5fdcd691a2e2e7242c2#p25813191

Nel mio caso particolare:

• aggiunta una nuova linea in /etc/selinux/targeted/contexts/files/file_contexts.homedirs:

  • questa è la linea originale per le normali home directory:

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

  • questa è la mia nuova linea:

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

• seguito da un restorecon -r /data/e un sshdriavvio

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

Nel mio caso, ho scoperto che la /rootdirectory stessa (non ad esempio /root/.ssh) aveva le autorizzazioni sbagliate. Avevo bisogno:

chown root.root /root
chmod 700 /root

Naturalmente, tali autorizzazioni dovrebbero essere qualcosa del genere (forse chmod 770) a prescindere. Tuttavia, ha impedito in modo specifico sshddi funzionare, anche se /root/.sshed /root/.ssh/authorized_keysentrambi avevano autorizzazioni e proprietari corretti.

Ho avuto questo problema quando ho aggiunto il gruppo dell'utente di accesso a un altro utente. Supponiamo che ci sia un utente ssh-login chiamato userA e un utente non-ssh-login userB. userA ha anche il gruppo userA. Ho modificato userB per avere anche il gruppo userA. Questo porta al comportamento descritto, quindi l'utenteA non è stato in grado di accedere senza un prompt. Dopo aver rimosso il gruppo userA da userB, il login senza prompt ha funzionato di nuovo.