0

On my Ubuntu 20.04.5 machine, I have a Perl script running under userA's account. The script issues this command:

sudo su - userB -c "ssh -l userB 10.0.0.1 ls -tr /some/remote/directory"

(i.e., SSH to a remote host as userB, and then list all the files in /some/remote/directory)

The command works great... except that I'm seeing an error on the command line:

me@ubuntu1$ sudo su - userB -c "ssh -l userB 10.0.0.1 ls -tr /some/remote/directory"
mesg: cannot open /dev/pts/2: Permission denied
Welcome to 10.0.0.1!  You have logged in.
file1.txt
file2.txt
file3.txt
me@ubuntu1$

What is that mesg: cannot open /dev/pts/2: Permission denied message???

A little Internet research reveals that:

Entries in /dev/pts are pseudo-terminals (pty for short). Unix kernels have a generic notion of terminals. A terminal provides a way for applications to display output and to receive input through a terminal device.

And assuming that I'm only reading through my pseudo-terminal:

If a program opens a terminal for reading, the input from the user is passed to that program. If multiple programs are reading from the same terminal, each character is routed independently to one of the programs; this is not recommended. Normally there is only a single program actively reading from the terminal at a given time; programs that try to read from their controlling terminal while they are not in the foreground are automatically suspended by a SIGTTIN signal.

That's interesting... but I'm still befuddled why I'm seeing mesg: cannot open /dev/pts/2: Permission denied. I'm still developing my script and have run it several times; I can't remember if I noticed this error message on the first run. Is it likely that every time my script runs, it tries to access /dev/pts/2 every time, but my code didn't properly close the connection or something?

Or might this be related to userA using userB to run the command? Pseudo-terminals wouldn't come into play when accessing another user account, would they?

Any insight or feedback is welcome, thank you.

Improve this question
6
  • 1
    can you try with ssh -t .......... ?
    – Gilles Quénot
    Nov 16, 2022 at 17:12
  • @GillesQuenot Thanks Gilles. So running sudo su - userB -c "ssh -t -l userB... didn't make a difference; the error message still appears, sadly.
    – Pete
    Nov 16, 2022 at 17:17
  • 1
    Does this happen if you invoke sudo su - userB to become userB and then separately invoke the ssh command ssh -l userB 10.0.0.1 'ls -tr /some/remote/directory' ?
    – Sotto Voce
    Nov 16, 2022 at 17:23
  • @SottoVoce If I manually test on the command line and break the command up into the sudo su - userB and then issue the ssh command, no, there is no error message. I'd like to keep the command as one line in my script, if possible. Thanks!
    – Pete
    Nov 16, 2022 at 17:31
  • 1
    My question was for diagnosis. No error from the mesg command was seen in the ssh to the remote server, so it's most likely coming from the local server. Does userB have some sort of invocation of mesg in their home directory's .bash_profile or .zprofile file?
    – Sotto Voce
    Nov 16, 2022 at 17:57

1 Answer 1

Reset to default
2

if group assigned of that device is "tty", just add the user in that group tty (/etc/group).

Regards

Improve this answer

You must log in to answer this question.

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