web-dev-qa-db-fra.com

Déconnexion du serveur Google PuTTY ': Aucune méthode d'authentification prise en charge disponible (serveur envoyé: publickey)

J'essaie de me connecter à mon serveur Debian Google Compute Engine via PuTTY (j'ai aussi essayé d'autres alternatives) mais j'obtiens l'erreur "Disconnected: aucune méthode d'authentification prise en charge disponible (serveur envoyé: publickey)

Le serveur Google est venu sans nom d'utilisateur ni mot de passe, seulement une URL pour se connecter automatiquement à son propre terminal.

sshgoogle-cloud-platformdebiangoogle-compute-engineputty
58
user3050859

Je travaillais avec PuTTY et puis un jour, j'ai eu cette erreur. 

Solution : J'avais révisé le nom du chemin du dossier contenant mes certificats (clés privées), ce qui a fait perdre à Pageant le suivi des certificats et était donc vide. 

Une fois que j'ai réinstallé le certificat dans Pageant, PuTTY a recommencé à fonctionner.

24
Elliptical view

Activer l'authentification par mot de passe

Par défaut, vous devez utiliser des clés pour ssh dans votre moteur Google Compute Engine, mais vous pouvez activer l'authentification par mot de passesi vous n'avez pas besoin de ce niveau de sécurité.

Astuce: Utilisez l'option Ouvrir dans la fenêtre du navigateur SSH de votre console de cloud pour accéder à la machine. Ensuite, passez à l'utilisateur root avec Sudo su - root pour apporter les modifications de configuration ci-dessous.

enter image description here

  1. Editez le fichier /etc/ssh/sshd_config.
  2. Remplacez PasswordAuthentication et ChallengeResponseAuthentication par yes.
  3. Redémarrez ssh /etc/init.d/ssh restart.
17
Nate

Vous devez utiliser une clé SSH pour vous connecter à votre instance.

La documentation GCE explique le processus ici .

8
Thomas Orozco

Suivez ce guide: https://Gist.github.com/feczo/7282a6e00181fde4281b Avec des images.

En bref:

À l’aide de Puttygen, cliquez sur «Générer», déplacez la souris comme indiqué et attendez

  • Saisissez le nom d'utilisateur désiré

  • Tapez votre mot de passe

  • Sauvegarder la clé privée

Copiez l'intégralité du contenu de la fenêtre 'Clé publique à coller dans le fichier OpenSSH authorised_keys'. Assurez-vous de copier chaque caractère du début à la fin!

Accédez à la page Créer des instances dans la console Google Cloud Platform et dans le lien Options avancées, collez le contenu de votre clé publique.

Notez l'adresse IP de l'instance une fois celle-ci terminée. Ouvrez PuTTY, dans le menu de gauche, accédez à Connection/SSH/Auth et définissez l’emplacement du fichier clé sauvegardé.

Dans le menu de gauche, sélectionnez Connexion/Données et définissez le même nom d'utilisateur.

  • Entrez l'adresse IP de votre instance
  • nommez la connexion sous les sessions sauvegardées en tant que 'GCE' cliquez sur 'Enregistrer' 
  • double-cliquez sur l'entrée 'GCE' que vous venez de créer
  • accepter l'identité de l'hôte 

Maintenant, connectez-vous avec le mot de passe que vous avez spécifié précédemment et exécutez Sudo su - et vous êtes tous ensemble.

5
Feczo

J'ai eu le même problème et je l'ai compris !!

En supposant que vous ayez déjà créé une clé privée/publique et ajouté votre clé publique sur le serveur distant, saisissez [email protected] et ALORS accédez à Connexion -> SSH -> Auth, puis cliquez sur Parcourir pour localiser votre clé privée. Après avoir choisi, le champ de saisie sera renseigné. Après cela, cliquez sur OUVRIR ... 

La chose la plus importante ici est donc la commande ... Assurez-vous d’abord de saisir les paramètres de l’hôte, puis de localiser votre clé privée.

4
shabany

J'ai eu cette erreur parce que j'avais oublié d'ajouter mon nom d'utilisateur derrière la clé dans la section des métadonnées GCE. Par exemple, vous êtes censé ajouter une entrée dans la section des métadonnées qui ressemble à ceci:

sshKeys    username:key

J'ai oublié la partie username: et c'est pourquoi, lorsque j'ai essayé de me connecter avec ce nom d'utilisateur, j'ai eu l'erreur de non prise en charge des méthodes d'authentification.

Ou, pour désactiver complètement l'exigence de clé ssh, consultez mon autre réponse .

2
Nate

Apparemment, si vous exécutez Sudo chmod -R a+rw sur votre dossier personnel, cela se produit également.

2
futilerebel

Téléchargez "PuttyGEN", publickey et privatekey Utilisez gcloud SSH, éditez et collez votre publickey situé dans /home/USER/.ssh/authorized_keys

Sudo vim ~/.ssh/registered_keys

Appuyez sur la touche i pour coller publicKEY . Pour enregistrer, appuyez sur Échap::, w, q, Entrée . Modifiez le fichier/etc/ssh/sshd_config.

