ssh ne demande jamais de mot de passe

14

D'une manière ou d'une autre, mon SSH ne veut jamais me demander de mot de passe.

J'ai donc installé un VPS sur un serveur aléatoire quelque part dans le monde et je veux me connecter avec ssh.

Je peux configurer une clé, mais quand je le fais:

ssh -l some-user IP

Je reçois l'erreur:

Received disconnect from ##.##.##.##: 2: Too many authentication failures for some-user

Quand je regarde les détails, je peux voir que le mot de passe est l'une des options:

debug1: Offering RSA public key: some-user@computer
debug1: Authentications that can continue: publickey,password

Pourtant, SSH ne me demande jamais le mot de passe. Il essaie 5 fois avec ce que je pense être la méthode publickey et échoue. Pourquoi ssh n'essaierait-il pas avec le mot de passe?!

Au cas où, mon fichier ssh_config a:

PasswordAuthentication yes

Journal complet

ssh -v -l root ##.##.##.##
OpenSSH_6.1p1 Debian-4, OpenSSL 1.0.1c 10 May 2012
debug1: Reading configuration data /home/someuser/.ssh/config
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: Connecting to ##.##.##.## [##.##.##.##] port 22.
debug1: Connection established.
debug1: identity file /home/someuser/.ssh/id_rsa type 1
debug1: Checking blacklist file /usr/share/ssh/blacklist.RSA-2048
debug1: Checking blacklist file /etc/ssh/blacklist.RSA-2048
debug1: identity file /home/someuser/.ssh/id_rsa-cert type -1
debug1: identity file /home/someuser/.ssh/id_dsa type -1
debug1: identity file /home/someuser/.ssh/id_dsa-cert type -1
debug1: identity file /home/someuser/.ssh/id_ecdsa type -1
debug1: identity file /home/someuser/.ssh/id_ecdsa-cert type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_6.2p2 Ubuntu-6
debug1: match: OpenSSH_6.2p2 Ubuntu-6 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.1p1 Debian-4
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5 none
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: sending SSH2_MSG_KEX_ECDH_INIT
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ECDSA XX:XX:...:XX:XX
debug1: Host '##.##.##.##' is known and matches the ECDSA host key.
debug1: Found key in /home/someuser/.ssh/known_hosts:38
debug1: ssh_ecdsa_verify: signature correct
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: Offering RSA public key: /home/someuser/.ssh/id_rsa
debug1: Authentications that can continue: publickey,password
debug1: Offering RSA public key: someuser@computer
debug1: Authentications that can continue: publickey,password
debug1: Offering RSA public key: someuser@computer
debug1: Authentications that can continue: publickey,password
debug1: Offering DSA public key: someuser@computer
debug1: Authentications that can continue: publickey,password
debug1: Offering RSA public key: someuser@computer
debug1: Authentications that can continue: publickey,password
debug1: Offering RSA public key: someuser@computer
Received disconnect from ##.##.##.##: 2: Too many authentication failures for root

ssh password Alexis Wilke
la source

17

Essayez de vous connecter avec l'authentification par clé publique désactivée, en utilisant

ssh -o PubkeyAuthentication=no root@newserver

Klaus-Dieter Warzecha
la source

D'accord! Ça a marché! J'ai essayé le "contraire" sans succès ... (ie -o PasswordAuthentication=yes). Mais c'est ce que je cherchais.

Alexis Wilke

3

@AlexisWilke Je suis content que cela fonctionne! Mais lisez également la réponse d'Olli. Il a définitivement raison en ce qu'il y a toujours quelque chose qui ne va pas avec votre .ssh/config. Ce -o PubkeyAuthentication=non'est pas bien comme solution permanente.

Klaus-Dieter Warzecha

Cette astuce (-o PubkeyAuthentication = no) fonctionnait bien sur une machine avec plusieurs fichiers d'identité.

Valerio Schiavoni

17

Vous avez probablement plus d'une identityfileligne dans votre .ssh/configfichier.

Même si vous avez identityfilesous hostconfiguration, il est appliqué globalement. Cela signifie que sshchaque fichier d'identité (c'est-à-dire la clé publique) doit être testé sur chaque hôte avant de demander une invite de mot de passe au serveur.

Vous pouvez résoudre ce problème en

Supprimer toutes les identityfilelignes sauf une , ou
Ajout PubkeyAuthentication noà .ssh/config, ou
Exécution de ssh avec -o PubkeyAuthentication=noparamètre.

De man 5 ssh_config:

PubkeyAuthentication
    Specifies whether to try public key authentication.  The argument to this
    keyword must be “yes” or “no”.  The default is “yes”.  This option applies 
    to protocol version 2 only.

IdentityFile
    ...
    It is possible to have multiple identity files specified in configuration
    files; all these identities will be tried in sequence.  Multiple 
    IdentityFile directives will add to the list of identities tried (this 
    behaviour differs from that of other configuration directives).

Quelques instructions générales avec les clés publiques:

En général, vous ne devez avoir qu'une seule clé privée par client (poste de travail) et mettre la clé publique correspondante sur tous les serveurs auxquels le client doit avoir accès. En d'autres termes, partagez la clé publique entre les serveurs et n'utilisez jamais la même clé privée sur plusieurs appareils.
Générez toujours une paire de clés sur votre appareil et transmettez uniquement la clé publique. De cette façon, même si le serveur est compromis, votre clé privée est toujours sûre et sécurisée. Cela peut se produire de manière surprenante - par exemple, par le biais de sauvegardes.
Si quelqu'un d'autre administre le serveur, vous devez lui fournir une clé publique; ils ne doivent pas générer de paire de clés et vous envoyer une clé privée. De cette façon, ils ne peuvent pas vous imiter avec votre clé (bien sûr, ils peuvent généralement faire ce qu'ils veulent). De plus, avec la clé publique, seule l'intégrité (c'est-à-dire que quelqu'un n'a pas changé la clé publique) doit être protégée; avec la clé privée, la confidentialité (c'est-à-dire que personne d'autre n'a obtenu la clé) doit être conservée, et il n'est pas possible d'être absolument sûr qu'elle n'a pas été compromise.
Compromettre un serveur ne compromet pas les autres serveurs, même si vous utilisez la même clé privée pour vous connecter à plusieurs serveurs (sauf si vous avez transmis cette clé privée au serveur. Ne faites jamais cela.)
Compromis de votre poste de travail exposera de toute façon vos clés privées. Avoir plusieurs clés privées n'aide pas à cela (sauf si vous avez des phrases de passe différentes et fortes, et que toutes ne sont pas disponibles pour l'attaquant).

Il y a quelques exceptions, mais pas trop.

Olli
la source

2

Aaah! J'ai "trop" de fichiers d'identification et il vérifie avec 5 d'entre eux et s'arrête. Je l'ai! Cela explique tout. Je suppose que je devrais déplacer tous ceux-ci dans un sous-dossier afin qu'ils ne soient pas trouvés automatiquement et que la fonction de mot de passe fonctionne à nouveau automatiquement ...

Alexis Wilke

3

Si possible, vous devez / pourriez utiliser une seule clé publique pour chaque service dont vous avez besoin. Il y a très rarement une raison de le faire d'une autre manière. Si quelqu'un vole votre clé publique (contenu de authorized_keys), il ne peut rien en faire. Et si toutes vos clés privées ( id_rsa/ id_dsa) sont de toute façon sur le même ordinateur, en utiliser plusieurs n'a pas d'importance.

Olli

4

Votre ssh local ne devrait pas vous demander de mot de passe, le serveur ssh à l'autre bout devrait le faire. Il est probable que le serveur soit configuré pour ne pas accepter l'authentification par mot de passe. Le mien ne vous demanderait pas non plus un mot de passe.

Marc
la source

1

L'autre serveur est un tout nouveau serveur et ils vous disent de faire exactement cela. Non seulement cela, mon partenaire n'a pu se connecter sans problème! Quelque chose de louche sur mon ordinateur qui l'empêche de tester le mot de passe ... En fait, si vous regardez les journaux, l'authentification autorisée DOIT inclure "mot de passe". Par conséquent, mon client ssh local DEVRAIT me demander le mot de passe, mais il décide de l'ignorer.

Alexis Wilke

Il est plus facile de voir pourquoi le serveur ne vous demandera pas de mot de passe que de voir pourquoi votre client ne vous proposera pas cette option si le serveur la propose. Il y a beaucoup d'options de configuration de leur côté et sacrément peu de vôtres. Il est possible qu'une personne possédant votre adresse IP ait tenté de se connecter trop de fois sans le mot de passe correct et que les tentatives futures de votre adresse IP aient été désactivées. Shoot, je viens de lire la réponse d'Olli. C'est ça.

Marc

ssh ne demande jamais de mot de passe

Réponses: