Ssh – allow only specific users to login via sshd, but refuse connect to non-listed users

hostspamsshd

I'm running a CentOS server (7.0) and I'd like to login via sshd as a user, not root. So I set PermitRootLogin no in the config file and su - after login. I've received lots of hacking activities and I decided to allow only one user to login via sshd. Since the username is not my real name or any common name, I think it would be good enough. Let's say it's 'hkbjhsqj'.

I've tried both ways introduced on nixCraft: AllowUsers in sshd_config or pam_listfile.so in PAM. The only problem to me is that anyone else still has chances to type in passwords and that leaves records in /var/log/secure. I assume these actions consumes my server's resources to run password checking and other stuff.

Let's say I try to login with the username 'admin':

www$ ssh admin@0.0.0.0
admin@0.0.0.0's password:
Permission denied, please try again.
admin@0.0.0.0's password:
Permission denied, please try again.
admin@0.0.0.0's password:
Permission denied (publickey,gssapi-keyex,gssapi-with-mic,password).

and in the secure log:

Aug  8 08:28:40 www sshd[30497]: pam_unix(sshd:auth): check pass; user unknown
Aug  8 08:28:40 www sshd[30497]: pam_listfile(sshd:auth): Refused user admin for service sshd
Aug  8 08:28:43 www sshd[30497]: Failed password for invalid user admin from 192.168.0.1 port 52382 ssh2
Aug  8 08:28:47 www sshd[30497]: pam_unix(sshd:auth): check pass; user unknown
Aug  8 08:28:47 www sshd[30497]: pam_listfile(sshd:auth): Refused user admin for service sshd
Aug  8 08:28:50 www sshd[30497]: Failed password for invalid user admin from 192.168.0.1 port 52382 ssh2
Aug  8 08:28:52 www sshd[30497]: pam_unix(sshd:auth): check pass; user unknown
Aug  8 08:28:52 www sshd[30497]: pam_listfile(sshd:auth): Refused user admin for service sshd
Aug  8 08:28:55 www sshd[30497]: Failed password for invalid user admin from 192.168.0.1 port 52382 ssh2
Aug  8 08:28:55 www sshd[30497]: Connection closed by 192.168.0.1 [preauth]
Aug  8 08:28:55 www sshd[30497]: PAM 2 more authentication failures; logname= uid=0 euid=0 tty=ssh ruser= rhost=192.168.0.1

While all this will not happen if I add the IP in /etc/hosts.deny:

www$ ssh admin@0.0.0.0
ssh_exchange_identification: Connection closed by remote host

and in the secure log:

Aug  8 08:35:11 www sshd[30629]: refused connect from 192.168.0.1 (192.168.0.1)
Aug  8 08:35:30 www sshd[30638]: refused connect from 192.168.0.1 (192.168.0.1)

So my question would be, is there a way I can refuse all irrelevant users' ssh requests from anywhere without password checking, like I put them in the hosts.deny list? But at the same time I do need allow all ssh requests with the username 'hkbjhsqj' from anywhere and check the password then.

Best Answer

I don't think it is possible to do what you are asking. If you could, someone could "brute force" to find valid usernames on your server. I am also pretty sure that the username and the password are sent simultaneously by the client, you could verify this by capturing packets using Wireshark on an unencrypted SSH connection.

By "hacking activities" I assume you are talking about brute force attempts at passwords. There are many ways to protect yourself from this, I will explain the most common ways.

Disable root login By denying root login with SSH the attacker has to know or guess a valid username. Most automated brute force attacks only try logging in as root.

Blocking IPs on authentication failure Daemons like fail2ban and sshguard monitor your log files to detect login failures. You can configure these to block the IP address trying to log in after a number of failed login attempts. In your case this is what I would recommend. This reduces log spam and strain on your server, as all packets from this IP would be blocked before they reach the sshd daemon. Your could, for example, set fail2ban to block IPs with 3 login failures in the last 5 minutes for 60 minutes. You will in the worst cases see three failed logins in your log every 60 minutes, assuming the attacker does not give up and move on.

Public key authentication You can disable password authentication entirely and only allow clients with specific keys. This is often considered to be the most secure solution (assuming the client keeps his key safe and encrypted). To disable password authentication, add your public key to ~/.ssh/authorized_keys on the server and set PasswordAuthentication to no in sshd_config. There are numerous tutorials and tools to assist with this.

Related Solutions

Ssh – Allowing only specific users to login via ssh at one port and others to login via another port

