La clé publique SSH ne sera pas envoyée au serveur

Cela fait deux heures que je me bats avec ça alors toute aide est grandement appréciée ...

J'ai deux serveurs que je peux utiliser sshavec des clés publiques sous OSX, aucun problème là-bas, donc je suis certain que tout va bien sshd_config.

J'essaie de configurer un travail cron pour rsyncsynchroniser les deux serveurs et que le serveur B (sauvegarde) soit nécessaire sshsur le serveur A à l'aide d'une clé publique.

Je ne peux pas pour la vie de comprendre pourquoi il ne trouve pas mes clés publiques - elles sont dedans ~/.ssh/(c.- à -d. /root/.ssh) Et toutes les autorisations de fichiers sont correctes sur A & B.

C'est la sortie:

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

Notez également qu'il recherche des clés privées qui n'existent pas ...

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

Consultez votre page de manuel 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).

ou la page de manuel 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.

Vous voyez, il existe quelques noms de fichiers spéciaux qui sont essayés si vous ne spécifiez pas de clé. Ce sont aussi les fichiers que vous voyez dans votre journal.

Pour utiliser une clé dans un fichier de nom différent, vous avez trois options:

• spécifiez le fichier explicitement en utilisant l' -ioption ci-dessus .
• configurez le fichier dans la configuration de votre client en utilisant l’ IdentityFileoption ci-dessus .
• ajoutez la clé à votre agent avec ssh-add.

Pour les sessions interactives, l'agent est le plus flexible. Pour votre travail cron, l' -ioption est probablement la plus simple.

Une autre raison pour laquelle ssh renvoie le message "Nous n’avons pas envoyé de paquet" et demande un mot de passe au lieu d’utiliser 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

Le problème dans ce cas particulier était que les données de clé publique, qui avaient été collées sur .ssh/authorized_keysl'hôte de destination, manquaient de leur premier caractère:

sh-rsa AAAA...

La solution consistait simplement à ajouter les "s" manquants.

ssh-rsa AAAA...

Et donc:-

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).

Cette chaîne exacte de messages d'erreur dans la question peut également se produire dans le cas d'une paire de clés privée / publique mal appariée du côté local . Non, ça n'a aucun sens, mais je me suis simplement arraché les cheveux pendant longtemps en essayant de comprendre ce qui se passait.

• Le système distant A a .ssh/mykey.pubcopié dans .ssh/authorized_keys.
• Le système local B possède .ssh/mykeyla clé privée appropriée pour correspondre à la clé publique du système A, mais contient également un .ssh/mykey.pubfichier qui correspond à une correspondance erronée, éventuellement la version précédente d'une clé remplacée.

SSH de B à A ( ssh -i mykey A) échouera avec les messages de la question. En particulier, si vous activez le -vvclient ssh, vous verrez:

Essai de clé privée: .ssh / mykey
nous n’avons pas envoyé de paquet, méthode disable

C'est un mensonge parce que la clé réelle n'a pas été essayée, elle a apparemment utilisé le fichier de clé publique locale avec le nom correspondant pour déterminer si elle était susceptible de fonctionner et n'a ensuite rien fait en cas d'incompatibilité. Aucune quantité d’informations de débogage d’un côté ou de l’autre ne donne réellement une idée du problème.

Les noms de fichier par défaut que ssh recherche sont id_rsaet id_rsa.pub.

Si vous souhaitez utiliser d'autres noms de fichiers, vous devez les spécifier dans ssh_config(à l'aide du IdentityFileparamètre) ou via le paramètre de ligne de commande ssh -i.

J'ai eu le même problème sur RedHat; vérifié les journaux et a constaté que le répertoire de base avait des droits d'utilisateur incorrects.

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

La fixation des droits de répertoire de base a résolu ce problème.

Une façon simple de déboguer dans Debian / Ubuntu est la suivante: Connectez-vous avec un mot de passe et réduisez le journal.

tail -f /var/log/auth.log

Essayez de vous connecter depuis un autre terminal et vous verrez l'erreur ...

Dans mon cas, le répertoire / root était 770 et non 700, valeur par défaut. L'erreur était "Authentification refusée: propriété incorrecte ou modes pour répertoire / racine".

Corrigez ceci et vous avez terminé.

Essayer

/sbin/restorecon -r /root/.ssh

Un problème possible avec le contexte de vente

Après avoir couru

ssh-copy-id user@remote-host

normalement ça devrait marcher. Mais si cela échoue, essayez ceci: connectez-vous à l'hôte distant en tant qu'utilisateur auquel vous souhaitez vous connecter à l'avenir et exécutez:

ssh-keygen

Ça m'a aidé.

Donc, ce qui m'est arrivé, c’est que j’ai accès à 2 ordinateurs virtuels à partir de mon ordinateur local (2 clés id_rsa.pub et id_rsa2.pub). Je me suis rendu compte que ma connexion ssh utilise id_rsa.pub par défaut pour toute connexion ssh [email protected]. J'ai résolu mon problème en ajoutant un fichier de configuration et en spécifiant l'identité à utiliser pour chaque hôte, comme suit:

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

client:

vim /etc/ssh/ssh_config

#add your key 
IdentityFile ~/.ssh/yourkey

service sshd restart