Protecting SSH
-
I don't know if this is the appropriate forum as my question may span a couple of different areas.
I would like to be able to SSH into an Ubuntu 20.04 server I have hosted at home behind my pfSense firewall.
I currently have a port opened forwarded to this server. I know this is wrong. This is why I am posting. I want to make this better and I have seen my auth.log.1 getting filled up with login failures. I know it is only a matter of time...
The traditional response would be to not open the port and instead use VPN to connect to home and then SSH into the machine. However, this has a couple of issues.
- I probably need to change my home network IP range from 192.168.1.x to something else as this seems to conflict with some client networks. This is a separate problem, and I need to bite the bullet and make this change.
- I am often connected to my work VPN and I can't connect to my home VPN. They do not allow split tunneling.
So, if I can't use VPN, what other options do I have? Could I setup mTLS for that port in pfSense?
-
Still may not be the best way, but I use a port like 55521 on the outside and I have the NAT translate that to 21 on the inside. I also use keys to make it harder.
-
Yeah use a different port.
Set a source range on the allow rule. If you are VPNing to a work location they probably have a fixed IP so you can limit it to that.
When you are not VPN'd there you can VPN to home.Use a dyndns client on the machine you're connecting from is an option if the address you're coming from does not change often.
Use key based SSH login.
Steve
-
@AndyRH and @stephenw10, thank you for the response.
I am using a port other than 22 on the WAN.
I will check, but I think my companies VPN uses a couple different IP addresses.
Can you elaborate on setting up keys? I have SSH public key authentication setup, but it is more for auto-login. Are you talking about something else?
-
That is what I'm talking about. Key based login is far more secure.
Even if your company has 100 IPs you can add them to an alias and limit the source in the rule to that.
And/or to a dyndns address.Steve
-
@stephenw10 can I configure SSH to use keys from external requests, but allow username/password internally?
Most of the time I will be logging in using an RSA key, but I am just worried if I disable username & password auth that I will get locked out should something happen to my key.
-
Yes, it can be both. Not as secure as key only. You can't set it differently for different interfaces.
-
One option is to use a stored public/private key, instead of password. This will allow you to connect automagically, without a password, while blocking anyone who doesn't have the correct key. In fact, you should always use this method, if you can.
-
@jknott Is it advisable to disable username & password authentication?
-
@ryanm If you're using public/private keys, you don't have to use a password. However, when you generate the key pair, you can choose how long to make it. You can make a long one.
-
For anyone finding this later, I found this page helpful: https://askubuntu.com/questions/435615/disable-password-authentication-in-ssh
-
In pfSense there's a gui setting for that in Sys > Adv > Admin:
-
Public key is the most secure.. I personally would set it to that, why would there be a problem with your keys..?
If you do say loose your key, you should prob reset the public key pair anyway. You can always get in from the local side via the gui and fix the issue.
To be honest not sure why too many people would be sshing to your firewall? That really should only be admin access. And then only in rare instances..
Unless you were using it as a fall back vpn, or "poor mans" vpn ;) One advantage of ssh tunnels are that you can almost always run say putty on some box without admin right. While installing an actual vpn client needs admin.. So yeah it does have it uses.
But if your going to expose your ssh to public, even if changing the ports. You should really lock it down to public key only. If you can lock it down to source IPs that are none, then ok should be fine to leave it as both.
-
@stephenw10 said in Protecting SSH:
In pfSense there's a gui setting for that in Sys > Adv > Admin:
Isn't this for opening SSH to your pfSense? I was asking more specifically about doing this on an Ubuntu server behind my pfSense firewall.
-
@johnpoz said in Protecting SSH:
Public key is the most secure.. I personally would set it to that, why would there be a problem with your keys..?
If you do say loose your key, you should prob reset the public key pair anyway. You can always get in from the local side via the gui and fix the issue.
To be honest not sure why too many people would be sshing to your firewall? That really should only be admin access. And then only in rare instances..
Unless you were using it as a fall back vpn, or "poor mans" vpn ;) One advantage of ssh tunnels are that you can almost always run say putty on some box without admin right. While installing an actual vpn client needs admin.. So yeah it does have it uses.
But if your going to expose your ssh to public, even if changing the ports. You should really lock it down to public key only. If you can lock it down to source IPs that are none, then ok should be fine to leave it as both.
Good points johnpoz. I was mostly thinking about if I lost my key. But like you said, I could always use the physical console. I suppose I would need my keys if using someone else's computer, but I don't see myself doing that.
So, to clarify, I wasn't asking about SSH into my pfSense firewall. I think I do have that allowed from LAN, but not WAN. I was asking about SSH into an Ubuntu server on LAN.
I did forward using a non-standard port and I added an Alias with company IP ranges and updated the NAT to use that in pfSense.
I also updated the sshd_config using recommendations from the askubunutu.com page above to lock down my SSH to not allow root login or password auth.
I think I am in a much better spot than I was. Watching the auth.log seems to no longer have the "Invalid user" requests every few seconds (thank you IP filtering).
-
That setting is only for ssh "TO" pfsense, not anything behind it.
If you want to allow access to some device running sshd behind pfsense (on your lan or vlan) then that would be a port forward..
That setting and port is only for ssh to pfsense. I don't have that open to the public internet, so I just leave it at 22..
If its only you that will be sshing to this server, why not just vpn into pfsense and ssh to it that way - that way you don't have to expose ssh to the internet at all.. And just vpn into pfsense which is secure. This also has the added bonus of allowing you to access anything on your local network if you so desire - rdp to your PC, access your plex server, your file server, etc. etc. And vpn can be very secure.. Shoot if the client doesn't have the right tls key they don't get anywhere at all. not even prompted for their cert for auth, etc.
And wireguard is coming with 2.5 of pfsense - so if your of fan of that, that is right around the corner. And if you ok with running beta, 2.5 snapshots are out now.
-
@johnpoz said in Protecting SSH:
That setting is only for ssh "TO" pfsense, not anything behind it.
If you want to allow access to some device running sshd behind pfsense (on your lan or vlan) then that would be a port forward..
That setting and port is only for ssh to pfsense. I don't have that open to the public internet, so I just leave it at 22..
If its only you that will be sshing to this server, why not just vpn into pfsense and ssh to it that way - that way you don't have to expose ssh to the internet at all.. And just vpn into pfsense which is secure. This also has the added bonus of allowing you to access anything on your local network if you so desire - rdp to your PC, access your plex server, your file server, etc. etc. And vpn can be very secure.. Shoot if the client doesn't have the right tls key they don't get anywhere at all. not even prompted for their cert for auth, etc.
And wireguard is coming with 2.5 of pfsense - so if your of fan of that, that is right around the corner. And if you ok with running beta, 2.5 snapshots are out now.
I hear you on VPN, and I do have that setup and would use it under most circumstances.
However, the issue is if I am already on VPN to my company, I can't open a 2nd VPN and they do not allow split tunneling.
I am interested in Wireguard. My understanding is that it will be less CPU intensive than OpenVPN. Is that true, or at least true under most circumstances? I will probably wait until 2.5 is out. While I am not running anything mission-critical, I don't want the hassle right now if there is a problem.
-
How are you connected to your work vpn? On your device? What does that have to do with running a vpn server on your router?
So your running a ssh tunnel through your work vpn, to be able to get back to your home network?
