Solved SSH disaster... (vultr SSHD_CONFIG basic setup)

freezr

freezr

Hi there,

I spent all the day asking me why SSH requests the password instead of the key to eventually realize I do not have even the key installed yet on this FreeBSD machine.

I setup on the server sshd_config this way:

Code: 
PubkeyAuthentication yes   
ChallengeResponseAuthentication yes
PermitRootLogin no
PasswordAuthentication no

But the setup is totally ignored, anyone who knows the user and the host ip can brute force the SSH password, what I am doing wrong?

Shouldn't the sshd daemon forbid any connection without the key?

Thanks ?
 
I'm not sure what exactly your problem is - let alone what the "disaster" is so I will focus on this:

freezr said:
But the setup is totally ignored, anyone who knows the user and the host ip can brute force the SSH password, what I am doing wrong?
Click to expand...
There are plenty of ways to detect and block bruteforcers. A popular choice is security/fail2ban.
Personally, I usually use pf's built-in rate control:
Code: 
pass in quick on $if_lan0 proto tcp from any to any port ssh flags S/SA keep state (max-src-conn 10, max-src-conn-rate 20/3600, overload <bruteforce> flush global)
You can also get commercial products for this sort of thing.

freezr said:
Shouldn't the sshd daemon forbid any connection without the key?
Click to expand...
You still have PAM authentication enabled. In your config you'd want to set ChallengeResponseAuthentication to off to disable PAM authentication.
 
Also check if rights of your files located in $HOME/.ssh are valid. If they are "too open" (rw for group or other) sshd won't allow you to login. When debugging ssh problems it's also good to use client with "-vvv" option.
 
A reload of sshd is enough. From the client: ssh -v server, post the content so people can see what the client sees. Your .ssh directory, and even it's parent directory, on the server might have the wrong permissions. Also server side logs, dig those up.

edit: I subsequently notice I've kinda repeated a lot of what 3301 already said, same but a bit different...
 
You can also use:
Code: 
AuthenticationMethods publickey
To have just only publickey, or even better you can setup some totp and then
Code: 
AuthenticationMethods publickey,keyboard-interactive:pam
Note that with the latter, if you didn't setup some totp (like with security/pam_google_authenticator), you will be asked to enter password + to have the public key.
 
Sorry for the misleading title...

Mr. jbodenmann It was a disaster in the terms that it might likely happen. The problem is not a brute-force attack but the fact that the connection is happening without using the keys...

Things that I do not understand...
  1. If I setup AuthenticationMethods publickey, it must deny any other connections, this is not happening.
  2. If I restart the SSH deamon while connected, I guess it should kick me off, this is not happening. That is more less what wrote Mr. SirDice.
[EDIT]

While writing this reply I think I solved the issue using the suggestion from Mr. VladiBG

ChallengeResponseAuthentication no

The line above must be uncommented with no as value; otherwise the default setup is a recipe for a disaster!

Thanks to all for your help, you are all A W E S O M E! ?
 
Just to recap the changes I did for the sshd_config file:

Code: 
PubkeyAuthentication yes            (line 41)
ChallengeResponseAuthentication no  (line 65)
PermitRootLogin no                  (line 123)
PasswordAuthentication no           (line 124)
 
Were you actually able to login with ChallengeResponseAuthentication set to yes and PasswordAuthentication set to no or did you just get prompted for a password and assumed it was the case?
 
msplsh said:
Were you actually able to login with ChallengeResponseAuthentication set to yes and PasswordAuthentication set to no or did you just get prompted for a password and assumed it was the case?
Click to expand...

Without having the keys installed on my machine and this setup:

Code: 
PubkeyAuthentication yes
ChallengeResponseAuthentication yes
PasswordAuthentication no

I was able to login with the user password alone.

Still without the keys installed when I changed to:

Code: 
PubkeyAuthentication yes
ChallengeResponseAuthentication no
PasswordAuthentication no

Connection was refused because didn't have the key.

When I copied the keys and fixed their permissions still was unable to get the connection until I cleaned up the "known_hosts" file.

After this very last change I was able to connect through SSH as expected, thanks!

f.
 
Interesting, PasswordAuthentication no doesn't disable PAM "keyboard-interactive" password authentication via ChallengeResponseAuthentication. Probably not what people are expecting.
 
msplsh said:
Interesting, PasswordAuthentication no doesn't disable PAM "keyboard-interactive" password authentication via ChallengeResponseAuthentication. Probably not what people are expecting.
Click to expand...

It is important to mention that:

"ChallengeResponseAuthentication"

By default is commented and looks that its default behavior is assumed as "YES", therefore you could ssh connect from anywhere with user@host and user-password; only after uncommenting that line and setting the value on "NO", keys and passphrase started to work properly.
 
In FreeBSD 13.1 version of sshd_config it's changed to KbdInteractiveAuthentication

KbdInteractiveAuthentication
Specifies whether to allow keyboard-interactive authentication.
All authentication styles from login.conf(5) are supported. The
default is yes. The argument to this keyword must be yes or no.
ChallengeResponseAuthentication is a deprecated alias for this.
Click to expand...
 
You must log in or register to reply here.
Back
Top