SSH Port Change

somik

Hello.

So the basic of basic you can do to protect your server is to change the SSH port. I think we can all (well, at least most) agree that this is a basic step to setting up any server following OS installation.

1. However, change port to what?
2. How many digits?
3. Should repeating numbers be avoided?
4. Should it be different for all of your servers?

5. How do you keep track of the ports?

6. Finally, firewal or no firewall?

Firewall blocks ports not in use so maybe it can be easy for hackers to run a port scanner to find which ports are open. What if all open ports not in use are forwarded to a catch all service that does nothing? Will that improve security?

Do let me know what you think.

seriesn

@somik said: However, change port to what?

How many digits?
Should repeating numbers be avoided?
Should it be different for all of your servers?
How do you keep track of the ports?

Finally, firewal or no firewall?

Or simply limit connection by specific IP (host.allow/host.deny) and enjoy your life like no tomorrow.

somik

@seriesn said:

@somik said: However, change port to what?

How many digits?
Should repeating numbers be avoided?
Should it be different for all of your servers?
How do you keep track of the ports?

Finally, firewal or no firewall?

Or simply limit connection by specific IP (host.allow/host.deny) and enjoy your life like no tomorrow.

Except that my IP keeps changing (dynamic IP) so thats not a option unless I setup a VPN server specificly for this. But if the VPN server dies, all my servers die with it. So ya...

seriesn

@somik said:

@seriesn said:

@somik said: However, change port to what?

How many digits?
Should repeating numbers be avoided?
Should it be different for all of your servers?
How do you keep track of the ports?

Finally, firewal or no firewall?

Or simply limit connection by specific IP (host.allow/host.deny) and enjoy your life like no tomorrow.

Except that my IP keeps changing (dynamic IP) so thats not a option unless I setup a VPN server specificly for this. But if the VPN server dies, all my servers die with it. So ya...

Multiple VPN? a cheap SSH jumpbox for backup purpose, like one of those $12-15/year services. Because even if you change your port, it isn't too hard to scan ports.

Also something like fail2ban should helps.

donko

-4 digit
-same port for all server
-not blocked by firewalls (my ip is dynamic too)
-and no password login only key (root login disabled too)

nullnothere

@somik said: Except that my IP keeps changing (dynamic IP)

Why not wireguard? So the server's public IP is firewalled for SSH but accessible via the WG interface so all private and protected. Plus you can have a mesh of all your servers in the same address space reachable via multiple paths if required.

Second option is to use something like https://github.com/mrash/fwknop - opens up the SSH port only when you (cryptographically) knock. Very useful but requires server + client side setup (very straightforward but still...)

Irrespective of the reachability of your SSH server it is important to ensure you have only (public) key based logins (along with a few tweaks to the MaxAuthTries settings to throttle things just in case).

SGraf

@somik said:
1. However, change port to what?

