I’m curious why people say not to have ssh exposed if you only have key auth enabled. It seems to me that every single other password + some other number of protections is inherently weaker than simple old public key auth.

If you do expose your SSH port, one option is to setup a firewall rule to allow your own public IP for connections to the SSH port and drop all the rest.

If you're using Digital Ocean, you can set a firewall rule via the droplet web interface, that's quick to do. Otherwise just a simple iptables does the trick.

Edit: if you have a static public IP, of course

As long as you have a static IP that could never change, otherwise you'll deny yourself access after, for example a power outage where your router gets a new IP (or a random period of time where your ISP decides to change your IP, or you move, or you want to connect from another server).

Using an alternative connection to activate the protocol is probably the only reasonable defense:

* An https service that can enable a port for connections from an IP for a limited time (which has some security implications too since it would need root access, or to trigger something with root access)

* Something built into KLO hardware, or software provided by your provider (including something simple like turn on the firewall a few minutes after boot, and using the reboot trigger and connecting in that brief window.. as long as you don't mind your server down - probably ok as an emergency recovery strategy)

* Some form of port knocking

> * Some form of port knocking

Variable port knocking ie a different sequence tied to rules can help expose compromised networks making up the internet. Say you port knock from your mobile phone, use one port knocking sequence, if port knocking from a different internet connection use a different port knocking sequence. This can help highlight those networks with taps, but the identity of who is behind the tap can still remain a mystery, unless you set other traps. You also need to trust your devices, which no one can legally do as copyright prevents people from examining the code on their chips and some OS'es like Windows. NSA still provide the tools for examining code for free https://www.nsa.gov/resources/everyone/ghidra/ but as always Resource Burning is something to take seriously when trying to secure your systems. Sometimes its best to view servers as disposable, so automation can be your friend even simple PXE boots can be useful. Its also worth noting you can run at least two different ADSL connections down the same copper wire, they do here in the UK at least, most people dont know this, but the TV & film streaming services use this, some ISP supplied routers can give this away if you examine the backup config files.

I’m not sure I trust myself to set up my own bastion securely. Are there any companies that offer secure bastions as a service?

What I’m envisaging is: I pay somebody, make an account on their site and add 2FA, and then they give me a server with a static IP and handle the auth. Then all I have to do is to whitelist that static IP.

Ideally it would function as both an HTTP proxy and an SSH proxy; like a ‘secure web portal’

Look into Gravitational Teleport.

They have a cloud offering in beta where they'll manage the proxy/bastion.

How much would you pay for that?

$30/month

About $3.50

Provided you are not behind CGNAT then dynamic DNS is your way forwards here. My parents have a RPi for a phone exchange (RasPBX) and a pair of Yealink DECT handsets and BT Home for an ISP. A static IP is impossible.

I tie the Pi to my home router via OpenVPN and use https://freedns.afraid.org/ for dynamic DNS to send calls to. It has worked fine for four years now. The Pi runs a one liner from a cronjob every 15 mins or so. The TTL for the DNS entry is very short and the DHCP lease is something like 24 hours plus also I think it tends to renew the last one used reasonably reliably. I don't bother monitoring that. I could write the cronjob result to a local log I suppose.

More things can go wrong than the tiny window that might exist when the DNS might be out of whack. Don't let the lack of a static IP address get in the way.

Could you comment on my way of accessing my servers on AWS: My server are on VPC and no public ssh is allowed (nothing is open besides 443). When I want to login to my server , I run a script to modify security. (I have disabled ssh password logins and ssh is running on non standard port). And when I am done with task, I plug the hole in security group with another batch code. I am worried that I may be not exposing my servers with my practices.

No op, but your practice is probably fine. More ideally, SSH would be locked down to your public IP address only. If you're already scripting this, you could just do a curl request to one of the many "what is my ip" services and set that instead of 0.0.0.0/0 as the security group IP address.

We also use bastion hosts. They're whitelisted for key-based SSH only access for our public IP addresses. We can jump around to other servers once we login to that one, but our externally facing servers never advertise anything other their base service (:443 or whatever is running on them).

I also use them with my personal servers and just leave them shut off when I'm not actively using them. This keeps costs down, but more importantly it permanently blocks off SSH access unless I'm specifically in need of it.

Did you try port knocking https://wiki.archlinux.org/index.php/Port_knocking

Using ssh in an obscure port helps a little bit.

PAM modules also help.

This particular malware doesn't seem to grok when you're using certs or keys, so while it'll never be successful it keeps trying (effectively a resource DOS).

Obscure port does nothing.. it eventually finds it and then you'll see tons of servers try that port (unless you constantly move it).

I'm not sure how you imagine Pluggable Authentication Modules would help? Fail2Ban or some sort of active IPS helps, but because the IPs are very varied (and presumably ever increasing) and infrequently re-attempt it doesn't help much.

Note anyone running exposed SSH without keys or certs, should run the detection script[0] (which is just shell and you should read first before installing) provided by Guardicore

[0]: https://github.com/guardicore/labs_campaigns/tree/master/Fri...

For my hobby servers, I listen on a non standard port. Not once in 20+ years has anything hit that port. Even when I've had domains / sites that ruffled feathers, no hits. It most certainly cuts out noise in logs and stops all the bots.

A few months ago I started noticing failed login attempts on my non standard SSH port (> port 1024) so I moved it up a few port numbers. About 2-3 weeks ago, I noticed that it was getting hit again by failed login attempts. I then changed the port to the original and immediately started getting login attempts again... it kind of spooked me.

I thought about using fail2ban but every login is a different IP (using my eyeballs, I didn't parse the logs).

You can still use fail2ban to block unique IP addresses if you use some supporting scripting. There's an example ([1]), which will check the IP addresses by country code. If they're all the same country then you can just block the whole country.

You do not need to use firewalld, either, although this does. See the second link for something generic ([2]).

[1] https://pagure.io/firewalld-blacklist/tree/master

[2] https://www.linuxjournal.com/content/advanced-firewall-confi...

I take a different approach than fail2ban. My sftp servers use a standard port 22 and any time people try to log in, I create an account for them automatically via a cron job in the sftp-only group and a null password. The bots will spend years trying to log in repeatedly every few minutes. I have yet to see them upload anything interesting. Many years ago, bots would upload malware, then try to browse to it on port 80. But no more... These bots just want to get a shell and install malware / c&c tools. Some of them try port forwarding, but I have that restricted for the sftp users.

I've also used a port other than 22 for sshd. And I can confirm that the past month I've been getting hit with lots of failed login attempts on ssh. My basic look at the logs shows it trying random dictionary words for usernames. And every connection attempt comes from a different IP.

Yes, I'm seeing the same to my non-standard port and the connection attempts are from a large number of different addresses (and only usually 1 or 2 attempts from each) that Fail2Ban does not trigger.