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

centossshd

I have the following use case:

  • Need to allow users to login from a secured, trusted network
  • and then allowing a couple (only two) mobile users to login remotely on a Linux Centos machine.

I can make the sshd run on different ports e.g.:

  • from inside it is okay to make it run on 22 as I don't want to make them connect on other ports (messes up the script).
  • For outside mobile users, I will run the sshd on a different port, say port X (increased security – this is a small office kind of setup).

For added security, I was hoping to configure sshd to allow access to only particular users on port X (and then configure some alerts so that we can know when users are logging in through port X).

However, I am unable to find any configuration like this in sshd documentation. If there is no solution like this, is it at least possible to trigger a shell script to run whenever someone completes sshd login on port X? I was looking at iptables documentation to see if it could trigger an alert when sshd login is there but could not come up with anything.

Inputs appreciated

Best Answer

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.

Related Question