3

I have a debian VM, here the info:

las@Client:~$ cat /etc/os-release 
PRETTY_NAME="Debian GNU/Linux 8 (jessie)"
NAME="Debian GNU/Linux"
VERSION_ID="8"
VERSION="8 (jessie)"

When I type ss -nte I expect to see the uid of the process that uses the socket because of the -e option, but it doesn't appear and I can't figure it out why. Here's the output:

las@Client:~$ ss -nte
State       Recv-Q Send-Q                    Local Address:Port                      Peer Address:Port 
ESTAB       0      176                      192.168.56.201:22                        192.168.56.1:50468  timer:(on,204ms,0) ino:12286 sk:ffff88000e7f3140 <->

How can I solve this?

Jeff Schaller
  • 66,199
  • 35
  • 114
  • 250
Francesco
  • 808
  • 7
  • 24

1 Answers1

4

The ss command (any version) will display an uid only if it's not zero. Here's the source for the Debian 8 jessie version:

    if (show_details) {
        if (s.uid)
            printf(" uid:%u", (unsigned)s.uid);
        printf(" ino:%u", s.ino);
        printf(" sk:%llx", s.sk);
        if (opt[0])
            printf(" opt:\"%s\"", opt);
    }

The test if (s.uid) makes it not display the information each time the socket owner's uid value is 0.

Additional tests (but using kernel 5.6 and a matching ss from iproute2 5.6.0), show that indeed a normal user can know the owner's uid of an other socket even if not owned by itself. So the absence of the uid: entry can mean only two things: owned by the root user, or owned by the kernel (which is different, but can't be distinguished here).

In your case, as the sshd daemon is running as root, all TCP sockets related to it will be owned by root, even if sshd grants a non-root login. The user login granted by sshd is not connected to any TCP socket: it's connected to the sshd daemon (or a separate instance of it) through master/slave PTYs or else with pipes. So ss can't be used to match a TCP connection to a user locally logged in through incoming ssh.

A.B
  • 31,762
  • 2
  • 62
  • 101
  • 1
    To add a minor detail that I hope won't lower explanation: the sshd process parent to the login shell or command does belong to the user and does have the TCP socket. But it's a duplicate copy of the original socket (still opened by the root sshd process parent to this sshd), with same pseudo-filesystem *sockfs*'s inode, which was initially opened as uid 0. – A.B May 03 '20 at 15:24