Gerowen

The hard part is finding an acceptable balance between good OPSEC but not pre-emptive compliance.

All the more reason to give him hell for doing a terrible job. If you can’t handle the heat get out of the kitchen.

Generate a unique key for each client or device. SSH keys identify devices, not people, so I do not recommend sharing the same key between two different devices.

I generally do a few things to protect SSH:

1. Disable password login and use keys only
2. Install and configure Fail2Ban
3. Disable root login via ssh altogether. Just change “permit root login” from “no password” to just “no”. You can still become root via sudo or su after you’re connected, but that would trigger an additional password request. I always connect as a normal user and then use sudo if/when I need it. I don’t include NOPASSWD in my sudoers to make certain sudo prompts for a password. Doesn’t do any good to force normal user login if sudo doesn’t require a password.
4. If connecting via the same network or IPs, restrict the SSH open port to only the IPs you trust.
5. I don’t have SSH internet visible. I have my own Wireguard server running on a separate raspberry pi and use that to access SSH when I’m away, but SSH itself is not open to the internet or forwarded in the router.

So far I haven’t seen any attempts to change their user agents. I’ve seen one or two other bots poking around, but nothing to write home about so I’ve left them alone.

I have heard however that changing user agents is a tactic they do indeed employ, especially Claude, so it may be that I’ll eventually have to adapt my defenses.

I’ve been fending off AI bots the last week or so; wrote about it here:

https://gerowen.substack.com/p/the-ai-data-scraping-is-getting-out