La chiave pubblica SSH non verrà inviata al server

Ho lottato con questo per un paio d'ore, quindi ogni aiuto è molto apprezzato ...

Ho 2 server entrambi che posso usare sshcon le chiavi pubbliche di OSX, nessun problema, quindi sono certo che tutto vada bene sshd_config.

Sto cercando di configurare un processo cron per rsyncsincronizzare i due server e ho bisogno del server B (backup) sshnel server A usando una chiave pubblica.

Per la vita non riesco a capire perché non trova le mie chiavi pubbliche: sono in ~/.ssh/(es. /root/.ssh) E tutte le autorizzazioni per i file sono corrette su A e B.

Questo è l'output:

debug2: we did not send a packet, disable method
debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Trying private key: /root/.ssh/identity
debug3: no such identity: /root/.ssh/identity
debug1: Trying private key: /root/.ssh/id_rsa
debug3: no such identity: /root/.ssh/id_rsa
debug1: Trying private key: /root/.ssh/id_dsa
debug3: no such identity: /root/.ssh/id_dsa
debug2: we did not send a packet, disable method
debug3: authmethod_lookup password
debug3: remaining preferred: ,password
debug3: authmethod_is_enabled password
debug1: Next authentication method: password

Nota anche che sta cercando chiavi private che non esistono ...

drwx------. 2 root root 4096 May 25 10:15 .
dr-xr-x---. 4 root root 4096 May 24 18:52 ..
-rw-------. 1 root root  403 May 25 01:37 authorized_keys
-rw-------. 1 root root    0 May 25 01:41 config
-rw-------. 1 root root 1675 May 25 02:35 id_rsa_tm1
-rw-------. 1 root root  405 May 25 02:35 id_rsa_tm1.pub
-rw-------. 1 root root  395 May 25 02:36 known_hosts

Dai un'occhiata alla tua pagina man ssh:

   -i identity_file
          Selects a file from which the identity (private key) for public
          key authentication is read.  The default is ~/.ssh/identity for
          protocol   version   1,   and  ~/.ssh/id_dsa,  ~/.ssh/id_ecdsa,
          ~/.ssh/id_ed25519 and ~/.ssh/id_rsa  for  protocol  version  2.
          Identity files may also be specified on a per-host basis in the
          configuration file.  It is possible to have multiple -i options
          (and  multiple  identities  specified  in configuration files).

o la pagina man ssh_config:

   IdentityFile
          Specifies a file from which the user's DSA, ECDSA,  ED25519  or
          RSA   authentication   identity   is   read.   The  default  is
          ~/.ssh/identity for  protocol  version  1,  and  ~/.ssh/id_dsa,
          ~/.ssh/id_ecdsa, ~/.ssh/id_ed25519 and ~/.ssh/id_rsa for proto‐
          col version 2.  Additionally, any identities represented by the
          authentication  agent  will  be  used for authentication unless
          IdentitiesOnly is set.

Vedete, ci sono alcuni nomi di file speciali che vengono provati se non si specifica una chiave. Questi sono anche i file che vedi nell'output del log.

Per usare una chiave in un file con un nome diverso hai tre opzioni:

• specifica il file esplicitamente usando l' -iopzione sopra .
• configura il file nella tua configurazione client usando l' IdentityFileopzione sopra .
• aggiungi la chiave al tuo agente utilizzando ssh-add.

Per le sessioni interattive l'agente è il più flessibile. Per il tuo lavoro cron l' -iopzione è probabilmente la più semplice.

Un file autorizzato_keys non valido sull'host di destinazione è un altro motivo per cui ssh genera il messaggio "non abbiamo inviato un pacchetto" e chiede una password invece di usare pubkey auth: -

debug1: Next authentication method: publickey
debug1: Offering RSA public key: ~/.ssh/id_rsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey,password
debug2: we did not send a packet, disable method

