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,
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.
change 2 settings:
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
Match Address 192.168.1.0/24
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
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.
to something like:
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.