Sample Header Ad - 728x90

Unable to write to client over ssh

2 votes
0 answers
111 views
## Preface I am unable to write to my client user connected over SSH. No issues with users on server. I run as root, and SELinux is disabled for all the tests below(sudo setenforce 0). Yet, I always get the below error:
[vtian@vbox ~]$ write vtian pts/0
write: vtian is not logged in on pts/0

[vtian@vbox ~]$ who | grep [p]ts/0
vtian    pts/0        2025-06-24 17:55 (10.0.2.2)
If I write to vtian tty1 which is logged in server-side, there is no issues at all. I have another question [here](https://unix.stackexchange.com/questions/797201/unable-to-write-to-self-in-graphical-terminal-session/797235#797235) which is answered, to make sure that it wasn't an issue with my client gnome-terminal. ## Prerequisites I have checked * user is logged in utmp (According to who, loginctl, and last). * user tty is correct (tty returns pts/0). * user can receive messages if writing directly to the fd /dev/pts/0. * user is receiving messages (According to who -T and mesg). * write has s+g permission (setgid) ## Write Version [Edit 1]
vtian@vbox ~]$ sudo rpm -qf $(which write)
util-linux-2.40.2-10.el10.x86_64
## who and last and ls output [Edit 1]
[vtian@vbox ~]$ last | head -n 4
vtian    pts/0        10.0.2.2         Mon Jun 23 16:18   still logged in
vtian    tty1                          Mon Jun 23 16:18   still logged in
reboot   system boot  6.12.0-55.16.1.e Mon Jun 23 16:17   still running
vtian    pts/0        10.0.2.2         Sat Jun 21 16:19 - 16:29  (00:09)
[vtian@vbox ~]$ last | head -n 5
vtian    pts/0        10.0.2.2         Mon Jun 23 16:18   still logged in
vtian    tty1                          Mon Jun 23 16:18   still logged in
reboot   system boot  6.12.0-55.16.1.e Mon Jun 23 16:17   still running
vtian    pts/0        10.0.2.2         Sat Jun 21 16:19 - 16:29  (00:09)
vtian    tty1                          Sat Jun 21 16:18 - 16:29  (00:11)
[vtian@vbox ~]$ who -aT
           system boot  2025-06-23 16:17
vtian    + tty1         2025-06-23 16:18 00:01        4299
           run-level 3  2025-06-23 16:17
vtian    + pts/0        2025-06-23 16:18   .          4903 (10.0.2.2)
           pts/1        2025-06-23 16:18              4939 id=ts/1  term=0 exit=0
[vtian@vbox ~]$ sudo ls -l $(which write)
-rwxr-sr-x. 1 root tty 24152 Feb 13 08:00 /usr/bin/write
## Disk Mount Status [Edit 1] My disk is using LVM. None of the LVs are mounted with nosuid. The only mounts with nosuid are /proc, as well as some stuff in /dev, /sys, and /run. ## loginctl output [Edit 2] I have just found out something really strange and reproducible. Output for loginctl and sudo loginctl on vtian tty1, and loginctl on vtian pts/0 given the condition stated below.
[vtian@vbox ~]$ loginctl
SESSION  UID USER  SEAT  LEADER CLASS   TTY   IDLE SINCE
      2 1000 vtian -     3697   manager -     no   -    
      3 1000 vtian seat0 3149   user    tty1  no   -    
      6 1000 vtian -     3960   user    pts/0 no   -    
3 sessions listed.
Output for sudo loginctl on pts/0
[vtian@vbox ~]$ sudo loginctl
[sudo] password for vtian: 
SESSION  UID USER  SEAT  LEADER CLASS   TTY  IDLE SINCE
      2 1000 vtian -     3697   manager -    no   -    
      3 1000 vtian seat0 3149   user    tty1 no   -    
      6 1000 vtian -     3960   user    -    no   -    

