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, 2010 at 15:26
  • yep thats the one. I understand why it's happening but is there a workaround?
    – sdot257
    Feb 25, 2010 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, 2010 at 16:38
  • 2
    @Jim: +1 for supplying the missing error message. Feb 25, 2010 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, 2010 at 16:50

8 Answers 8


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, 2010 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, 2013 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, 2013 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, 2016 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, 2016 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, 2015 at 8:19
  • 2
    This will not quote arguments to screen correctly, otherwise a good solution.
    – augurar
    Nov 9, 2016 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 [email protected] 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, 2010 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, 2010 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, 2014 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, 2012 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, 2013 at 15:35
  • Be warned: never try this at home! this is dangerous!!!
    – ruizpauker
    Aug 30, 2018 at 10:12

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .