20

Somehow my SSH never wants to ask me for a password.

So I setup a VPS on some random server somewhere in the world and I want to connect to it with ssh.

I can setup a key, but when I do this:

ssh -l some-user IP

I get the error:

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

When I look at the details, I can see that password is one of the options:

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

Yet SSH never asks me for the password. It tries 5 times with what I suspect is the publickey method and then fails. Why wouldn't ssh try with the password?!

Just in case, my ssh_config file has:

PasswordAuthentication yes

Full log

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
0

5 Answers 5

22

Try to log in with Public Key Authentification disabled, using

ssh -o PubkeyAuthentication=no root@newserver
4
  • Okay! That worked! I tried the "opposite" without success... (i.e. -o PasswordAuthentication=yes). But this is what I was looking for. Feb 11, 2014 at 18:28
  • 5
    @AlexisWilke I'm glad that it works! But please read Olli's answer too. He' definitely right in that there is still something wrong with your .ssh/config. The -o PubkeyAuthentication=no is not nice as a permanent solution. Feb 11, 2014 at 18:32
  • This trick (-o PubkeyAuthentication=no) worked well on a machine with several identity files. Dec 1, 2015 at 15:01
  • guys, I want the default ssh functionality, ask for the password just one time for the section. but I can't do that. I changed the config and he asks about the password every single time
    – Guilherme
    Feb 22, 2022 at 9:29
20

Most probably you have more than one identityfile lines on your .ssh/config file.

Even if you have identityfile under host configuration, it is applied globally. What that means is that ssh tries every identity file (i.e public key) on every host, before it asks for password prompt from the server.

You can fix this by

  1. Removing all but one identityfile lines, or
  2. Adding PubkeyAuthentication no to .ssh/config, or
  3. Executing ssh with -o PubkeyAuthentication=no parameter.

From 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).

Some general instructions with public keys:

  1. In general, you should have only a single private key per client (workstation), and put matching public key to all servers that client should have access to. In other words, share public key between servers, and never use same private key on multiple devices.
  2. Always generate keypair on your device, and transmit only public key. That way, even if server is compromised, your private key is still safe and secure. This could happen in surprising ways - for example, through backups.
  3. If someone else administrates the server, you should provide a public key for them; they should not generate keypair and send private key to you. That way, they can't impersonate you with your key (of course, usually they can do whatever they want to). Also, with public key, only integrity (i.e someone did not change the public key) must be protected; with private key, confidentiality (i.e no-one else obtained the key) must be conserved, and it is not possible to be absolutely sure it was not compromised.
  4. Compromising a server does not compromise other servers, even if you use same private key for connecting to multiple servers (except if you transmitted that private key to the server. Never do that.)
  5. Compromising your workstation will expose your private keys anyway. Having multiple private keys does not help with this (except if you have different, strong passphrases, and not all of those are available for attacker).

There is some exceptions to this, but not too many.

3
  • 2
    Aaah! I have "too many" identify files and it checks with 5 of them and stops. Got it! That explains everything. I suppose I should move all of those in a sub-folder so that way they would not be found automatically and the password feature would work automatically again... Feb 11, 2014 at 18:32
  • 3
    If possible, you should/could use only single public key for every service you need. Very rarely there's a reason to do it in any other way. If someone steals your public key (contents of authorized_keys), they can't do anything with it. And if all your private keys (id_rsa/id_dsa) are on the same computer anyway, using more than one does not matter.
    – Olli
    Feb 11, 2014 at 18:46
  • 1
    related: security.stackexchange.com/q/40050
    – djvg
    Sep 13, 2022 at 8:51
4

Your local ssh shouldn't be asking you for a password, the ssh server on the other end should. It's likely that the server is set up to not accept password authentication. Mine wouldn't ask you for a password either.

4
  • 1
    The other server is a brand new server and they tell you to do exactly that. Not only that, my partner could log in no problem! Something's fishy on my computer that prevents it from testing for the password... Actually, if you look at the logs, the authorized authentication DOES include "password". Therefore, my local ssh client SHOULD ask me for the password, but it decides to skip on it. Feb 11, 2014 at 18:11
  • 1
    It's easier to see why the server won't prompt you for a password than to see why your client won't present you with that option if the server offers it. There are lots of configuration options on their end, and darned few on yours. It's possible that someone with your IP address has tried to log in too many times without the correct password, and future attempts from your IP have been disabled. Shoot, I just read Olli's answer. That's it.
    – Marc
    Feb 11, 2014 at 20:11
  • Good story. Now the solution... Jul 13, 2020 at 15:16
  • @JhourladEstrella The solution is the selected answer. Don't have more than 2 or 3 keys directly in your ~/.ssh folder. It will present a few of them to the server and then the server will close the connection. That means the ssh binary never has the time to ask for your password. Instead, I now put my keys (other than my main id_rsa) under ~/.ssh/other_keys. Oct 29, 2021 at 19:51
1

In my experience, I found that a parameter was commented out in /etc/pam.d/sshd , as below.

#  diff cwe-pam-sshd /etc/pam.d/sshd
3c3
< auth       include      password-auth
---
> #auth       include      password-auth
1
  • 1
    Oh! That's a location I don't know about... Aug 28, 2020 at 19:34
1

Another cause I found. I had:

Host *
   PreferredAuthentications publickey

in ~/.ssh/config (copied from another user, thinking it was "preference"). Actually PreferredAuthentications specifies "allowed" methods and order.

Either delete the PreferredAuthentications line or add password

Host *
   PreferredAuthentications publickey,password

Note: No space after the comma!

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .