Hi ejolson,
I agree with respect to the VM perhaps being overkill, but I figured there is no harm, and it would mean not having to create the users on my own or any other existing machine, thus keeping them 'cleaner'.
Spinning up a VM is no big deal, but there is a risk in that as well - VM bloat is all to easy to experience!
I suppose I could always run, say, lastb, as the very first thing on the VM each time to make sure there is no-body else accessing, but I think it might show all the (failed) access attempts by the users that have not been enabled - I would have to test that to be sure.
Thanks,
Alan.
Agreed - this would be purely key-based access, with password login over SSH disabled for each of the 'remote access' users.The way I understand your configuration is the remote sites use a username and password to set up a reverse tunnel into your server. I'd suggest using public keys instead and in the authorised key file on the server add options so only tunnels can be set up and not arbitrary shell access.
In my opinion if sshd and authorised keys are set up correctly, then the VM is not needed. On the other hand if you give a dog shell access, almost anything can happen--even from inside a VM.
I agree with respect to the VM perhaps being overkill, but I figured there is no harm, and it would mean not having to create the users on my own or any other existing machine, thus keeping them 'cleaner'.
Spinning up a VM is no big deal, but there is a risk in that as well - VM bloat is all to easy to experience!
I suppose I could always run, say, lastb, as the very first thing on the VM each time to make sure there is no-body else accessing, but I think it might show all the (failed) access attempts by the users that have not been enabled - I would have to test that to be sure.
Thanks,
Alan.
Statistics: Posted by Alan2409 — Tue Sep 10, 2024 4:22 am