Posted: Thu 11 Apr 2019, 15:47
Yes, I've blocked ssh from external as I've been experimenting with EasyOS
As part of standard ssh server you can set a chroot to run. However its trivial to break out of a chroot if you can chroot within that. The answer is to drop the chroot capability (i.e. at the kernel level).
Currently the way I have things set up is that userid 'ssh' is listening to incoming ssh connections and its shell script (instead of /bin/sh for instance) su's to aufs mounts a changes folder along with the main Easy sfs to a top folder, but where the chroot capability is dropped for that and only then chroots into the top (top layer) folder as su spot.
Puppy/EasyOS is odd in that it uses busybox su and if you set that setuid so spot/ssh or whatever can su, then the whole of busybox becomes setuid root - a potential security risk. But if the main system has that set and incoming ssh connections run a chroot (easyOS container) that doesn't have su setuid, then that risk is mitigated.
Currently I have that set so the changes folder is just deleted after disconnection, so a pristine EasyOS connection for each new ssh. Could easily be made persistent but best to have it just reset to the clean boot each time IMO. I've remastered the main EasyOS sfs for that purpose (layout). I've also set it to be cli only (so primarily targeted as being for tmux type purposes/uses) - no X forwarding. But could just as easily have X forwarded and be gui/X based. For cli only it makes the client (remote) end that much simpler, just need a vmlinuz/initrd with busybox and ssh support, perhaps a 20MB boot. For X, the client would also need a X based boot (200MB - 300MB typically).
Presently I'm using hashbang.sh as a Socks proxy, so all http(s) traffic routed through that, and with a small firefox tweak that also disconnects any dns leakage. So conceptually a remote client could ssh in using a minimal 20MB boot which in turn routes all http traffic via a ssh tunnel with no dns leakages. Whilst being relatively quick (socks proxying is quicker than tor or vpn). If the client, ssh server and socks proxy are in three different jurisdictions, perhaps with barriers to the free sharing of information, then that's moderately anonymous. More so if set up on a liveCD type setup, with periodic reboots (runs in ram, contents (records) lost after a reboot).
As part of standard ssh server you can set a chroot to run. However its trivial to break out of a chroot if you can chroot within that. The answer is to drop the chroot capability (i.e. at the kernel level).
Currently the way I have things set up is that userid 'ssh' is listening to incoming ssh connections and its shell script (instead of /bin/sh for instance) su's to aufs mounts a changes folder along with the main Easy sfs to a top folder, but where the chroot capability is dropped for that and only then chroots into the top (top layer) folder as su spot.
Puppy/EasyOS is odd in that it uses busybox su and if you set that setuid so spot/ssh or whatever can su, then the whole of busybox becomes setuid root - a potential security risk. But if the main system has that set and incoming ssh connections run a chroot (easyOS container) that doesn't have su setuid, then that risk is mitigated.
Currently I have that set so the changes folder is just deleted after disconnection, so a pristine EasyOS connection for each new ssh. Could easily be made persistent but best to have it just reset to the clean boot each time IMO. I've remastered the main EasyOS sfs for that purpose (layout). I've also set it to be cli only (so primarily targeted as being for tmux type purposes/uses) - no X forwarding. But could just as easily have X forwarded and be gui/X based. For cli only it makes the client (remote) end that much simpler, just need a vmlinuz/initrd with busybox and ssh support, perhaps a 20MB boot. For X, the client would also need a X based boot (200MB - 300MB typically).
Presently I'm using hashbang.sh as a Socks proxy, so all http(s) traffic routed through that, and with a small firefox tweak that also disconnects any dns leakage. So conceptually a remote client could ssh in using a minimal 20MB boot which in turn routes all http traffic via a ssh tunnel with no dns leakages. Whilst being relatively quick (socks proxying is quicker than tor or vpn). If the client, ssh server and socks proxy are in three different jurisdictions, perhaps with barriers to the free sharing of information, then that's moderately anonymous. More so if set up on a liveCD type setup, with periodic reboots (runs in ram, contents (records) lost after a reboot).