[bitfolk] Re: Thoughts on tightening up Xen Shell's SSH (not yours - that's your business!)

On 14 Apr 2024, at 01:34, Andy Smith via BitFolk Users &lt;users(a)mailman.bitfolk.com&gt; wrote: Hi, In light of the recent XZ/lzma backdoor we should perhaps think harder about how complex sshd is and the wisdom of exposing that to the entire Internet. At BitFolk, this currently needs to be exposed to the Internet so that you can connect to your Xen Shell (console). More info on the Xen Shell for those new to it: https://tools.bitfolk.com/wiki/Xen_Shell When thinking about ways to tighten this up, they are all going to involve taking away your ability to just SSH to you(a)you.console.bitfolk.com. There's a couple of ways this could go: 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. 2. Firewall off SSH from the Internet, poke holes temporarily You'd have to supply to the Panel some list of net blocks that you will SSH from and then there'd be a button to punch holes in the firewall for SSH from those net blocks for 6 hours (for example). There would have to be a limit on the size of the net blocks. Let's say a /16 for IPv4 and a /32 for IPv6. 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. Option (1) will require a lot of work but maybe it's less friction to use a web-based terminal if you have to visit a web site anyway? Option (2) does not preclude option (1). Providing a web-based terminal that doesn't need the "allow SSH" button to be pressed can be implemented after option (2) is done, as a sort of stretch goal. Or maybe the web terminal is such an attractive and required feature that it should be done first, before option (2) would be enacted? I am disregarding the idea of flipping the default to having password auth disabled. It is currently by default enabled but you can disable it on a per-VM basis. I do recommend that you do that, but what I am really more concerned about is an(other) exploit in sshd, and that doesn't really have to be anything to do with authentication (the XZ thing wasn't). Yes it would be a very bad day for you if someone got in to your Xen Shell, but that's as far as that goes, so I am still okay with leaving that determination up to the customer. I can't see a way of avoiding there having to be a list of net blocks. With 50+ VMs on a host, if SSH is opened up from anywhere for any one of them then it is open for all so really even with a timeout it would be open a lot of the time. 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. 😀 I'd be interested in hearing your thoughts on this. Thanks, Andy ¹ Which you may not know because you might be behind one or more layers of NAT. -- https://bitfolk.com/ -- No-nonsense VPS hosting _______________________________________________ BitFolk Users mailing list &lt;users(a)mailman.bitfolk.com&gt; You're subscribed as &lt;space.dandy(a)icloud.com&gt; Unsubscribe: <https://mailman.bitfolk.com/mailman/postorius/lists/users.mailman.bitfolk.com/> or send an email to &lt;users-leave(a)mailman.bitfolk.com&gt; <signature.asc>