SSH continue de passer mon pubkey et de demander un mot de passe

52

Chaque fois que je ssh sur mon serveur distant, je dois fournir le mot de passe. J'ai copié ma clé publique (id_dsa.pub) sur le serveur distant à l'aide de:

ssh-copy-id -i id_dsa.pub user@server

J'ai vérifié qu'il a été correctement ajouté à registered_keys. Toutes les autorisations de fichier / répertoire sont correctes:

~user 755
~user/.ssh 700
~user/.ssh/authorized_keys 640
~user/.ssh/id_dsa.pub 644

Le champ PasswordAuthentication dans / etc / ssh / sshd_config est défini sur yes. J'ai mis le sshd en mode débogage et j'ai ajouté le commutateur détaillé à la commande ssh. J'ai l'impression que le serveur n'a pas essayé d'utiliser id_pub.dsa à cause de la ligne

Skipping ssh-dss key: ........... not in PubkeyAcceptedKeyTypes

Il n'y a pas de disque crypté côté serveur. Des idées comment progresser? Voici les informations de débogage du démon ssh:

sudo /usr/sbin/sshd -d
====
debug1: sshd version OpenSSH_6.6.1, OpenSSL 1.0.1f 6 Jan 2014
debug1: key_parse_private2: missing begin marker
debug1: read PEM private key done: type RSA
debug1: private host key: #0 type 1 RSA
debug1: key_parse_private2: missing begin marker
debug1: read PEM private key done: type DSA
debug1: private host key: #1 type 2 DSA
debug1: key_parse_private2: missing begin marker
debug1: read PEM private key done: type ECDSA
debug1: private host key: #2 type 3 ECDSA
debug1: rexec_argv[0]='/usr/sbin/sshd'
debug1: rexec_argv[1]='-d'
Set /proc/self/oom_score_adj from 0 to -1000
debug1: Bind to port 22 on 0.0.0.0.
Server listening on 0.0.0.0 port 22.
debug1: Bind to port 22 on ::.
Server listening on :: port 22.
debug1: Server will not fork when running in debugging mode.
debug1: rexec start in 5 out 5 newsock 5 pipe -1 sock 8
debug1: inetd sockets after dupping: 3, 3
Connection from xxx port 63521 on yyy port 22
debug1: Client protocol version 2.0; client software version OpenSSH_7.1
debug1: match: OpenSSH_7.1 pat OpenSSH* compat 0x04000000
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.6.1p1 Ubuntu-2ubuntu2.3
debug1: permanently_set_uid: 115/65534 [preauth]
debug1: list_hostkey_types: ssh-rsa,ssh-dss,ecdsa-sha2-nistp256 [preauth]
debug1: SSH2_MSG_KEXINIT sent [preauth]
debug1: SSH2_MSG_KEXINIT received [preauth]
debug1: kex: client->server [email protected] <implicit> none [preauth]
debug1: kex: server->client [email protected] <implicit> none [preauth]
debug1: expecting SSH2_MSG_KEX_ECDH_INIT [preauth]
debug1: SSH2_MSG_NEWKEYS sent [preauth]
debug1: expecting SSH2_MSG_NEWKEYS [preauth]
debug1: SSH2_MSG_NEWKEYS received [preauth]
debug1: KEX done [preauth]
debug1: userauth-request for user damian service ssh-connection method none [preauth]
debug1: attempt 0 failures 0 [preauth]
debug1: PAM: initializing for "damian"
debug1: PAM: setting PAM_RHOST to "freebox-server.local"
debug1: PAM: setting PAM_TTY to "ssh"
Connection closed by xxxx [preauth]
debug1: do_cleanup [preauth]
debug1: monitor_read_log: child log fd closed
debug1: do_cleanup

Voici la sortie verbeuse ssh:

