Is it possible to have 2 ports open on SSH with 2 different authentication schemes?
I’m currently trying to set up an SSH server so that access to it from outside the network is ONLY allowed using an SSH Key and does not allow access to root or by any other username/password combination.
At the same time, internal users inside the network, still need to be able to connect to the same system, but expect to log in in the more traditional sense with a user name and password.
Users both external & internal will be accessing the system from windows using PuttySSH and the external access will be coming into the system via a port forwarding firewall that will open the source port to the outside world on some arbitrarily chosen high numbered port like 55000 (or what ever the admins decide)
The following diagram attempts to show the traffic flows better.
I know how to set up the actual login to only use keys, and I know how to deny root, what I don’t know is how to separate the two login types.
I had considered running two copies of SSHD listening on different ports on the same IP and having two different configurations for each port.
I also considered setting up a “match” rule, but I’m not sure if I can segregate server wide configurations using those options.
Finally, the external person logging in will always be the same user let’s call them “Frank” for the purposes of this question, so “Frank” will only ever be allowed to log in from the external IP, and never actually be sat in front of any system connecting internally, where as every other user of the system will only ever connect internally, and never connect from an external IP.
Franks IP that he connects from is a dynamically assigned one but the public IP he is connecting too is static and will never change, the internal IP of the port forwarder like wise will also never change and neither will the internal IP address of the SSH server.
Internal clients will always connect from an IP in the private network range that the internal SSH servers IP is part of and is a 16 bit mask EG: 192.168.0.0/16
Is this set up possible, using one config file and one SSH server instance? If so, how do I do it?
Am I much better using 2 running servers with different config?
For ref the SSH server is running on Ubuntu 18.04.
So, it turns out the answer was actually way, way simpler than I thought it would be.
I do however have to thank ‘@jeff schaller’ for his comments, if it hadn’t of been for him I wouldn’t have started looking into how the SSH ‘Match’ configuration works.
The trick is to set your /etc/ssh/sshd_config file up as default to be the configuration you would like to have for the access coming in from the external internet connection.
In my case, this meant setting the following
By doing this, I’m forcing ALL logins no matter where they come from to need to be key based logins using an SSH key.
I then on the windows machines used ‘PuttyGen’ to generate a public/private key pair which I saved to disk, and an appropriate ssh entry for my “authorized_hosts” file in the external users home directory.
I pasted this ssh key into the correct place in my users home folder, then set putty up to use the private (ppk) file generated by PuttyGen for log in and saved the profile.
I then saved the profile, and sent that and the ppk key file to the external user using a secure method (Encrypted email with a password protected zip file attached)
Once the user had the ppk and profile in their copy of putty and could log in, I then added the following as the last 2 lines on my sshd_config file
Match Host server1,server1.internalnet.local,126.96.36.199
In the “Match” line I’ve changed the server names to protect the names of my own servers.
Note each server domain is separated by a comma and NO SPACES, this is important. If you put any spaces in it causes SSHD to not load the config and report an error, the 3 matches I have in there do the following:
server1 – matches on anyone using just ‘server1’ with no domain to connect EG: ‘fred@server1’
server1.internalnet.local – matches on anyone using the fully qualified internal domain name EG: ‘email@example.com’ (NOTE: you will need an internal DNS to make this work correctly)
188.8.131.52 – matches on the specific I.P. address assigned to the SSH server EG: ‘firstname.lastname@example.org’ this can use wild cards, or even better net/mask cidr format EG: 1.2.* or 192.168.1.0/8 if you do use wild cards however, please read fchurca’s answer below for some important notes.
If any of the patterns provided match the host being accessed, then the one and only single change to be made to the running config is to turn back on the ability to have an interactive password login.
You can also put other config directives in here too, and those directives will also be turned back on for internal hosts listed in the match list.
do however read this:
carefully, as not every configuration option is allowed to be used inside a match block, I found this out when I tried to “UsePAM yes” to turn PAM authentication back on, only to be told squarely that wasn’t allowed.
Once you’ve made your changes, type
followed by return to test them before attempting to restart the server, it’ll report any errors you have.
In addition to everything above, I got a lot of help from the following two links too:
1.2.* – matches on anyone in the local net using any address assigned to the SSH server that’s in the 16 bit net mask for the server EG: ‘email@example.com’
Careful! Pattern matching in .ssh/config is based on string globbing, not necessarily ip addresses. According to the same manpage you are reading:
A pattern consists of zero or more non-whitespace characters, ‘*’ (a wildcard that matches zero or more characters), or ‘?’ (a wildcard that matches exactly one character). For example, to specify a set of declarations for any host in the “.co.uk” set of domains, the following pattern could be used:
The following pattern would match any host in the 192.168.0.[0-9] network range:
If somebody tries to login from an IP that publicly reverse-resolves to
1.2.badguy.com , it will match your
[Updated for completeness]
As noted elsewhere, you can use
Match Address 184.108.40.206/16 instead of
Match Host 1.2.*
I think what you should be looking into is splitting out your ssh configs. For example; setup your /etc/ssh/ssh_config to have the global variables you need for all users by default (ssh key auth, port forwarding, etc…).
Then if your user (let’s call him Bob) has a local (or nfs mounted) home directory, put a config just for him in /home/bob/.ssh/. This config will contain your match statement as well as if you need him to connect with a password rather then a cert as well as his own keep alive values, etc…
I have done this in the past and presently to lock down certain local accounts to come in from only one IP address and only allow cert based authentication while other user accounts may instead be using PAM authentication and have password based authentication.
In short, building and maintaining separate user config files based on user need is easier to manage than trying to keep it all under the default config file for ssh.