screen fails with “Cannot open your terminal ‘/dev/pts/x’ – please check.”

A quick note on how to get around this problem. Background: many shops uses individual operating system accounts for DBAs and keep the oracle password secret. Once connected, the user would sudo to oracle: “sudo su – oracle” which is explicitly allowed. The auditors can then trace who did what and when, otherwise the logins to oracle would be almost completely anonymous.

Here’s a sample session output to demonstrate the problem:

login as: mbh
mbh@prodbox's password:
Last login: Thu Jan 14 12:11:12 2010 from desktop001

RHN kickstart on 2009-07-27

[mbh@prodbox ~]$ sudo su - oracle
[oracle@prodbox ~]$ screen
Cannot open your terminal '/dev/pts/4' - please check.

This is slightly frustrating-starting the screen session with your account works fine, but then no one can follow up and connect to your session. The quick but insecure solution is as follows:after logging in as yourself, find out which tty you use:

[oracle@prodbox ~]$ w | grep mbh
mbh    pts/4    desktop001 12:14    0.00s  0.05s  0.07s sshd: mbh

Then grant permission to your tty to the world:

[mbh@prodbox ~]$ chmod a+rw /dev/pts/4

Alternatively, add the oracle user to group tty, which owns all the ttys.

Now sudo to oracle and start your screen sesssion:

[mbh@prodbox ~]$ sudo su - oracle
[oracle@prodbox ~]$ screen
[screen is terminating]

Also check the comment by Ariel for another solution. Anyway, check with your security team what method is most appropriate in your situation.

11 thoughts on “screen fails with “Cannot open your terminal ‘/dev/pts/x’ – please check.”

  1. coskan

    Shame on me, I never heard about screen command :(. It looks extremely useful. Thank you for mentioning the command Martin.

  2. Pingback: Blogroll Report 15/01/2009 – 22/01/2010 « Coskan’s Approach to Oracle

  3. oracledba01

    Strikes me that if you don’t want your dbas to know the oracle password you have bigger issues than security. Am I the only one thinking that sudo is a poor substitute for trust? And if we’re saying to our colleagues you aren’t trustworthy then why did we hire them in the first place? There is no amount of controls, devices, or features that can protect us from people without integrity.

    1. Martin Post author

      The bigger problem is called SAS 70 accreditation in this case. However I know many shops where direct access to the oracle (or root) account is prohibited for accountability.

  4. Ariel

    > Then grant permission to your tty to the world:
    > [mbh@prodbox ~]$ chmod a+rw /dev/pts/4

    VERY bad idea, by doing that you are allowing anybody in your “prodbox” to have your “mbh” privileges (hopefully you won’t never ever do that if /dev/pts/XX is owned by root!!!)

    Rather just use the script/screen combination or in your screen session do:

    CTRL-a multiuser on
    CTRL-a addacl

    (more info: man screen)

  5. Julian

    As mentioned by Ariel, to allow any user to access my pty shall not the target. :)
    Just a couple of specific users are allowed to login via SSH directly to my Server and share some other users to manage specific services.

    To avoid, everyone needs to run “script /dev/null” and logout twice, when using a shared user, I have append the ~/.bashrc of related user as below.

    if [ “$(stat -c ‘%U’ $(tty))” != “$(whoami)” ]; then
    script -q /dev/null

Comments are closed.