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


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.

  • 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? Feb 25 '10 at 16:38
  • 2
    @Jim: +1 for supplying the missing error message. 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

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.

  • 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
  • 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 8 '13 at 15:40
  • 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. Nov 27 '13 at 4:48
  • 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

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.

  • 1
    Works perfectly. For those wanting this system-wide, I recommend adding this to /etc/bash.bashrc - works across all users.
    – Someguy123
    Jan 2 '15 at 8:19
  • 2
    This will not quote arguments to screen correctly, otherwise a good solution.
    – augurar
    Nov 9 '16 at 18:13

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

  • 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

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"'


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.


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.


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.

  • 3
    Nope. sudo su - username and sudo su username - do the same thing. Nov 10 '14 at 20:59

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

sudo chmod o+rw /dev/pts/0

Then try screen again


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.

  • 2
    Sounds like a great solution. 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 8 '13 at 15:35
  • Be warned: never try this at home! this is dangerous!!!
    – ruizpauker
    Aug 30 '18 at 10:12

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.