Question

Unable to bypass sudo Password prompt on SSH

I have deployed my public key on to authorized keys.

All was fine till a couple of hours ago, when Logging in via SSH with RSA PK Auth

started prompting for a sudo password.

I checked Auth.log , and it says

Public Key Accepted.

One weird thing I noticed was, There were Millions of entries that logged

Opened a session for root

Immediately after It said

Public key accepted

Probably because it prompted me for a sudo password?

There are also millions of entries logging

Maximum login attempts reached for root @ port 472 from an IP I dont recognise

which were all blocked thanks to the firewall.

Also weird is, Once I do login,

When I run

ps -aux | grep ssh

I get a long list of root logins on the SSH process

I kill them, and they create a new one.

Why?


Submit an answer

This textbox defaults to using Markdown to format your answer.

You can type !ref in this text area to quickly search our full set of tutorials, documentation & marketplace offerings and insert the link!

Sign In or Sign Up to Answer

These answers are provided by our Community. If you find them useful, show some love by clicking the heart. If you run into issues leave a comment, or add your own answer to help others.

Accepted Answer

I Found the culprit!

It was a process called

hugepages

and it was doing

dev-hugepages.mount

on startup.

systemctl list-unit-files | grep hu

Gave it out

dev-hugepages.mount | static
sigpwr-container-shutdown.service | static

This, was running a shell script , to disable thp (Transparent huge page) on startup.

Like so:

sudo hugeadm --thp-never

This was one of the tweaks to memalloc for the Redis server on the VPS

** Solution : **

remove the shell script it ran from under \etc\init.d

reboot droplet

@jtittle

thanks for pointing me to this :

That being said, it’s hard to tell what’s going on. It looks like something is being executed after login (authentication) and it’s attempting to run something that would require root or sudo, thus you’re being prompted to authenticate before whatever command is running tries to execute.

@SchrodingersCat

When it comes to SSH and PubKey Authentication, it’s best to keep it as simple as possible unless you have a reason to drift from the norm. I can only speak from MacOS and Windows 10 at the moment as I don’t have a Linux box setup locally right now – only the remote Droplets.

I use Terminal on MacOS and PuTTy on Windows 10.

The known_hosts file on MacOS does store basic information and that, of course, prevents having to confirm the host that I’m connecting to. Beyond that, the key itself is not cached on either system, so to login, the passphrase for the key must still be used unless there’s no passphrase setup for the key.

I personally wouldn’t use anything that caches the passphrase of my keys, even on my own systems as that is substantially less secure and allows anyone that can gain access the ability to login.

That being said, it’s hard to tell what’s going on. It looks like something is being executed after login (authentication) and it’s attempting to run something that would require root or sudo, thus you’re being prompted to authenticate before whatever command is running tries to execute.

Using the details I provided above, your scenario is definitely not normal and shouldn’t happen unless you do have something that is set to run or execute after authentication, in which case, you’d need to find out what that is. It’s hard to tell when you’re just being prompted as it doesn’t provide any actual details on what’s going on.

In any normal circumstance, you’d run:

ssh user@host

or

ssh user@host -i /path/to/privkey

Confirm (if it’s the first connection), or enter your passphrase (if one is set), and you’re in.

I can’t think of anything off the top of my heard that would log you in and then immediately attempt to get you to authenticate your sudo user unless you’ve somehow been hacked and something is running in an attempt to gain your sudo password, thus allowing an attacker to get what they’re after.

That’s just a guess, not a claim, and is only based on the information you’re providing.

To test, I would setup a simple 512MB Droplet and run though the configuration I provided. With it, you should confirm once, authenticate with or without a passphrase, and either login and be denied (if the details are not correct).

@SchrodingersCat

If you’re logged in as root and using sudo, i.e.

sudo [command]

… then you shouldn’t be prompted for a password as you’re already running as root, thus there’s no higher escalation.

If you’re logged in a as a non-root user and prefixing commands with sudo, then you’ll be asked to confirm that users password before the command executes – that’s by design. Without prompting for the users password, you’re effectively running as root and that defeats the purpose of a sudo user.

Public Key authentication has nothing to do with anything other than initial authentication between your computer and the server (or between two servers). If you’re being prompted at initial login, that’s because you’ve most likely put a passphrase on your key (which is ideal), but that’s as far as that goes.

As for the failed logins, seeing failures is normal as the IP of your Droplet is public and most likely belonged to a user before you had it. It’s common to see attempts to break in, and what this boils down to is security and properly securing your server.

Ideally, you should:

1). Create a sudo user; 2). Setup SSH keys for that user (with a passphrase on the key); 3). Set a password for the sudo user that differs from your passphrass; 4). Confirm that you’re able to login as the sudo user using the key. 5). Confirm that you’re able to run sudo [command] as the user, and it works; 6). Lock the root account so that it can’t be used to login.

@SchrodingersCat

What tutorial/guide did you follow to setup the sudo user you’re referencing?

Ideally, if we just use password-based logins, we’d do the following as root:

useradd -d /home/username username
usermod -aG sudo username
passwd username

Once the password is set for the user, you now have a sudo user and can login using SSH. If we need to setup SSH Keys for the user, it’s a bit more involved.

mkdir -p /home/username/.ssh
touch /home/username/.ssh/authorized_keys
chown -R username:username /home/username/*
chmod 700 /home/username/.ssh
chmod 644 /home/username/.ssh/authorized_keys
usermod -aG sudo username
passwd username

You’d change username in the above to match that of the username you want to use as a sudo user. You would then add the public key to:

/home/username/.ssh/authorized_keys

Using:

nano /home/username/.ssh/authorized_keys

Paste and save.

As long as your SSH Configuration is setup to allow keys, then that should allow you to login using a public/private key pair as opposed to logging in with a password, but that won’t prevent you from being prompted for the passphrase on your SSH key (two entirely different things).

With the above, you’d have to run:

sudo [command]

On each command you run as that user. This should be enforced. If you’re able to run without sudo prefixing a command as a normal user added to the sudo group, then I’d say there’s something wrong with the setup.

It’s normal to not have to enter your password each time you run sudo [command] as authentication expires after a few minutes, so you can run a few commands without being prompted again.