web-dev-qa-db-fra.com

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

Je me bats avec ça depuis quelques heures donc toute aide est grandement appréciée ...

J'ai 2x serveurs tous les deux que je peux ssh avec des clés publiques d'OSX, aucun problème là-bas donc je suis certain que tout va bien avec sshd_config.

J'essaie de configurer un travail cron pour rsync pour synchroniser les deux serveurs et j'ai besoin du serveur B (sauvegarde) sur ssh dans le serveur A à l'aide d'une clé publique.

Pour la vie de moi, je ne peux pas comprendre pourquoi il ne trouve pas mes clés publiques - elles sont dans ~/.ssh/ (c'est à dire. /root/.ssh) et toutes les autorisations de fichiers sont correctes sur A & B.

Voici 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
sshkey-authentication
37
Danny

Jetez un œil à 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 y a quelques noms de fichiers spéciaux qui sont essayés si vous ne spécifiez pas de clé. Ce sont également les fichiers que vous voyez dans votre sortie de journal.

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

  • spécifiez le fichier explicitement en utilisant l'option -i ci-dessus.
  • configurez le fichier dans votre configuration client en utilisant l'option IdentityFile ci-dessus.
  • ajoutez la clé à votre agent en utilisant ssh-add.

Pour les sessions interactives, l'agent est le plus flexible. Pour votre tâche cron, l'option -i Est probablement la plus simple.

23
michas

Un fichier author_keys mal formé sur l'hôte de destination est une autre raison pour laquelle ssh envoie le message "nous n'avons pas envoyé de paquet" et demande un mot de passe au lieu d'utiliser l'authentification par clé de pub: -

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 dans .ssh/authorized_keys sur l'hôte de destination, il manquait son 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).
29
jah

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 appariée du côté local. Non, cela n'a aucun sens, mais je me suis arraché les cheveux pendant longtemps en essayant de comprendre ce qui se passait.

  • Le système distant A a .ssh/mykey.pub copié dans .ssh/authorized_keys.
  • Le système local B a .ssh/mykey qui est la bonne clé privée pour correspondre à la clé publique du système A, mais qui a également un .ssh/mykey.pub fichier qui est une erreur de correspondance, peut-être la version précédente d'une clé remplacée.

SSH de B vers A (ssh -i mykey A) échouera avec les messages de la question, notamment si vous activez -vv du client ssh vous verrez:

Essayer la clé privée: .ssh/mykey
nous n'avons pas envoyé de paquet, désactivez la méthode

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 s'il était susceptible de fonctionner et n'a ensuite rien fait en cas de non-concordance. Aucune quantité d'informations de débogage de chaque côté ne fait vraiment allusion au problème.

16
Caleb

Un moyen simple de déboguer dans Debian/Ubuntu est: se connecter avec un mot de passe et suivre le journal

tail -f /var/log/auth.log

Essayez de vous connecter à partir d'un autre terminal et vous verrez l'erreur ...

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

Corrigez cela et vous avez terminé.

5
Dimitrios

Les noms de fichiers par défaut recherchés par ssh sont id_rsa et id_rsa.pub.

Si vous souhaitez utiliser d'autres noms de fichiers, vous devez soit les spécifier dans ssh_config (en utilisant le paramètre IdentityFile) ou via le paramètre ssh ligne de commande-i.

5
mreithub

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

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

La correction des droits du répertoire d'origine a résolu ce problème.

5
skywalkie

Essayer

/sbin/restorecon -r /root/.ssh

Un problème possible avec le contexte de vente

2
Abdel Karim Mateos Sanchez

[J'ai été mordu par cette vague erreur aujourd'hui, alors j'ajoute à la liste possible les causes du message "nous n'avons pas envoyé de paquet, désactivez la méthode" debug2. ]

Il peut s'agir du compte auquel vous vous connectez car (sur le système distant) n'a pas accès en lecture au fichier de clé publique (sur le système distant). Par exemple, dans notre environnement, nous avons un emplacement AuthorizedKeysFile personnalisé spécifié dans /etc/ssh/sshd_config:

AuthorizedKeysFile /usr/local/etc/ssh_authorized_keys/%u_pub

Et /usr/local/etc/ d'une manière ou d'une autre, ses autorisations ont été modifiées en:

drwx------. 3 root root 29 Feb 20  2018 /usr/local/etc/

Résolu en (re) définissant les autorisations pour:

drwxr-xr-x. 3 root root 29 Feb 20  2018 /usr/local/etc/
1
ecs-hk

Après avoir couru

ssh-copy-id user@remote-Host

normalement, cela devrait fonctionner. Mais s'il é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é.

0
mennanov

Donc, ce qui m'est arrivé, c'est que j'ai 2 machines virtuelles auxquelles accéder depuis ma machine locale (2 clés id_rsa.pub et id_rsa2.pub). J'ai réalisé 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
0
Aymen Alsaadi