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.

You can add something like this to your /etc/ssh/sshd_config:

AllowUsers mobileuser1 mobileuser2 *@10.0.0.0/8

The above assumes that the permitted remote users are named mobileuser1 and mobileuser2, and that your trusted network is 10.0.0.0 with subnet mask 255.0.0.0.

This allows the two mobile users to log in from anywhere and everyone to log in from the trusted network. Any user that doesn't match any of those patterns (such as user foo logging in from remote) will be denied access.

You can do this by starting two ssh daemons and two sshd_config files. Copy your existing one (e.g. from /etc/ssh/sshd_config /etc/ssh/sshd_alt_config and in the alternative config setup (from the man page for sshd_config:

Port

Specifies the port number that sshd(8) listens on.  The default
is 22.  Multiple options of this type are permitted.  See also
ListenAddress

AllowUsers

This keyword can be followed by a list of user name patterns,
separated by spaces.  If specified, login is allowed only for
user names that match one of the patterns.  Only user names are
valid; a numerical user ID is not recognized.  By default, login
is allowed for all users.  If the pattern takes the form
USER@HOST then USER and HOST are separately checked, restricting
logins to particular users from particular hosts.  The
allow/deny directives are processed in the following order:
DenyUsers, AllowUsers, DenyGroups, and finally AllowGroups.

You probably want to have the alternative ssh log to a different file, and e.g. follow what is written to that file to notice aberrant login attempts.