$ ssh -v user@server
OpenSSH_7.1p1, OpenSSL 1.0.2d 9 Jul 2015
debug1: Connecting to server [xxxx] port 22.
debug1: Connection established.
debug1: key_load_public: No such file or directory
debug1: identity file /home/user/.ssh/id_rsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/user/.ssh/id_rsa-cert type -1
debug1: identity file /home/user/.ssh/id_dsa type 2
debug1: key_load_public: No such file or directory
debug1: identity file /home/user/.ssh/id_dsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/user/.ssh/id_ecdsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/user/.ssh/id_ecdsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/user/.ssh/id_ed25519 type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/user/.ssh/id_ed25519-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_7.1
debug1: Remote protocol version 2.0, remote software version OpenSSH_6.6.1p1 Ubuntu-2ubuntu2.3
debug1: match: OpenSSH_6.6.1p1 Ubuntu-2ubuntu2.3 pat OpenSSH_6.6.1* compat 0x04000000
debug1: Authenticating to server:22 as 'user'
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client [email protected] <implicit> none
debug1: kex: client->server [email protected] <implicit> none
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ecdsa-sha2-nistp256 SHA256:v4BNHM0Q33Uh6U4VHenA9iJ0wEyi8h0rFVetbcXBKqA
debug1: Host 'server' is known and matches the ECDSA host key.
debug1: Found key in /home/user/.ssh/known_hosts:2
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Trying private key: /home/user/.ssh/id_rsa
debug1: Skipping ssh-dss key /home/user/.ssh/id_dsa for not in PubkeyAcceptedKeyTypes
debug1: Trying private key: /home/user/.ssh/id_ecdsa
debug1: Trying private key: /home/user/.ssh/id_ed25519
debug1: Next authentication method: password
user@server's password:
ssh password authentication Damo
la source
1
Voir aussi superuser.com/q/1016989/93541 pour le même problème (et essentiellement la même solution).
DW
Notez que si sshd_config sur la destination a PubkeyAuthentication no , vous serez toujours invité à entrer un mot de passe. Définissez-le sur yes et redémarrez sshd (sur l'hôte de destination) pour activer l'authentification par clé publique.
C. Kelly

Réponses:

84

La nouvelle version openssh (7.0+) déconseille les clés DSA et n'utilise pas les clés DSA par défaut (ni sur le serveur ni sur le client). Les touches ne sont plus préférées, donc si vous le pouvez, je vous recommanderais d’ utiliser les clés RSA dans la mesure du possible.

Si vous avez vraiment besoin d'utiliser des clés DSA, vous devez les autoriser explicitement dans votre configuration client à l'aide de

PubkeyAcceptedKeyTypes +ssh-dss

Cela devrait suffire à mettre cette ligne ~/.ssh/config, car le message commenté essaie de vous dire.

Jakuje
la source
5
+1, mais un meilleur conseil serait d'utiliser un autre type de clé, non déprécié ...
jasonwryan
@jasonwryan Merci pour votre commentaire. Certainement. Je vais mettre à jour la réponse.
Jakuje
Merci Jakuje! Cela a du sens, je ne savais pas que dsa était vieux. J'ai généré une nouvelle paire de clés ssh-keygenrsa est la valeur par défaut maintenant. Je vais essayer de me connecter avec cela de l'autre machine demain.
Damo
Si vous ~/.ssh/confign'existez pas, créez-le. Et rappelez - vous de définir les autorisations corect: chmod 600 ~/.ssh/config.
Florian Brucker
@knb ne fait pas ça. Cela évitera d'utiliser d'autres algorithmes à l'avenir, car vous avez supprimé tous les algorithmes de courbe elliptique.
Jakuje
2

Dans mon cas, je rencontrais ce problème car un autre utilisateur avait modifié l' AuthorizedKeysFileemplacement. Comme il n'y avait pas authorized_keysd'autres utilisateurs à cet emplacement, le mot de passe de connexion serait défini par défaut, même s'il authorized_keysexistait avec les autorisations appropriées dans le répertoire de base par défaut.

AuthorizedKeysFile   /etc/ssh/%u/authorized_keys

Commenté cette sortie modifiée et redémarré le service sshd pour revenir au paramètre par défaut, ce qui a ensuite permis aux autres utilisateurs de s’authentifier à l’aide de leurs clés.

GotGame
la source
Je viens de résoudre un problème similaire sur un système RHEL7 où le contexte SELinux n'était pas correctement initialisé sur le répertoire de l'utilisateur. Ssh n'a donc pas été en mesure de lire le fichier de clés autorisées malgré les autorisations standard. J'ai fini par courir restorecon -Rv /homepour résoudre le problème pour les autres utilisateurs qui étaient également configurés de manière incorrecte sur le même système.
dannysauer
1

J'ai essayé la réponse de Jakuje Pas de chance. Mais je comprends le problème à partir de là. J'ai essayé d'ajouter un commentaire, mais j'ai besoin de la réputation d'avoir ajouté une réponse.

Mais le fichier de configuration pour moi / etc / ssh / ssh_config

  1. sudo nano /etc/ssh/ssh_config
  2. PubkeyAcceptedKeyTypes +ssh-dss Ajout de cette ligne en bas.
  3. Enregistrez et essayez à nouveau.

Travaillé!

SWAPNIL DEWALKAR
la source
1

Juste pour résumer ce que j'ai fait pour SSH to framboise Pi .

Sur la machine serveur (framboise Pi): 

$ ip addr show

ou simplement ip a, ceci affichera l'adresse IP de la machine Pi - host_ip

$ mkdir .ssh

Dans la machine client (Ubuntu):

$ ssh-keygen -t rsa

Nous remercions @Jakuje ci-dessus. J'utilisais initialement ssh-keygen -t dsa pour la génération de clés, et ssh n'arrêtait pas de me demander un mot de passe. ssh -v ip-address ne me donne pas beaucoup d'informations utiles, jusqu'à ce que je voie la réponse de @ Jakuje

$ cat .ssh/id_rsa.pub | ssh user_id@host_ip 'cat >> ~/.ssh/authorized_keys'

remplacez user_id et host_ip, lorsque vous y êtes invité, indiquez le mot de passe de la machine Pi

$ ssh user@ip_address

connecté avec succès à PI, plus de mot de passe

VictorL
la source
0

Dsa n'a pas fonctionné pour moi. rsa fait.

ssh-keygen -t rsa -P '' -f ~/.ssh/id_rsa
cat /Users/user_name/.ssh/id_dsa.pub >> ~/.ssh/authorized_keys

Et je peux ssh sans mot de passe.

Rodya
la source