On 2014-11-18 16:09, Libertas wrote: [..]
https://github.com/plsql/ssh-auth-methods
The purpose of this is to alert relay operators that are still allowing password authentication. 2,051 relays offered password auth, and many more likely offer similarly insecure methods or were missed for reasons discussed below.
Excellent run! And thanks for bringing this up on this list.
Now to hope that folks actually fix their setups though.
[..]
- SSH being served on a non-standard port - something other than port
- This is a good idea, as many brute-force attackers will only
bother trying port 22. The script I wrote could have used an alternate port number supplied from nmap, but this would run much slower and would potentially get my VPS blocked before it could even get the SSH information.
Try 2022, it is a general alternative.
People should realize though that it is not 'safer' in any way running SSH on another port. SSH readily shows itself as being SSH and nmap and other tools easily recognize it on other ports.
- The server only allowing SSH connections from certain IP addresses.
This is also commonly recommended, although it can be a little rigid if you don't have a VPN with a static IP (what if your server goes down while you're away from home?).
Actually it is not 'a little rigid' it is the best thing to do: Only allow certain prefixes access
If you do not have a static IP address, at minimum limit access to the prefix of your ISP (whois your own IP address and check the 'route' object); though be warned you might change outside that block too.
Possibly better, set up IPv6 at home and on the server by getting a free IPv6 tunnel (effectively just also a VPN) from many places around the world (see Wikipedia IPv6 Tunnel Broker List).
Then just allow access over the static IPv6 address you have.
As there are no SSH scanners on IPv6 you could even opt to not having a filter if you don't publish the address of the endpoint anywhere.
Greets, Jeroen