web-dev-qa-db-fra.com

Impossible de ssh même avec la clé publique ajoutée à allowed_keys

J'ai une gouttelette Digital Ocean que j'essaie de m'offrir un accès SSH. Je ne suis pas sûr de ce qui a été fait auparavant. J'ai essayé d'ajouter ma clé publique via l'interface utilisateur Digital Ocean. Cela n'a pas fonctionné, j'ai continué à avoir permission denied (publickey).

J'ai accédé au serveur via la console Digital Ocean et ajouté manuellement ma clé publique à /root/.ssh/authorized_keys. J'ai ensuite essayé de ssh en utilisant ssh [email protected]. Cela n'a pas fonctionné (permission refusée).

J'ai donc essayé d'ajouter un nouvel utilisateur, de créer le répertoire /home/me/.ssh avec les autorisations 700 sur le répertoire .ssh et de 600 dans le fichier authorized_keys. Ensuite, j'ai essayé ssh [email protected]. Cela n'a pas fonctionné non plus.

Redémarrer le démon ssh ne change rien non plus.

Qu'est-ce que je rate?

Modifier:

Voici la sortie ssh verbeuse.

https://Gist.github.com/jaesung2061/a37cfd68308414cede8abf7f0137daa9

Edit 2:

LogLevel DEBUG3 output:

enter image description here

networking16.04ssh
12
Jeff

J'ai fini par réinstaller openssh-server qui a résolu le problème. Les solutions proposées sont excellentes, mais elles n’ont pas fonctionné pour moi. Je ne sais pas du tout ce qui était à l'origine du problème, mais je pense que le développeur précédent a peut-être gâché la configuration et mal gâché le travail.

Je doute qu'il y ait quelqu'un avec un problème aussi spécifique que le mien. Toutefois, si vous disposez d'un droplet Digital Ocean, vous ne pouvez pas obtenir d'accès SSH et aucune des solutions fournies ne fonctionne, réinstallez le serveur SSH en exécutant ces commandes via la console Digital Ocean. Attention, il s’agit d’un processus destructif qui effacera les anciens fichiers de configuration de /etc/ssh/ (et non votre répertoire .ssh).

apt-get purge openssh-server
apt-get autoremove
apt-get autoclean
apt-get install openssh-server

En supposant que votre client/clé ssh soit en ordre, vous devriez être capable de SSH sur votre serveur.

3
Jeff

Configuration du client

Configurer ~/.ssh/config

Configurer les entrées de l'hôte pour sshest très simple et vous épargnera pas mal d'ennuis. Voici un exemple:

Host digitaloceanbox
Hostname 111.111.111.111
User root
PubKeyAuthentication yes
IdentityFile /home/user/.ssh/digitalocean-rsa
ForwardX11 yes


Host github github.com
Hostname github.com
User git
PubKeyAuthentication yes
IdentityFile /home/user/.ssh/github-rsa
ForwardX11 no

Dans cet exemple, nous configurons digitaloceanboxet githubet github.com afin que nous puissions exécuter les commandes suivantes:

  1. ssh github
  2. ssh digitaloceanbox

Si nous voulons nous connecter en tant qu'utilisateur différent de celui spécifié dans le fichier de configuration, il suffit de mettre user@ au début:

  • ssh user@digitaloceanbox

Génération de sshclés

ssh-keygen -t rsa -b 4096 -C user@homemachine
Generating public/private rsa key pair.
Enter file in which to save the key (/home/user/.ssh/id_rsa):  /home/user/.ssh/digitalocean-rsa
Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in /home/user/.ssh/digitalocean-rsa
Your public key has been saved in /home/user/.ssh/digitalocean-rsa.pub.
The key fingerprint is:
SHA256:p9PYE/tveF2n//bLbp3ogYDtMtYEC5ziQiPxeob6fbo user@homemachine

Notez que j'ai spécifié le chemin complet de la clé privée que je veux générer lorsque je suis invité par ssh-keygen. J'ai également défini le commentaire (-C) qui me permet d'identifier facilement les clés sur des machines distantes.

Cela créera deux fichiers:

  1. .ssh/digitalocean-rsa
    • PRIVÉ clé. Ne jamais partager ceci.
  2. .ssh/digitalocean-rsa.pub
    • Clé publique. C'est ce que vous stockez sur le serveur pour vous authentifier.

