SSH: "Serveur refusé notre key" sans raison

Certaines raisons possibles que je connais sont liées à des permissions de files, celles-ci sont la plupart du time trop larges et surtout je peux callbacker deux raisons

1. exposant / home / user directory à plus que le propriétaire
2. .ssh et / ou authorized_keys permissions de file (les mettre à 700/600 respectivement s'ils sont plus que cela)

la raison exacte de la key est refusée en démarrant un server sshd supplémentaire sur un autre port avec des options de debugging et de non-démon si vous avez un access root sur le server que vous pouvez exécuter:

 sudo `which sshd` -p 2020 -Dd 

sur le server

Après avoir quitté cette course, lancez-la ssh:

 ssh -p 2020 -i /path/to/refusedkey 

La sortie du server vous indiquera la raison du refus

une vérification évidente

• format de authorized_keys ssh-rsa AA...long_line_of_char comment putty gen parfois donner une autre forme.

• autorisation:

  • ~ user / .ssh / authorized_keys est -rw-r -r–
  • ~ user / .ssh / est drwx ——
  • ~ l'user n'est pas inscriptible dans le monde.

• la key doit être déployée id ~ root ou dans ~ user en fonction de l'user auquel vous vous connectez.

certains less évidents:

• root n'est pas autorisé à être ssh'd. ( PermitRootLogin no ou commentaire)

• location par défaut pour authorized_keys AuthorizedKeysFile %h/.ssh/authorized_keys

  • c'est-à-dire .ssh sous le directory home de l'user.

• exemple d'location personnalisé pour authorized_keys AuthorizedKeysFile /foo/bar/authorized_keys.%h

  • c'est-à-dire les keys, se trouvent dans /foo/bar dir.
  • dans le file authorized_keys.root for root
  • dans le file authorized_keys.user pour l'user, le file appartient à root

Dans mon cas, je l'ai résolu en faisant:

 chmod 700 myuserdir/.ssh chmod 600 myuserdir/.ssh/authorized_keys 

Sur la boîte des windows, au lieu d'utiliser puttygen pour générer la key privée rsa, j'ai téléchargé cygwin de cygwin.org. Il offre quelques packages par défaut. J'ai modifié le package Net pour installer OpenSSH. Cela a installé, entre autres, le programme ssh-keygen. Donc, j'ai couru:

• ssh-keygen -t rsa et laissé le mot de passe vide
• Cela a créé la key privée nommée id_rsa dans c:/cygwin/home/myusername/.ssh
• J'ai commencé puttygen et select l'option de menu "Fichier -> Charger la key privée" et select votre id_rsa (pas le public id_rsa.pub ).
• Enregistrez-le en format mastic en cliquant sur le button "Enregistrer la key privée" (je l'ai appelé putty.ppk)
• Démarrer mastic et select login -> SSH -> Auth -> Clé privée pour l'authentification. Entrez le putty.ppk généré.
• Entrez votre nom d'user dans mastic: login -> Données -> Nom d'user de connection automatique

Maintenant, je peux me connecter sans entrer ni user ni mot de passe.

Courir:

 sudo `which sshd` -p 2020 -Dd 

en tant que root dans une session et dans une autre session exécutée:

 ssh -p 2020 -i /path/to/refusedkey refusedkeyusername@hostname 

A travaillé pour moi d'get la raison. Mes permissions d'user n'ont pas été définies à 700. J'ai eu l'o / p comme ci-dessous

 debug1: trying public key file /home/userid/.ssh/authorized_keys debug1: fd 4 clearing O_NONBLOCK Authentication refused: **bad ownership** or modes for directory /home/sapadmin debug1: restore_uid: 0/0 Failed publickey for userid from 172.31.2.12 port 27382 ssh2: RSA Connection closed by 172.31.2.12 [preauth] 

D'accord! L'une des raisons est que le directory de base de l'user du file passwd n'est pas le directory à partir duquel vous voulez copyr les files. Seule la racine peut copyr de chaque article, les autres users non!

Par exemple, si vous voulez copyr à partir du directory / backup, assurez-vous que l'user que vous voulez authentifier a le directory de base défini sur / backup (appartenant à lui), pour que scp trouve le path corect à authorized_keys "/backup/.ssh/ authorized_key "

deuxièmement: veillez à copyr dans le file authorized_keys exactement le text de Putty Key Generator avec "ssh-rsa AA …." sur une seule ligne. vous pouvez supprimer tout commentaire comme "rsa-key-xxx .." à la fin. Le file authorized_keys doit posséder l'user / groupe bonne chance!

A partir du journal du server de debugging que vous avez partagé, il semble que la key que vous avez spécifiée du côté client ne correspond à aucun des files disponibles dans /testuser/.ssh/authorized_keys.

si /testuser/.ssh/authorized_keys est l'location attendu, vous devriez vérifier qu'il y a une ligne de key publique correspondant à votre key privée utilisée côté client – c'est-à-dire si vous utilisez say, id_rsa sur le client, vérifiez id_rsa.pub à côté de il correspond exactement à l'une des lignes de /testuser/.ssh/authorized_keys.

Si vous doutez du file authorized_keys de l'location sur le server, vous devez déterminer si vous spécifiez le bon nom d'user côté client.