I have multiple test user accounts on a Linux box. These accounts have different (restricted) shells, with unique login scripts and crontabs configured. When I power up and log into my system using my regular account, I would like all of these other users to be automatically logged in (in the background) as well. How can this be done?

In essence, I want it to be as if those users are actually logged into the machine with me, doing stuff (the login scripts and cron jobs simulate activity), without human users (or other machines) actually needing to establish a connection to my box, enter login credentials, or any of that sort of thing. Apart from getting those test users logged in, I do not need any additional interactivity.

I realise that I can run processes as arbitrary users, but I don't (think I) want to do that. I want the commands executed by these test users to have the whole environment and side-effects of a restricted shell. I want to be able to type who and see their names come up.

  • 1
    If you use tmux and tmuxinator you can create a terminal window with several panes that each can be logged into a different machine, and you can set up "broadcast" so that anything typed into one pane is also typed into all the others. – glenn jackman Jan 27 at 14:36
  • Are you wanting them to have an X11 (graphical) login, or tty (text) login? – ctrl-alt-delor Jan 27 at 15:25
  • @ctrl-alt-delor I would like the users to be logged in 'in the background'. Ideally that would mean no windows at all ever being associated with their login or continued operations. A text-based login sounds like a better fit than a graphical one. – Tim Jan 27 at 22:27
  • @glennjackman tmux seems to be a remake of screen tailored and optimised for people that want to interact with the shells. At this point I don't need interactivity at all — login scripts and cron jobs are fine. Looking into tmux, however, I stumbled across dtach— something that might be an even better fit for me than screen. So thanks for that! – Tim Jan 28 at 5:00

You didn't specify if you want these user sessions to be interactive, ie. you could attach to them and run commands yourself, or some tools will run commands in these sessions automatically, or they should just "sit and do nothing" (be logged in and idle). Each case would require a slightly different approach.

I would suggest to install expect and write expect scripts that log to these accounts using for example ssh -l user localhost (you could use su -l user as well, but these sesions won't show in who output). You might want to mix screen in if you want to be able to control these sessions. Then put these scripts in your .profile so that they run automatically when you log in.

You can find sample expect scripts that log in to a machine and do something here or here.

  • The test accounts would execute cron jobs and commands as per their login scripts. The commands in the login scripts will be many and varied, and should keep that virtual user "busy" as long as I have the system running. They should not be idle for any extended period of time. From my regular login I would like to monitor their activity with regular sysadmin tools, but otherwise not interfere with what they are doing. I would not be running ad-hoc commands as any of the users. – Tim Jan 27 at 13:17
  • So running expect scripts that log in with ssh -l user localhost should be enough. – raj Jan 27 at 13:19
  • 1
    In short, expect creates a virtual terminal, in which you can run any interactive program (eg. a login session) and programatically interact with it ie. feed input and read output. So it basically simulates a human user interacting with the program. In your case the "user" will however do nothing after logging in, I guess. I used ssh as an example to make the sessions record in utmp, so you will see them in who output (su does not record in utmp). You may use telnet as well, but telnet is often no more installed on modern system. I'm not sure if telnet will consume less resources than ssh. – raj Jan 27 at 13:39
  • 1
    The session is kept active as long as the expect script runs; if you terminate the expect script it has the effect as if you disconnect from a logged in session; usually the session is aborted in such case. But you can add screen to it and detach it to the background if this is needed. Detached session on screen will keep running even if the session it was started from aborts. Everything depends on what you need. – raj Jan 27 at 13:46
  • 1
    Both expect and screen provide virtual terminals, but while expect is for scripting, screen is for manual use. If you are able to configure key-based ssh authentication on these users so that you don't need to type password when you log in, maybe you won't need expect at all; just running a couple of detached screen sessions like screen -d -m ssh -l user localhost might be what you want. – raj Jan 27 at 13:55

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.