Sudo vim /etc/ssh/sshd_config

Changement 

PasswordAuthentication no [...] ChallengeResponseAuthentication à no . [...] UsePAM no [...] Redémarrez ssh 

/etc/init.d/ssh restart.

le reste configure votre PuTTY en tant que tutoriel NB: choisissez le pageant ajouter des clés et commencer la session serait mieux

1
Dongdong Ling

Si la clé privée a été générée avec ssh-keygen sous Linux, elle doit être convertie avec puttygen car PuTTY ne prend pas en charge les clés openssh.

Lancez puttygen, cliquez sur Conversions - Importer, puis sur Parcourir et sélectionnez la clé privée générée avec openssh, puis cliquez sur Enregistrer la clé privée.

Utilisez votre nouvelle clé pour vous connecter.

1
Antonio Ulloa

L'électricité a baissé et a eu cette erreur. La solution consistait à double-cliquer sur votre .ppk (clé privée PuTTY) et à entrer votre mot de passe.

1
geranimo

Ce problème principalement dû à votre nom d'utilisateur connecté n'a pas accès au shell dans GCE. Vous utilisez donc les étapes suivantes pour résoudre ce problème.

gcloud auth list

Si vous utilisez le bon identifiant. veuillez suivre les étapes ci-dessous. sinon utiliser 

gcloud auth revoke --all
gcloud auth login [your-iam-user]

et vous obtenez le jeton ou il détecte automatiquement le jeton.

gcloud compute --project "{projectid}" ssh --zone "{zone_name}" "{instance_name}" .

si vous ne connaissez pas cette ligne, cliquez sur compute engine-> ssh dropdown arrow-> view google command-> copy pour le code et utilisez-le.

Maintenant, il met à jour vos métadonnées et elles sont disponibles dans le dossier de votre ordinateur Users->username

~/.ssh/google_compute_engine.ppk
~/.ssh/google_compute_engine.pub

Ensuite, vous créez un nouveau fichier ppk en utilisant puttygen et vous donnez le nom d'utilisateur, que vous voulez comme my_work_space. Ensuite, sauvegardez le publickey et la clé privée dans un dossier.

Étape suivante: copiez les données de clé publique de puttygen et créez une nouvelle clé ssh dans les métadonnées gcloud

cloud console ->compute engine->metadata->ssh key->add new item->paste the key and save it

et retournez maintenant votre outil de ligne de commande Shell puis entrez

Sudo chown -R my_work_space /home/my_work_space

maintenant, vous connectez cette clé privée en utilisant sftp à n’importe où. et il ouvre les fichiers sans montrer les erreurs d'autorisation

:) heures heureuses. 

1
karthikeyan ganesan

Pour moi, c’était mon problème, solution de https://unix.stackexchange.com/questions/282908/server-refused-public-key-signature-despite-accepting-key-PuTTY

"Regarder le log/var/log/secure a montré que c'était tout simplement un refus. Je suis un peu nouveau sur Centos puisque je suis principalement du genre debian, je ne connaissais donc pas/var/log/secure

Après avoir vérifié cela et fait quelques recherches, il s'avère que PermitRootLogin n'a pas besoin d'être PermitRootLogin sans mot de passe si vous souhaitez utiliser uniquement des clés pour la connexion root. Cela a fait le tour. Merci à tous pour votre contribution. "

0
William

Problème similaire - même message d'erreur. J'ai reçu le même message lorsque j'essayais de cloner quelque chose à partir de bitbucket avec ssh. Le problème était dans ma configuration ssh configurée dans le fichier Mercurial.ini: J'ai utilisé le mauvais nom d'utilisateur bitbucket. Après avoir corrigé le nom d'utilisateur, les choses ont fonctionné.

0
Nina

J'ai fait face au même problème et je l'ai résolu après plusieurs essais et erreurs . Dans le fichier/etc/ssh/ssh_config,

  • PubkeyAuthentication oui

  • AuthorizedKeysFile .ssh/registered_keys

  • Authentification par mot de passe non

  • AuthenticationMethods publickey

ensuite, ouvrez PuTTY . Dans les "Sessions enregistrées", entrez l'adresse IP du serveur, suivez le chemin Connexion-> SSH-> Auth-> Parcourez le panneau de gauche pour rechercher votre clé privée et ouvrez-le . Dernier point mais non le moindre, retournez à Session of PuTTY dans le panneau de gauche et vous pouvez voir que l’adresse IP du serveur est toujours dans le champ "Sessions sauvegardées", puis cliquez sur "Enregistrer", qui constitue l’étape critique . laissera l'utilisateur se connecter sans mot de passe plus .. .. Amusez-vous,

0
codexplorer

PasswordAuthentication et ChallengeResponseAuthentication sont définis par défaut sur NO dans rhel7. 

Changez-les en NO et redémarrez sshd.

0
user2427719

J'ai eu le même problème, mais je l'ai obtenu en modifiant enable-oslogin de TRUE à FALSE dans Google Cloud.

de:  

à:  enter image description here

0
Sgedda