3 sessions listed.
After I run sudo loginctl from vtian pts/0, vtian pts/0 is gone from logind for the rest of the session! If I run loginctl or sudo loginctl from vtian tty, I continue to get the above output! The only way to fix it is by restarting the ssh session. ## Other Outputs [Edit 2]
vtian@vbox ~]$ sudo grep -e @include -e pam_systemd /etc/pam.d/{sshd,common*}
grep: /etc/pam.d/common*: No such file or directory
## PAM Systemd Output [Edit 3]
[root@vbox vtian]# grep -r pam_systemd /etc/pam*
/etc/pam.d/runuser-l:-session	optional	pam_systemd.so
## uname and distro info [Edit 4]
[root@vbox vtian]# uname -a
Linux vbox 6.12.0-55.16.1.el10_0.x86_64 #1 SMP PREEMPT_DYNAMIC Tue Jun 10 18:27:04 UTC 2025 x86_64 GNU/Linux
[root@vbox vtian]# cat /etc/os-release
NAME="Rocky Linux"
VERSION="10.0 (Red Quartz)"
ID="rocky"
ID_LIKE="rhel centos fedora"
VERSION_ID="10.0"
PLATFORM_ID="platform:el10"
PRETTY_NAME="Rocky Linux 10.0 (Red Quartz)"
ANSI_COLOR="0;32"
LOGO="fedora-logo-icon"
CPE_NAME="cpe:/o:rocky:rocky:10::baseos"
HOME_URL="https://rockylinux.org/ "
VENDOR_NAME="RESF"
VENDOR_URL="https://resf.org/ "
BUG_REPORT_URL="https://bugs.rockylinux.org/ "
SUPPORT_END="2035-05-31"
ROCKY_SUPPORT_PRODUCT="Rocky-Linux-10"
ROCKY_SUPPORT_PRODUCT_VERSION="10.0"
REDHAT_SUPPORT_PRODUCT="Rocky Linux"
REDHAT_SUPPORT_PRODUCT_VERSION="10.0"
## strace [Edit 5] I don't know how to interpret the strace data, but it looks to me like write does successfully iterate the vtian pts/0 session, but it seems to disregard it as not belonging to vtian pts/0
[root@vbox vtian]# strace -o /tmp/tracefile write vtian pts/0
write: vtian is not logged in on pts/0
[root@vbox vtian]# grep '/run/systemd/sessions/' /tmp/tracefile
openat(AT_FDCWD, "/run/systemd/sessions/", O_RDONLY|O_NONBLOCK|O_CLOEXEC|O_DIRECTORY) = 3
openat(AT_FDCWD, "/run/systemd/sessions/1", O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD, "/run/systemd/sessions/1", O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD, "/run/systemd/sessions/2", O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD, "/run/systemd/sessions/2", O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD, "/run/systemd/sessions/6", O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD, "/run/systemd/sessions/6", O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD, "/run/systemd/sessions/7", O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD, "/run/systemd/sessions/7", O_RDONLY|O_CLOEXEC) = 3
[root@vbox vtian]# loginctl list-sessions
SESSION  UID USER  SEAT  LEADER CLASS         TTY   IDLE SINCE
      1    0 root  seat0 1249   user-early    tty1  no   -    
      2    0 root  -     1799   manager-early -     no   -    
      6 1000 vtian -     2033   user          pts/0 no   -    
      7 1000 vtian -     2041   manager       -     no   -
I know that this is a failed strace, as if it were successful, there would be an instruction like this after openat(AT_..., ../sessions/7" ...), as this is what it looks like when writing successfully to root tty1
openat(AT_FDCWD, "/run/systemd/sessions/1", O_RDONLY|O_CLOEXEC) = 3
...
newfstatat(AT_FDCWD, "/dev/tty1", {st_mode=S_IFCHR|0620, st_rdev=makedev(0x4, 0x1), ...}, 0) = 0
...
openat(AT_FDCWD, "/dev/tty1", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 3
...
In addition, I don't really know why /dev/pts/0 is invoked here when i'm writing to /dev/tty1
execve("/usr/bin/write", ["write", "root", "/dev/tty1"], 0x7ffc4f216350 /* 30 vars */) = 0
...
ioctl(0, TCGETS, {c_iflag=ICRNL|IXON|IUTF8, c_oflag=NL0|CR0|TAB0|BS0|VT0|FF0|OPOST|ONLCR, c_cflag=B38400|CS8|CREAD, c_lflag=ISIG|ICANON|ECHO|ECHOE|ECHOK|IEXTEN|ECHOCTL|ECHOKE, ...}) = 0
ioctl(0, TCGETS, {c_iflag=ICRNL|IXON|IUTF8, c_oflag=NL0|CR0|TAB0|BS0|VT0|FF0|OPOST|ONLCR, c_cflag=B38400|CS8|CREAD, c_lflag=ISIG|ICANON|ECHO|ECHOE|ECHOK|IEXTEN|ECHOCTL|ECHOKE, ...}) = 0
ioctl(0, TCGETS, {c_iflag=ICRNL|IXON|IUTF8, c_oflag=NL0|CR0|TAB0|BS0|VT0|FF0|OPOST|ONLCR, c_cflag=B38400|CS8|CREAD, c_lflag=ISIG|ICANON|ECHO|ECHOE|ECHOK|IEXTEN|ECHOCTL|ECHOKE, ...}) = 0
fstat(0, {st_mode=S_IFCHR|0620, st_rdev=makedev(0x88, 0), ...}) = 0
readlink("/proc/self/fd/0", "/dev/pts/0", 4095) = 10
newfstatat(AT_FDCWD, "/dev/pts/0", {st_mode=S_IFCHR|0620, st_rdev=makedev(0x88, 0), ...}, 0) = 0
newfstatat(AT_FDCWD, "/dev/pts/0", {st_mode=S_IFCHR|0620, st_rdev=makedev(0x88, 0), ...}, 0) = 0
getuid()                                = 0
getuid()                                = 0
...
```
Asked by Vesta Tian (81 rep)
Jun 20, 2025, 02:47 PM
Last activity: Jun 24, 2025, 01:06 PM