Answer No not trivially insecure, but still not ideal.
I manage multiple AWS instances, and while most of them have Security Groups limiting SSH inbound access, there is a business need for one of them to listen on port 22 for all connections.
As such this host gets hit by thousands of script-kid (skiddy) connections every day. This is indicated at login by MOTD messages like
Last login: Fri Jun 19 23:17:36 UTC 2020 on pts/2
Last failed login: Sat Jun 27 01:00:44 UTC 2020 from 188.8.131.52 on ssh:notty
There were 21655 failed login attempts since the last successful login.
host1234 ~ # date
Sat Jun 27 01:12:18 UTC 2020
So that's roughly 2,500 a day or a hundred an hour. Certainly most of them will simply be automated probes, but what happens if a zero-day vulnerability is found and exploited?
By limiting your exposure you reduce the risk.
Solutions include one/some/all:
- Use AWS security groups to only permit connections from specific IPs on the internet
- Use a VPN solution and require that SSH be done over the VPN. The VPN can listen to all sources, have certs and 2FA, and generally add more layers. OpenVPN works well, or there are multiple AWS offerings to do the same task.
- Move SSH to another port - its not any added security, but this does cut down on the number of ssh connection attempts and therefore the noise. Anyone worth their salt will scan all ports anyway, not just the default.
- If you HAVE to listen for SSH promiscuously, explore a solution like fail2ban which adds sources to
/etc/hosts.deny if they fail more than X times in Y minutes, and can remove them again after a day or so.
- Explore IPv6 - like changing the listening port, IPv6 increases the time taken to scan, so skiddies have more space to search. v6 scanning still happens though.
For me, the devices sshing-in are hardware, so they have a valid user certificate and they always auth successfully. We wrote a script that scans
/var/log/secure and looks for "user not found" or similar, and immediately adds those sources to the hosts.deny file permanently.
We've considered extending this to block whole subnets based on lookups, but that hasn't been needed yet.
We currently block:
host1235 ~ # grep -ci all /etc/hosts.*
I'm not going to share a list of bad source IPs, because some locations consider IP addresses to be Personally Identifiable Information (or PII)
Note that our Office IPs are in
hosts.allow which trump the
hosts.deny file, so if someone fails a login from an office, then it won't lock out human users.
Do ask for clarifications - I know I've handwaved a lot of details.