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


33

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

2
donnez-nous s'il vous plaît la sortie dels -la /root/.ssh/
mreithub

@mreithub Merci pour la réponse rapide - ajouté ci-dessus.
Danny

3
essayez de supprimer le _tm1de vos noms de fichiers de clés (c'est mv id_rsa_tm1 id_rsa-à- dire et mv id_rsa_tm1.pub id_rsa.pub)
mreithub

@mreithub Cela a fonctionné! Merci beaucoup, mais je ne comprends pas pourquoi je ne peux pas ajouter d'autres chaînes au nom du fichier. Je le fais sur mon iMac pour me connecter aux serveurs sans aucun problème ... c'est-à-dire que je peux utiliser id_rsa.tm1.imac.pub sans aucun problème. Et si je voulais plusieurs clés?
Danny

Réponses:


22

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.


26

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

2
merci, chaque fois que j'obtiens cette erreur, c'est parce que mon fichier registered_keys sur l'hôte distant (serveur) est mal formé. J'aimerais que l'erreur ne donne pas l'impression qu'il y a eu un problème avec le client.
Tamale

3
Coller dans vim sans appuyer d'abord sur 'i'!
Jordan Davidson

Pour moi, cela ne semblait pas mal formé, mais j'ai supprimé le fichier et de la machine source, j'ai refait ssh-copy-id pour le recréer. Problème résolu.
Alvarez

14

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.


Hou la la! Celui-ci a également pris pas mal de temps! Perdu des cheveux! Donc dans mon cas, c’était cela aussi, seule ma clé de publication se trouvait bien dans le fichier allowed_keys côté client, sauf qu’elle incluait une entrée name @ host à la toute fin, contrairement à mon hôte sshd. Je ne savais pas que vous deviez associer leske_ authorised_keys à chaque extrémité. En fait, je ne pense pas les avoir déjà égalées Ce n'était un problème que lorsque mon client était CentOS 7 et qu'il se connectait à Ubuntu 12.04. Utiliser MacOS ou d’autres systèmes Ubuntu a bien fonctionné.
gregthegeek

Alors, comment résolvez-vous ce problème? Vous avez décrit mon problème à un T. Mon problème est encore exacerbé parce que je saute entre plusieurs systèmes. En fait, spécifier que le fichier ne fonctionne pas pour moi
Madivad

@Madivad Vous résolvez le problème en faisant correspondre les clés publique / privée localement (ou aucune clé publique du tout).
Caleb

@Caleb Cela semble plus simple que si (et je pense que le sou a baissé), cela signifie que je devrais copier les clés publiques et privées sur chaque système que je souhaite utiliser en tant que client SSH? J'ai essayé de créer un
fichier d'

Supprimer le fichier orphelin id_rsa.pub sur le client a résolu le problème pour moi. Je viens de rencontrer ce problème encore une fois sur un nouveau client Centos 7 se connectant au serveur Ubuntu 12.04. allowed_keys nom @ hôte problème ne le résolvait pas. J'ai apparié les répertoires, les permanentes, exactement le même fichier de clé id_rsa, mais il y avait un extra id_rsa.pub (côté client). Supprimé, maintenant cela fonctionne. J'avais couru ssh-keygen pour créer des répertoires rapidement, puis rsync à partir d'un bon système connu. Mais cela laissait un fichier pub supplémentaire ne correspondant à aucune clé privée (ce n'était pas sur la source rsync). J'ai ré-ajouté un fichier pub sans équivalent pour le vérifier. Assurez-vous que correspondant ou supprimer.
gregthegeek

5

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.


4

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.


4
Bienvenue sur le site U + L Stack Exchange. Vous pourriez rendre votre réponse plus utile aux autres en fournissant un exemple de ce à quoi les autorisations correctes devraient ressembler.
Erathiel

J'ai eu un problème très similaire, sauf avec ~/.sshdir. Au moins sur Fedora 28, lorsque les ~/.sshautorisations étaient de 0775, je ne pouvais pas me connecter avec des clés publiques / privées. J'ai donc modifié les autorisations en 0755 et travaillé comme un charme :)
PovilasB

3

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


merci beaucoup, mec! tu as sauvé ma journée!
Anthony

Cela a aidé à clarifier. Mine disait User suchandsuch de 123.123.123.123 non autorisé car non répertorié dans AllowUsers . Merci beaucoup!
aexl


0

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


0

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 utilisateur@xx.xx.xx.xx. 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

-2

client:

vim /etc/ssh/ssh_config

#add your key 
IdentityFile ~/.ssh/yourkey

service sshd restart
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.