Take the 2-minute tour ×
Ask Ubuntu is a question and answer site for Ubuntu users and developers. It's 100% free, no registration required.

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
share|improve this question

3 Answers 3

up vote 13 down vote accepted

Try to log in with Public Key Authentification disabled, using

ssh -o PubkeyAuthentication=no root@newserver
share|improve this answer
    
Okay! That worked! I tried the "opposite" without success... (i.e. -o PasswordAuthentication=yes). But this is what I was looking for. –  Alexis Wilke Feb 11 at 18:28
3  
@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. –  Klaus Warzecha Feb 11 at 18:32

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.

share|improve this answer
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... –  Alexis Wilke Feb 11 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 at 18:46

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.

share|improve this answer
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. –  Alexis Wilke Feb 11 at 18:11
    
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 at 20:11

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.