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.