Lorsque vous fournissez votre clé sshname__, assurez-vous qu'il s'agit bien de la version .pub! Lorsque vous ajoutez à votre ~/.ssh/config, veillez à ajouter la clé privée appropriée correspondant à la clé publique que vous avez ajoutée au système.

Configuration du serveur

L’authentification de la clé publique sera activée pour la plupart des installations. Si vous commencez à faire des choses comme vous le souhaitez, vous pourriez toutefois rencontrer quelques problèmes. À l'endroit où l'OP est dans son problème, je recommande que l'OP supprime le répertoire /root/.ssh/ pour recommencer.

Il n'est pas recommandé d'utiliser sshpour accéder à l'utilisateur root sur le système distant. Il est recommandé de vous sshen un autre utilisateur, puis de passer à root en utilisant votre mot de passe (Sudo su -).

Ajouter des clés à l'hôte à l'aide de ssh-copy-id

Que vous décidiez ou non de créer un autre utilisateur et d'utiliser sshcomme utilisateur ou utilisateur racine, voici la méthode recommandée pour placer les clés sshsur un serveur:

  1. ssh-copy-id -i /home/user/.ssh/digitalocean-rsa.pub user@digitaloceanbox

Cela permet à sshdde créer le répertoire et les fichiers nécessaires avec les autorisations nécessaires. Cela signifie qu'il n'y a aucune chance que vous perdiez des autorisations ou que vous deviez vous souvenir des détails. Utilisez simplement l'outil pour télécharger les clés.

Désactiver l'authentification par mot de passe

Ceci étant dit, une fois que vous avez saisi la clé et vérifié que vous êtes en mesure de vous connecter à l'aide des clés, il est recommandé de désactiver l'authentification par mot de passe dans sshdet de redémarrer le service:

  1. Éditer /etc/ssh/sshd_config
  2. PasswordAuthentication no
  3. Sudo systemctl restart sshd

Qu'en est-il des nouveaux utilisateurs?

Si vous désactivez l'authentification par mot de passe, comment pouvez-vous entrer de nouveaux utilisateurs? Une solution consiste à ajouter des fichiers de modèle au répertoire /etc/skel. Une fois que vous avez saisi un utilisateur, procédez comme suit:

  1. Sudo cp -r .ssh/ /etc/skel/
  2. ls /etc/skel/.ssh
  3. Modifiez tous les fichiers contenus dans /etc/skel/.ssh/ afin qu'ils soient vides, à moins que vous ne souhaitiez vous saisir automatiquement pour chaque nouvel utilisateur créé.

Lorsque vous créez de nouveaux utilisateurs avec Sudo useradd -m newuser, cet utilisateur aura le .ssh/authorized_keys, que vous pourrez modifier et bénéficier des autorisations appropriées.

Débogage

Vous pouvez consulter le fichier journal sshdpour savoir pourquoi les connexions échouent ou sont refusées:

  1. Sudo tail -f /var/log/auth.log

Pendant que vous exécutez cette commande, utilisez un autre terminal pour tenter une connexion. Plusieurs fois, les messages fournis sont assez bons pour aider à cerner le problème ou à trouver une solution en ligne.

18
earthmeLon

Ssh est assez pointilleux sur les droits de propriété, de fichiers et de répertoires avec les clés ssh.

~/.ssh/devrait appartenir au propriétaire et disposer de 700 autorisations. ~/.ssh/registered_keys doit appartenir au propriétaire et disposer de 600 autorisations.

Donc, pour root:

Sudo chown root:root -R /root/.ssh/
Sudo chmod 700 /root/.ssh/
Sudo chmod 600 /root/.ssh/authorized_keys

Pour l'utilisateur moi:

Sudo chown me:me -R /home/me/
Sudo chmod 700 /home/me/.ssh/
Sudo chmod 600 /home/me/.ssh/authorized_keys

Et puis réessayez.

Bien sûr, vous devriez également vérifier dans/etc/ssh/sshd_config si la racine est autorisée à se connecter, ou simplement avec les clés ssh.

Si tu as :

PasswordAuthentication no

alors vous pouvez définir:

PermitRootLogin yes

Et redémarrez sshd:

/etc/init.d/sshd restart

et essayez à nouveau.

