Question

20

ssh never ask for a password

rated 0 times [ 20] [ 0] / answers: 1 / hits: 30809 / 1 Year ago, thu, march 2, 2023, 9:54:00

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

Answers

Only authorized users can answer the question. Please sign in first, or register a free account.

initiallartebeest

Add To Favorites

Follow

Total Points: 24

Total Questions: 118

Total Answers: 105

Location: Venezuela

Member since Thu, Jul 15, 2021

3 Years ago

answered 1 Year ago darpose · Accepted Answer

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

Removing all but one identityfile lines, or

Adding PubkeyAuthentication no to .ssh/config, or

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:

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.

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.

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.

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

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.