ssh never ask for a password

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

Solution 1:

Try to log in with Public Key Authentification disabled, using

ssh -o PubkeyAuthentication=no root@newserver

Solution 2:

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.

Solution 3:

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.

Solution 4:

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