Run host.dbr without giving access to a shell account
Closed this issue · 6 comments
We'd like to run host.dbr on Linux without giving the user account shell access. ie. if someone logged in with the user account then they would simply see "READY" and if they tried to crash out it would log out the session.
We've tried to execute launch from the user's startup script etc but it doesn't seem to work.
Does anyone know if there's something simple we may be missing?
I will send more info and screenshots etc if it's not clear what we're trying to do.
Thanks
If you're running the .Net service directly on your linux box you dont need it to have any shell access at all. My understanding is that this is blocked for you, waiting on a supported version of RHEL.
We're hosting HC on windows IIS and using ssh to run the host.dbr on Linux.
yes, but.... my understanding of your direction was that you wanted to host directly on linux but are currently blocked from that because you have too old a version of RHEL. If you upgrade that you will get this current request for free.
Is that no longer the direction that you're headed in?
Surely that's irrelevant! That may be our future preference but for now we are using it as set up by Synergex PSG which uses IIS and ssh to Linux.
I'm assuming you're looking into this because of the security implications of having an SSH account that could access the system. Since you shouldn't be giving actual human users access to this service account, I am further assuming that you are intending to protect against some sort of rogue process that is running on your network that has somehow extracted the service credentials and will use that connection, control-c out of the traditional bridge application and then go about its dastardly deeds. Unfortunately captive SSH accounts wont solve this problem for you, a mildly determined actor can bypass them using instructions like these https://serverfault.com/questions/94503/login-without-running-bash-profile-or-bashrc.
So, if I've guessed your intent correctly, the only way to do what you want is to run the process locally.
We've managed to get this all working in a secure shell now including handling the exploit in the link you shared, as well as various other exploits.