Technically it shouldnt matter much, what port number you choose. That being said, i would suggest not using one of the more commonly used ports. ( https://en.wikipedia.org/wiki/List_of_TCP_and_UDP_port_numbers )

2. How many digits?

I usually go with 4 or 5. But that is just personal preference. you might want to read the bit about privileged port numbers and consider that.... (https://www.w3.org/Daemon/User/Installation/PrivilegedPorts.html )

3. Should repeating numbers be avoided?

This has no effect on anything as modern port scanners are relativly fast. The only thing that changing the port number accomplishes, is that automated scanners going for the same port across all of the "internet" are not picking up on it. With single target/specialized attack attempts this does not really improve security.

4. Should it be different for all of your servers?

As with #3 it doesnt matter that much. It just discourages automated attacks that just go for a single port (or potentially a couple fixed ones on each system).
If you want to more...You could set up a dedicatred management network, where all your ssh/.... instance are reachable and use a jumphost (w. vpn,..) to connect to it. Alternativly you could look into a combination of port knocking ( https://en.wikipedia.org/wiki/Port_knocking ) and automated blacklisting if too many connection attempts are made on ports of the system that are not in use.

5. How do you keep track of the ports?

% cat .ssh/config 
Host givetheserversomename
    HostName insert-ip-or-dns-name-here
    Port 1337
    User yoursshuser

% ssh  givetheserversomename
Enter passphrase for key '/home/......

6. Finally, firewal or no firewall?

generally yes. as you can surpress unwanted outbound connections......
(But please forget the whole "it can be discovered myth", as it can and will be discovered if someone wants to....)

Do let me know what you think.

....Best thing is: 
* change to a nonstandard port (just to keep the logfiles tidy). 
*disable password based login
=> use ssh-key authentication...

https://www.digitalocean.com/community/tutorials/how-to-configure-ssh-key-based-authentication-on-a-linux-server

somik

@nullnothere said:

@somik said: Except that my IP keeps changing (dynamic IP)

Why not wireguard? So the server's public IP is firewalled for SSH but accessible via the WG interface so all private and protected. Plus you can have a mesh of all your servers in the same address space reachable via multiple paths if required.

Second option is to use something like https://github.com/mrash/fwknop - opens up the SSH port only when you (cryptographically) knock. Very useful but requires server + client side setup (very straightforward but still...)

Irrespective of the reachability of your SSH server it is important to ensure you have only (public) key based logins (along with a few tweaks to the MaxAuthTries settings to throttle things just in case).

I'll look into wireguard, but it looks complicated to setup.

Fwknop, never heard of it. I'll see how far i can go with it.

@SGraf said:

@somik said:
1. However, change port to what?

Technically it shouldnt matter much, what port number you choose. That being said, i would suggest not using one of the more commonly used ports. ( https://en.wikipedia.org/wiki/List_of_TCP_and_UDP_port_numbers )

2. How many digits?

I usually go with 4 or 5. But that is just personal preference. you might want to read the bit about privileged port numbers and consider that.... (https://www.w3.org/Daemon/User/Installation/PrivilegedPorts.html )

3. Should repeating numbers be avoided?

This has no effect on anything as modern port scanners are relativly fast. The only thing that changing the port number accomplishes, is that automated scanners going for the same port across all of the "internet" are not picking up on it. With single target/specialized attack attempts this does not really improve security.

4. Should it be different for all of your servers?

As with #3 it doesnt matter that much. It just discourages "drive by" attacks.
If you want to more...You could set up a dedicatred management network, where all your ssh/.... instance are reachable and use a jumphost (w. vpn,..) to connect to it. Alternativly you could look into a combination of port knocking ( https://en.wikipedia.org/wiki/Port_knocking ) and automated blacklisting if too many connection attempts are made on ports of the system that are not in use.

5. How do you keep track of the ports?

> % cat .ssh/config 
> Host givetheserversomename
>     HostName insert-ip-or-dns-name-here
>     Port 1337
>     User yoursshuser
> 

> % ssh  givetheserversomename
> Enter passphrase for key '/home/......
> 

6. Finally, firewal or no firewall?

generally yes. as you can surpress unwanted outbound connections......
(But please forget the whole "it can be disvoered myth", as it can and will be discovered if someone wants to....)

Do let me know what you think.

> ....Best thing is: hcange to a nonstandard port 
> (just to keep the logfiles tidy). disable password based login and use ssh-key authentication...
> 
> https://www.digitalocean.com/community/tutorials/how-to-configure-ssh-key-based-authentication-on-a-linux-server
> 
> 

Thanks. Your reply is much simpler to follow.

InceptionHosting

I guess the main thing to consider is that the vast majority of attempted brute force attacks come in following a port scan, so any none common port is fine that said I would avoid 2222 as that is also commonly scanned.

people looking to brute force ssh are usually working on bulk so just not using port 22 in the majority of cases will remove 99% of all the shitty traffic.

none standard port and use key based auth.

PHP_Backend

+1 everything @SGraf said.

life

why not explore https://gravitational.com/teleport .
https://gravitational.com/teleport/docs/quickstart/

foxone

• Five digits (though anything that's not in the 1000 common ports is okay and will probably not get scanned)
• disable password auth
• disable root login
• set ip whitelist to the subnets of your own provider (or perhaps use geoloc to allow only access from your own country)

vimalware

@somik said:

So the basic of basic you can do to protect your server is to change the SSH port.

Let me stop you right there and ask :
Have you disabled password authentication after adding your public key to authorized_keys file?

Second layer might be a fail2ban rule that bans IP for 2-5 days if more than 5 attempts in 30mins.

Another thing I've decided is useful , is adding a DROP rule for CN, BR and RU ipset in iptables. (maybe just port 22? )

InceptionHosting

@foxone said: r (or perhaps use geoloc to allow only access from your own country)

that's actually a really good idea.

poisson

Has anyone tried 2FA with SSH? Looks like you can 2FA any damn thing these days.

bugrakoc

@poisson said:
Has anyone tried 2FA with SSH? Looks like you can 2FA any damn thing these days.

That's actually a great idea.

SGraf

@bugrakoc said:

@poisson said:
Has anyone tried 2FA with SSH? Looks like you can 2FA any damn thing these days.

That's actually a great idea.

from personal experience it sounds great, until it stops working....

cochon

@SGraf said:

@bugrakoc said:

@poisson said:
Has anyone tried 2FA with SSH? Looks like you can 2FA any damn thing these days.

That's actually a great idea.

from personal experience it sounds great, until it stops working....

Sadly I also don't think there's a way to combine 2FA with public-key logins.

Authentication seems either, password only mediated by SSH handled by PAM, public key mediated by SSH handled by SSH, or password/2FA/others combined mediated and handled by PAM.

Public key still seems the better option, and more flexible for locking down with 'from=' and 'command='.

If anyone does know a way to combine keys with 2FA I'd be fascinated to know.

foxone

@SGraf said:

@bugrakoc said:

@poisson said:
Has anyone tried 2FA with SSH? Looks like you can 2FA any damn thing these days.

That's actually a great idea.

from personal experience it sounds great, until it stops working....

Why should it stop working?

seanho

2FA via PAM should work just fine in combination with pubkey auth for ssh

somik

@AnthonySmith said:
I guess the main thing to consider is that the vast majority of attempted brute force attacks come in following a port scan, so any none common port is fine that said I would avoid 2222 as that is also commonly scanned.

people looking to brute force ssh are usually working on bulk so just not using port 22 in the majority of cases will remove 99% of all the shitty traffic.

none standard port and use key based auth.

I agree with you there. If there is a targetted attack on my server, there is very little I can do, given my knowledge, except just turn it off for a few days and hope they go away. That being said, I doubt I'll be targetted for hacks given that I do not provide any services from my websites. I'm mostly worried of the generalized attacks.

@foxone said:

• Five digits (though anything that's not in the 1000 common ports is okay and will probably not get scanned)
• disable password auth
• disable root login
• set ip whitelist to the subnets of your own provider (or perhaps use geoloc to allow only access from your own country)

Not sure how to do the IP whitelist for SSH, but sounds like a good idea. Anyone has any "for dummies" tutorials on it?

@vimalware said:

@somik said:

So the basic of basic you can do to protect your server is to change the SSH port.

Let me stop you right there and ask :
Have you disabled password authentication after adding your public key to authorized_keys file?

Second layer might be a fail2ban rule that bans IP for 2-5 days if more than 5 attempts in 30mins.

Another thing I've decided is useful , is adding a DROP rule for CN, BR and RU ipset in iptables. (maybe just port 22? )

I had setup the fail2ban rule previously. It came with Virtualmin that time. Now I am not using any panels so I'll see how to get it working without it coming preinstalled.

@poisson said:
Has anyone tried 2FA with SSH? Looks like you can 2FA any damn thing these days.

Looked at it. Tried the google authy thing. Gave up on it. Instructions unlcear, penis stuck in SSH.

@cochon said:

@SGraf said:

@bugrakoc said:

@poisson said:
Has anyone tried 2FA with SSH? Looks like you can 2FA any damn thing these days.

That's actually a great idea.

from personal experience it sounds great, until it stops working....

Sadly I also don't think there's a way to combine 2FA with public-key logins.

Authentication seems either, password only mediated by SSH handled by PAM, public key mediated by SSH handled by SSH, or password/2FA/others combined mediated and handled by PAM.

Public key still seems the better option, and more flexible for locking down with 'from=' and 'command='.

If anyone does know a way to combine keys with 2FA I'd be fascinated to know.

That would be the best solution, but 2FA and password authentication is still good enough.

@foxone said:

@SGraf said:

@bugrakoc said:

@poisson said:
Has anyone tried 2FA with SSH? Looks like you can 2FA any damn thing these days.

That's actually a great idea.

from personal experience it sounds great, until it stops working....

Why should it stop working?

That happens when you dont sync your server time with NTP and your server time goes out of sync. 2FAs are based on time, so even 30s time out of sync is enough to completely break it.

@seanho said:
2FA via PAM should work just fine in combination with pubkey auth for ssh

All the tutorials I saw only talked about password auth though.

somik

@somik said:
Looked at it. Tried the google authy thing. Gave up on it. Instructions unlcear, penis stuck in SSH.

Scratch that, this tutorial worked fine: https://ubuntu.com/tutorials/configure-ssh-2fa

Turns out, my ssh client was the issue on the windows machine. Putty is the way to go. On linux/mac, terminal (or terminal emulator) works fine with TOTP.

Although I do wish there was a non-google way to go about it...

lleddewk

Although I do wish there was a non-google way to go about it...

A non-Google authenticator app? There are several here. FDROID

Edit: Oh I think you meant the PAM bit.

rcy026

@somik said:

@somik said:
Looked at it. Tried the google authy thing. Gave up on it. Instructions unlcear, penis stuck in SSH.

Scratch that, this tutorial worked fine: https://ubuntu.com/tutorials/configure-ssh-2fa

Turns out, my ssh client was the issue on the windows machine. Putty is the way to go. On linux/mac, terminal (or terminal emulator) works fine with TOTP.

Although I do wish there was a non-google way to go about it...

Use libpam-oath and Authy if that makes you feel better.

Or whatever other app you feel comfortable with.
https://www.g2.com/categories/multi-factor-authentication-mfa

skorous

@cochon said: Sadly I also don't think there's a way to combine 2FA with public-key logins.

I've always considered public key logins to be 2FA - something you have ( the key file ) and something you know ( the password to the key file ). It's not OTP but it is 2FA.

somik

@lleddewk said:

Although I do wish there was a non-google way to go about it...

A non-Google authenticator app? There are several here. FDROID

Edit: Oh I think you meant the PAM bit.

Ya, cause I'm using TOTP Authenticator app for android on my phone... My chinese phone that runs google's android... Nevermind. I guess google's authy will do fine.

@rcy026 said:

@somik said:

@somik said:
Looked at it. Tried the google authy thing. Gave up on it. Instructions unlcear, penis stuck in SSH.

Scratch that, this tutorial worked fine: https://ubuntu.com/tutorials/configure-ssh-2fa

Turns out, my ssh client was the issue on the windows machine. Putty is the way to go. On linux/mac, terminal (or terminal emulator) works fine with TOTP.

Although I do wish there was a non-google way to go about it...

Use libpam-oath and Authy if that makes you feel better.

Or whatever other app you feel comfortable with.
https://www.g2.com/categories/multi-factor-authentication-mfa

Looks like google was the easiest to setup. Now I just have to ensure my server time sync doesn't break as I only have a few offline keys to login without the TOTP...