Notez qu'avec ssh, le démon sshd peut être redémarré même si vous utilisez une session ssh pour cela. Openssh est conçu pour gérer cela.

En regardant vos extraits de fichier journal téléchargés, il semble que vous utilisiez MacOSX? Pourriez-vous créer une nouvelle clé SSH ici?

De plus, j’ai découvert par le passé que lorsque j’ai plus d’une clé privée ssh sur mon ordinateur local pour mon utilisateur, cela rend parfois impossible la connexion à distance avec ssh. Cela a beaucoup aidé de faire des entrées sur l’ordinateur local dans le fichier ~/.ssh/config, pour résoudre ce problème. Par exemple :

Host my-vps
  HostName my-vps-ip-address-here
  IdentityFile ~/.ssh/id_rsa-my-private-key-location
  User my-username-here

Après cela, essayez sur la ligne de commande sur votre ordinateur local:

ssh -v my-vps

Lorsque vous utilisez des clés ssh, ainsi que pas de clés ssh pour certaines autres connexions, vous pouvez, en plus des entrées avec des clés ssh, également définir un login ssh sans utilisation de la clé ssh dans le fichier ~/ssh/config, par exemple:

Host pi
  Hostname 192.168.1.111
  Port 22
  User pi
  PasswordAuthentication yes
  PreferredAuthentications password

Cela fonctionne bien pour moi. Il est également possible de définir quelle clé utiliser sur la ligne de commande:

ssh -v [email protected] -i .ssh/id_rsa

Cela pourrait faciliter le débogage et, sur la ligne de commande, cela devrait toujours fonctionner sur l'ordinateur local.

12
albert j

Selon les journaux que vous avez liés, je pense que vous rencontrez des problèmes du côté du client qui ne trouve pas le fichier clé privée.

  • Commencez par vérifier que le fichier ~/.ssh/id_rsa existe sur votre ordinateur local et qu’il est correct _ (si vous en avez plus).

  • Vérifiez les autorisations de dossier .ssh[devrait être drwx------, si ce n'est pas exécuté Sudo chmod 700 ~/.ssh) et son contenu (devrait être -rw-------, si ce n'est pas exécuté Sudo chmod 600 ~/.ssh/*). Appliquez également les mêmes autorisations pour la machine distante.

En outre, vous pouvez essayer de forcer l’utilisation de votre clé privée souhaitée, en l’attribuant directement à ssh avec le paramètre -i.

Vous pouvez obtenir plus d’informations sur la page de manuel ssh (exécutez man ssh sur votre terminal).

Rappelez-vous également que si vous souhaitez vous connecter en tant qu'utilisateur root, votre compte root doit être activé avant la connexion, en créant un mot de passe avec Sudo passwd root ou votre outil d'administration du serveur (Ubutntu a un compte root désactivé par défaut). Vous pouvez obtenir plus d’informations sur buntu Wiki .

J'espère que ça aide.

3
dgonzalez

Vérifiez la configuration du démon ssh (devrait être dans /etc/ssh/sshd_config) et vérifiez:

PubkeyAuthentication yes
AuthorizedKeysFile %h/.ssh/authorized_keys

Consultez également le fichier de configuration pour voir si AllowUsers ou AllowGroups a été défini, car ils agissent respectivement en tant que listes blanches pour les utilisateurs et les groupes.

De plus, j'ai remarqué que vous essayez d'ajouter une clé à l'utilisateur root. Par défaut, la connexion root doit être désactivée, mais vous pouvez également la modifier via le champ PermitRootLogin.

3
TLin

Ce problème est apparu en utilisant l'image Debian sur Digital Ocean. D'une manière ou d'une autre, au cours du bref processus de configuration, probablement lorsque j'ai défini le mot de passe root, le propriétaire de /root a été remplacé par l'utilisateur debian. J'ai vu ce qui suit dans /var/log/auth.log:

Jul 26 20:58:17 docker sshd[12576]: Authentication refused: bad ownership or modes for directory /root

Exécuter simplement chown root:root -R /root a résolu le problème.

HTH

1
Sean Brady

Je viens d'avoir un problème très similaire. Cela a fonctionné pour moi - Ajoutez cette ligne à / etc/ssh/sshd_config

AuthorizedKeysFile %h/.ssh/authorized_keys

Puis redémarrez ssh de la manière habituelle.

0
bodycheetah