Il problema in questo caso particolare era che i dati della chiave pubblica, che erano stati incollati .ssh/authorized_keysnell'host di destinazione, mancavano del primo carattere:

sh-rsa AAAA...

La soluzione era semplicemente aggiungere la "s" mancante.

ssh-rsa AAAA...

E così:-

debug1: Next authentication method: publickey
debug1: Offering RSA public key: ~/.ssh/id_rsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Server accepts key: pkalg ssh-rsa blen 279
...
debug1: Authentication succeeded (publickey).

Questa esatta stringa di messaggi di errore nella domanda può verificarsi anche nel caso di una coppia di chiavi privata / pubblica con corrispondenza errata sul lato locale . No, non ha alcun senso, ma mi sono semplicemente strappato i capelli per molto tempo cercando di capire cosa stesse succedendo.

• Il sistema remoto A è stato .ssh/mykey.pubcopiato .ssh/authorized_keys.
• Il sistema locale B ha .ssh/mykeyla chiave privata corretta per abbinare la chiave pubblica del sistema A, ma ha anche un .ssh/mykey.pubfile che è una mancata corrispondenza, probabilmente la versione precedente di una chiave sostituita.

SSH da B a A ( ssh -i mykey A) fallirà con i messaggi nella domanda, in particolare se si accende -vvdal client ssh vedrai:

Prova della chiave privata: .ssh / mykey
non abbiamo inviato un pacchetto, disabilita il metodo

Questa è una bugia perché la chiave effettiva non è stata provata, apparentemente ha usato il file della chiave pubblica locale con il nome corrispondente per capire se era probabile che funzionasse e quindi in realtà non ha fatto nulla in caso di mancata corrispondenza. Nessuna quantità di informazioni di debug su entrambi i lati suggerisce davvero il problema.

I nomi file predefiniti che ssh sta cercando sono id_rsae id_rsa.pub.

Se si desidera utilizzare altri nomi di file, è necessario specificarli in ssh_config(utilizzando l' IdentityFileimpostazione) o tramite il parametro della riga di comando ssh -i.

Ho avuto lo stesso problema su RedHat; ha controllato i log e ha scoperto che la directory home aveva diritti utente errati.

sshd[2507]: Authentication refused: bad ownership or modes for directory /home/user

Risolto il problema con la correzione dei diritti di home dir.

Un modo semplice per eseguire il debug in Debian / Ubuntu è: Connettiti con password e segui il registro

tail -f /var/log/auth.log

Prova a connetterti da un altro terminale e vedrai l'errore ...

Nel mio caso la directory / root era 770 e non 700, che è l'impostazione predefinita. L'errore era "Autenticazione rifiutata: proprietà o modalità errate per directory / root"

Risolvi questo e il gioco è fatto.

Provare

/sbin/restorecon -r /root/.ssh

Un possibile problema con il contesto di vendita

Dopo aver corso

ssh-copy-id user@remote-host

normalmente dovrebbe funzionare. Ma se fallisce, prova questo: accedi all'host remoto come l'utente a cui vuoi accedere in futuro ed esegui:

ssh-keygen

Mi ha aiutato

Quindi quello che è successo per me è che ho 2 VM per accedere dal mio computer locale (2 chiavi id_rsa.pub e id_rsa2.pub). Mi sono reso conto che la mia connessione ssh utilizza id_rsa.pub per impostazione predefinita per qualsiasi connessione ssh user@xx.xx.xx.xx. Ho risolto il mio problema aggiungendo un file di configurazione e specificando l'identità da utilizzare per ogni host come il seguente:

vi ~/.ssh/config

Add both hostnames and their identity file as follows:

Host server1.nixcraft.com
  IdentityFile ~/Users/.ssh/id_rsa1
Host server2.nixcraft.com
  IdentityFile /backup/home/aymen/.ssh/id_rsa2

cliente:

vim /etc/ssh/ssh_config

#add your key 
IdentityFile ~/.ssh/yourkey

service sshd restart