Running SSH on an alternate port doesn't count as security anymore. It only adds a slight bit of obscurity, and an added step of complexity for your users. It adds zero obstacles for people looking to break your network, who are using automated port scanners and don't care what port it's running on.

If you want to bolster security on a system that's allowing remote internet-based inbound SSH, control your users in the sshd_config as @Anthon indicated, and then also implement security directly in PAM.

Create two groups, lusers and rusers. Add the remote mobile users to the rusers group. Use the pam_succeed_if.so PAM module to permit access to those users. Add lines to your pam config for ssh:

account     sufficient  pam_succeed_if.so user ingroup lusers
account     sufficient  pam_succeed_if.so user ingroup rusers

Some pam_succeed_if.so modules may require you to use slightly different syntax, like group = lusers.

Then, not only is sshd limiting the users that can connect, but in the event of a bug in sshd, you still have the protection that the PAM based restrictions offer.

One additional step for the remote users is to force the use of ssh_keys with passphrases. So, local users can login with keys or passwords, but remote users must have a key, and if you create the keys for them, you can make sure the key has a passphrase associates. Thus limiting access to locations that actually possess the SSH key and the passphrase. And limiting potential attack vectors if a user's password is compomised.

In sshd_config:

change 2 settings:

ChallengeResponseAuthentication yes

and

PasswordAuthentication yes

to:

ChallengeResponseAuthentication no

and

PasswordAuthentication no

So, the default is to now allow only key authentication. Then for local users you can user the match config setting to change the default for local users. Assuming your local private network is 192.168.1.0/24, add to sshd_config:

Match Address 192.168.1.0/24
PasswordAuthentication yes

Now, the local users can connect with passwords or keys, and remote users will be forced to use keys. It's up to you to create the keys with pass-phrases.

As an added benefit, you only have to manage a single sshd_config, and you only have to run ssh on a single port, which eases your own management.

edit 2017-01-21 - Limiting the use of authorized_keys files.

If you want to make sure that users cannot just self generate an ssh key, and use it with an authorized_keys file to login, you can control that by setting a specific location for sshd will look for authorized keys.

In /etc/ssh/sshd_config, change:

AuthorizedKeysFile  %h/ssh/authorized_keys

to something like:

AuthorizedKeysFile  /etc/.ssh/authorized_keys/%u

Pointing to a controlled directory that users don't have permissions to write to means they can't generate their own key and use it to work around the rules you've put in place.

Ssh – Cannot login or ssh to non-admin Cygwin user this month but could last month and still can for other non-admin user

After further research (here and here) I'm inclined to think the issue is NOT with Cygwin but rather with Windows 10. A light-bulb turned on in my head when I was in User2's Windows account yesterday and noticed I could launch Task Manager without a UAC prompt--something I knew User1 was always prompted for post Windows 10 upgrade from Windows 8 (despite that upgrade taking place almost a year ago during the free upgrade to Win 10 promotion). I figured it was a Windows 10 thing and never thought twice. When I realized it was happening prompt-free for User2 and googled work-arounds to fix it for User1, I found I could use the same work-around for User1's Cygwin issue. It still doesn't answer how User1's account got messed up in the first place, nor how to actually fix it the correct way, but I'm satisfied with this work-around as I can now get my git changes done for User1.

TL;DR

WORK-AROUND:

Open command-line (CMD.EXE) and set this variable to stop getting the UAC pop-up prompt:


set __compat_layer=runasinvoker

From the same terminal the environment variable was set, launch Cygwin:


c:\cygwin64\bin\mintty.exe

To make this permanent for this user (and make the desktop icon work again)


setx __compat_layer "runasinvoker"

To make this permanent for all users machine-wide, open admin command-line, then:


setx /m __compat_layer "runasinvoker"

And finally, to access git without fixing Cygwin, install "Git Bash".

Caveat: With the User1 account still technically broken, I still cannot use ssh to login but I can at least get to local Cygwin Terminal as User1. Also this work-around does not fix ability to modify User1's Windows User Environment variables via sysdm.cpl GUI (still get UAC prompt and then after only shows Admin's ENV vars instead of User1's) but that's something for the Windows-related Stack Exchange forum now that I know this is a Windows account problem and not Cygwin's. And SETX allows altering user and machine ENV vars from command-line.

Best Answer

Related Solutions

Ssh – Allowing only specific users to login via ssh at one port and others to login via another port

Ssh – Cannot login or ssh to non-admin Cygwin user this month but could last month and still can for other non-admin user

Related Question