Just some thoughts on Andy's suggestions:
1. Remove direct SSH capability, replace with web
All current Xen Shell features to be put on a web interface.
Console to be used from a web interface.
I don't relish this, but I have seen some pretty nifty web
terminals so maybe it wouldn't be that bad.
That sounds like a possible solution, although I'd be intrigued to know how SSH keys work in that case (ideally I'd still like my log in process to the Xen shell to use a key, not a password)
2. Firewall off SSH from the Internet, poke holes temporarily
[...]
Option (2) is lots easier to implement so could happen fairly
quickly, but it is more fiddly to use: You're in an arbitrary place
and you suddenly need to connect to your Xen Shell; you've then got
to log in to Panel, work out your IP address¹, add it to the allow
list, then hit the button. Finally you can SSH.
I agree that this would be fiddly - especially if you're away and don't know your current IP. Additionally there might be a static IP you'd want to allowlist constantly, and having to come in every time to allow it would be a pain (or in my case, I have a DDNS entry that points to my home IP if it changes - ideally I'd like to allowlist that so it updates)
Option (3) might be to use a VPN of some kind? I use Wireguard at home to access my internal network - would something like that be preferable? I say Wireguard because I think it's fairly(!) easy to manage once it's running and doesn't require a huge amount of config on either side. Other VPN solutions do exist, of course.
I guess something interesting could be done for those not on legacy
Internet: assign unique IPv6 console address that can only be used
for connecting to that VM's Xen Shell. 😀
While that does sound fancy, I think that might cause more problems for those of us still on the legacy Internet... or if you need emergency access when travelling for example!
Cheers,
James