180

Found out today that running screen as a different user that I sudo into won't work!

i.e.

ssh bob@server         # ssh into server as bob
sudo su "monitor" -
screen                 # fails: Cannot open your terminal '/dev/pts/0'

I have a script that runs as the "monitor" user. We run it in a screen session in order to see output on the screen. The problem is, we have a number of user who logs in with their own account (i.e. bob, james, susie, etc...) and then they sudo into the "monitor" user. Giving them access to the "monitor" user is out of the question.

Thomas
  • 821
sdot257
  • 3,079

8 Answers8

259

Try running script /dev/null as the user you su to before launching screen - its a ghetto little hack, but it should make screen happy.

voretaq7
  • 80,749
36

I am using a wrapper function around screen for the user(s) that I sudo su to. This is the wrapper function that I've added to the user(s) ~/.bashrc:

function screen() {
  /usr/bin/script -q -c "/usr/bin/screen ${*}" /dev/null
}

This allows me to use all of the options and parameters for screen that I might want to use. I am contemplating on putting this function systemwide.

7

Assuming they are SSHing into the host anyway, you could add the public ssh keys for each user that needs access to the monitor account in the ~monitor/.ssh/authorized_keys file. Then on each user's remote machine they can run

ssh -t monitor@remote.machine screen -RD

Alex
  • 6,723
7

Assuming we're talking about this error:

$ sudo su - bob
$ screen
Cannot open your terminal '/dev/pts/5' - please check.

Here's a one-liner (could be used as "alias gobob", for example):

sudo su - bob -c "script -c bash /dev/null"'

Explanation:

This will start a shell (like login shell) as user bob. User bob starts script, which is told to invoke a bash (could be dash or ksh...) and a copy of the session is thrown away.

basic6
  • 383
0

Probably would have to change permissions on the device in question or add monitor to a group that has permission to read that device, that would be my first inclination. But you'd have to weigh the security implications of doing so.

0

You say you do:

sudo su "monitor" -

I'm wondering about the trailing dash. I usually do:

sudo su - username

The dash (per the su man page) tells su to "make the shell a login shell". This means it will source all the usual shell startup scripts and set things like PATH and HOME properly.

0

I would just give the read/write permission to "other":

sudo chmod o+rw /dev/pts/0

Then try screen again

Filippo Vitale
  • 553
  • 1
  • 5
  • 8
-4

I just hit this problem. Solved it with chmod +rw $(tty) before running sudo. The problem with this solution is that anyone can connect and snoop on your terminal after that.

nalply
  • 1,147