Automatically change user when using terminal access

[sylvaincolson]

When connecting to a remote Linux (Linux Debian), the connection is made as root. I have already read the Issue #362 but I'm looking for a way to automatically connect as another user, since root user must be avoided in my situation.

Would there be a solution that could be suggested to me, please ?

[MailYouLater]

@Ylianst / @krayon007 Could the terminal be set to launched with the --login parameter to make it request the username/password to log in as?

Edit: -l or --login will make sh, bash, fish, and possibly other shells require the user to login, but it's also possible other shells would need a different parameter (or set of parameters) to do so, so perhaps it would be a good idea to allow us to set parameters to launch the terminal with, then mention in the Tips and Tricks section of the guide that --login is the one to use to make bash require a login.

[krayon007]

I'll have to do some testing, but I recall the issue with that approach was that it broke the pipe redirection.

[MailYouLater]

@sylvaincolson: Is the issue that you don't want to accidentally run things as root but it's OK to fall back to root if you don't log in to another user account successfully? or is it that you don't want to be allowed to operate as root, and instead want to be forced to log in as another user, and if you don't successfully log in as another user, you get kicked off?

[krayon007]

Another potential issue, is that if this works, if you type 'exit' instead of exiting the terminal, it will revert back to the root console.

[sylvaincolson]

@sylvaincolson: Is the issue that you don't want to accidentally run things as root but it's OK to fall back to root if you don't log in to another user account successfully? or is it that you don't want to be allowed to operate as root, and instead want to be forced to log in as another user, and if you don't successfully log in as another user, you get kicked off?

In my situation, I will allow people (let's call them "operators") to remote log inside a computer. These people could do things they must not be allowed to do, therefore root access must not be allowed to them. That is the reason why, beside the root account, an operator account is created on the client computer and that is to this account I want the operator to connect to.

I think I have found a solution, could you please tell me what you think of it (I detail it below)

[sylvaincolson]

First of all, thank you all for replying and considering my request. After posting my message, I tried something that worked for me, but I am not sure if you would recommend it to me.

The trick I did is actually quite obvious and simple, but I do not know if there are security issue or any counter-argument to proceeding as I did.

When executing the installation as described in the Installation guide, we create a service associated to the root user. In the file /lib/systemd/system/meshagent.service, we can add the line User=operator in the [Service] section. We can update the demon and reload the service using the sh command :

sudo systemctl daemon-reload && sudo service meshagent restart

On the server web page, we can see that the once-accessible machine is now no longer reachable. The meshagent DB and MSH files are read-only accessible to the operator user and a

sudo chmod 664 /usr/local/mesh/meshagent.*
sudo chown root.operator /usr/local/mesh/meshagent.*

command should grant access to the user. On the server web page, the terminal command is once again accessible and logs us as operator user.

Thank you for your advices and time. It is possible that my solution is not recommended so please, do not hesitate to tell me so.

[ryanblenis]

This actually sounds like the optimal solution for your case IMO. If you want to restrict the rights of all users of the Mesh Agent, it should be running as a user with those restricted rights. The same could be accomplished on Windows by modifying the user the service runs as and restarting the service.

[MailYouLater]

I agree with ryanblenis. I was considering suggesting that you either use the root user's .bashrc file to script switching to a different user, or that you change the default shell of the root user to a script that forces you to log in as another user, but both of these have some major drawbacks, mainly that you have to choose to either allow someone who doesn't properly log in to another account to fall back to root, or you end up making it extra difficult to log in as root, even in special cases where it might be necessary. Switching which user the mesh agent runs as is a more secure, and less hassle inducing way to fix the issue without having to write any custom scripts.

This actually brings up an interesting point though... Isn't it generally considered bad practice to run software like the mesh agent as root? I'm not sure what the best solution for this is, but I think it would be a good idea for the MeshCentral team to reconsider having it run as root. Whether this means making an easy way to set it to run as a non-root user, or changing the setup to ask what user it should run as, or even making the setup default to creating a new meshagent user for the mesh agent to run under unless you choose to set it up differently.

Note: On Linux, there is rarely any reason to run software as root, especially remote access software like the mesh agent, and doing so is generally considered a security issue. If the remote user needs to be able to do root things, they should be granted permission to run things with sudo, and if they really need to act as root directly, they can use sudo su to su into the root user.

[ryanblenis]

I don't think it is a great practice to allow any software to run as root / admin explicitly, however in the case of MeshCentral, a program designed to offer a remote user/manager complete control over the destination computer, I'd think that should be the default. Most RMM system's agent install with this privilege level. Otherwise having a user load an agent for even a temporary support session could become burdensome or impossible if you have to walk a typical user through granting admin privs before being able to access what you need/want to access.

[krayon007]

The MeshAgent runs as root when running as a background service, because some of the API's that it needs to access requires root. For example, if the agent runs as local user, you'll lose all access to AMT APIs, because the HECI driver will only talk to privileged processes. Likewise certain API calls to do interactive things and/or task scheduling, etc, also require privileged access. In some cases, user escalation via the UAC prompt is insufficient, as some API calls explicitly require LocalSystem privileges.

But to answer the original question... On linux, spawning a terminal as a local user is actually extremely easy, as you can just specify the UID of the user you want the terminal session to spawn under. We also have support, to set the environment variables how you see fit... All this would just require tweeking the JavaScript in meshcore.js to do what you want it to do...

Windows is a little more complicated, but I'm in the process of writing a new terminal module, to take advantage of the new PseudoConsole API, so that module should be just as flexible as the linux counterpart... (This should also resolve the on-going issues with backspace, ctrl-c, powershell, etc)

[sylvaincolson]

I think I have almost everything I need. I will keep this issue alive a couple more days before closing it and considering it resolved.

I thank everyone who took an interest in my matter, yet I could still use your help on an issue derive from this one (#678). Thank you again.