179

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
  • 791
  • 1
  • 8
  • 16
sdot257
  • 3,039
  • 5
  • 29
  • 38
  • 15
    Is this the error that you are getting? "Cannot open your terminal '/dev/pts/0' - please check." – Jim Feb 25 '10 at 15:26
  • yep thats the one. I understand why it's happening but is there a workaround? – sdot257 Feb 25 '10 at 15:32
  • 4
    A comment on your commands -- I keep seeing people running `sudo su "user" -`. Why not use `sudo -u user -s`? – Andrew Aylett Feb 25 '10 at 16:38
  • 2
    @Jim: +1 for supplying the missing error message. – Dennis Williamson Feb 25 '10 at 16:41
  • 1
    @Andrew Most guys I know do `sudo su` - I think it's just what people get used to (in my case it's because you don't need to know any sudo flags to `sudo su` - I don't think I've ever read the sudo manpage :) – voretaq7 Feb 25 '10 at 16:50
  • I had the same issue while trying to run screen from rc.local. Solved it by calling "screen -d -m", even thought I use a configuration file that specifies "detach". Looks like -m makes all the difference, even thought I cannot put it in the configuration file. – Penz Oct 14 '13 at 13:44

8 Answers8

257

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
  • 79,345
  • 17
  • 128
  • 213
  • 1
    so um ... any security implications with this one? I think I can add the user to the tty group but that wouldn't be ideal. :-P – sdot257 Feb 25 '10 at 19:07
  • 5
    Re: security implications, none I'm aware of (but that doesn't mean there aren't any :) - IIRC this relies on a side-effect of "script" opening a new terminal device (as the user invoking it), and since you're sending script's output to /dev/null there's nothing to capture. It's also definitely safer than adding users to the tty group (IMHO) – voretaq7 Feb 25 '10 at 19:20
  • 1
    One problem is that it opens another shell I have to exit. It can be confusing. First `sudo su` then `script` then `screen`. Then I have to exit three times. – nalply Oct 08 '13 at 09:42
  • 2
    @nalply Frankly you shouldn't find multiple shells confusing if you're a Unix system administrator -- that said, `script` can be used to launch `screen`. Then you only have to exit twice (once for `screen`, once for `su`). (This is something the `script` man page can clarify for you, if you take the time to read it...) – voretaq7 Oct 08 '13 at 15:40
  • Of course I didn't speak for myself but for colleague. He is not a sysadmin and he just wants his stuff done and then gets out of these three shells as fast as possible. :-) – nalply Oct 09 '13 at 06:25
  • 11
    Or just run `sudo -u bob script -q -c 'screen -dr myscreen' /dev/null`. Then you only have one terminal to exit/detach from. – Andy Shulman Nov 27 '13 at 04:48
  • If you want to add this command to the ~/.bashrc of the user, you can add: `[ -n "$SCRIPT" ] || SCRIPT=y script /dev/null export SCRIPT` This will cause you to have to double exit though. – Matthew Herbst Sep 25 '14 at 21:12
  • 4
    Thanks, this saved me. But why does this fix it? From what I understand, it prints everything from stdout to... nowhere. And that somehow fixes screen. – sudo Jan 15 '16 at 20:33
  • 4
    @sudo In order to do its thing `script` opens its own tty device, owned by the user who ran it (look in `/dev` and you'll see it appear after you run `script`). `screen` then grabs that tty device (which is owned by the user running `screen` so it has no trouble accessing it). It's a total hack job, but it works. Looking at some of my machines it appears new versions of screen seem to install setuid-root, which also works, but means you have another setuid-root binary floating around, which makes some folks justifiably uncomfortable. – voretaq7 Jan 20 '16 at 23:01
  • 1
    Using `exec` to run either `screen` or `script` will mean you only have to exit once. – opello Mar 18 '17 at 14:22
  • Note that running `script /dev/null` will fail (`script` will immediately exit) if `SHELL` is not set to something reasonable (e.g., to `/bin/false`, for a user not supposed to be allowed to log in). In this case you can do `SHELL=/bin/bash script /dev/null`. – a3nm Aug 10 '19 at 21:57
  • 1
    @voretaq7 but what forbids `screen` itself from doing the same thing as `script` does? – Nikita Kipriyanov Oct 30 '19 at 13:18
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.

steviethecat
  • 463
  • 4
  • 6
  • 1
    Works perfectly. For those wanting this system-wide, I recommend adding this to /etc/bash.bashrc - works across all users. – Someguy123 Jan 02 '15 at 08:19
  • 2
    This will not quote arguments to screen correctly, otherwise a good solution. – augurar Nov 09 '16 at 18:13
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,477
  • 1
  • 23
  • 32
  • This is another good approach -- You would have to specify forced commands in the authorized keys file though (per luckytaxi's "giving them access to the 'monitor' user is out of the question" note above -- forced commands could limit them to just attaching the screen session) – voretaq7 Feb 25 '10 at 16:59
  • 2
    I wasn't sure how to address that in my answer, because he said "giving them access...is out of the question", but also said "...they sudo into the 'monitor' user". But I agree, forcing command restriction in the authorized_keys should take care of that. – Alex Feb 25 '10 at 20:14
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
  • 333
  • 3
  • 8
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.

Bart Silverstrim
  • 31,092
  • 9
  • 65
  • 87
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.

Doug Harris
  • 267
  • 1
  • 4
  • 10
0

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

sudo chmod o+rw /dev/pts/0

Then try screen again

Filippo Vitale
  • 483
  • 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,067
  • 1
  • 10
  • 19
Amos Shapira
  • 839
  • 2
  • 11
  • 23
  • 2
    Sounds like a great solution. – Evan Carroll Jan 20 '12 at 16:19
  • 12
    @EvanCarroll It's a great solution, except the part where it gives ***the entire world*** read & write access to his terminal. Just a minor security problem - No program would care about that, except of course anything that checks terminal security before accepting passwords (`gpg` for example). And surely he'll never be on a system with malicious users who would watch the `tty` and sniff passwords... – voretaq7 Oct 08 '13 at 15:35
  • **Be warned**: never try this at home! this is dangerous!!! – ruizpauker Aug 30 '18 at 10:12