Score:2

Ubuntu

I am seeing something strange running the w command and need help understanding it

Jaquarh

12/13/22, 12:16 AM

So I was checking around the server after a while of not looking on it and ran the w command:

 01:10:46 up 11 days,  2:53,  2 users,  load average: 0.00, 0.05, 0.05
USER     TTY      FROM             LOGIN@   IDLE   JCPU   PCPU WHAT
root     tty1     -                Tue21    2days  0.74s  0.60s -bash
root     pts/0    86.x.xxx.xx      22:18    0.00s  0.28s  0.00s w

I should be the only one on the server, and had no clue what this tty1 was or is doing so I ran ps -aef --forest | grep bash and found this one in particular

root         617       1  0 Aug01 tty1     00:00:00 /bin/login -p --

When I ran a kill -9 617 and checked w it had gone:

 01:11:18 up 11 days,  2:54,  1 user,  load average: 0.12, 0.07, 0.06
USER     TTY      FROM             LOGIN@   IDLE   JCPU   PCPU WHAT
root     pts/0    86.x.xxx.xx      22:18    5.00s  0.29s  0.00s w

What is that? I Googled what /bin/login -p -- was but only got information about the --. How was there a root logged in?

2 + 1

security

bash

Jaquarh

12/13/22, 11:24 AM

Ubuntu 20.04 with Docker and Docker Compose installed, that is all that runs on it @guiverc

Score:1

Ubuntu

terdon

12/14/22, 2:16 PM

One worrying possibility is that someone logged in as root. I can reproduce something very similar on my machine. First, I enabled root ssh access by adding this to /etc/ssh/sshd_config:

PermitRootLogin yes

And then restarted the sshd service:

sudo service sshd restart

And logged in as root (note that I have enabled the root account on this machine, have you done the same?):

ssh root@localhost

Now, when I run w, I see:

$ w
 17:06:36 up 3 min,  2 users,  load average: 1.98, 0.97, 0.38
USER     TTY        LOGIN@   IDLE   JCPU   PCPU WHAT
terdon   :0        17:04   ?xdm?  29.31s  0.01s /usr/lib/gdm-x-s
root     pts/3     17:06   24.00s  0.00s  0.00s -bash

At the very least, you cannot rule out the possibility that an attacker gained access to your system. The only solution, in that case, is to restore from a backup or reinstall from scratch. If someone did get root access, there is simply no way of being sure they haven't done something bad otherwise.

0 + 7

Jaquarh

12/14/22, 2:37 PM

Would it effect if I only have RSA keys for login and not password? Also, when I login via ssh I see `pts/<number>` too. But I saw `-` instead

terdon

12/14/22, 2:38 PM

@Jaquarh I don't really know. I am not an expert on security at all. All I can tell you is that by doing what I described above an logging in as root, I saw something very similar.

Jaquarh

12/14/22, 2:39 PM

So, I've not seen it since I killed it and I'm recently wondering if it could of been my `KVM` that never actually killed its connection - I might try reproduce using my KVM

terdon

12/14/22, 2:48 PM

@Jaquarh yes, please don't take my answer as any kind of authoritative proof that your machine was compromised. All I can say is that it _could_ be _one_ explanation. I don't have the knowledge to say for sure, and you know what the machine was doing.

Jaquarh

12/14/22, 2:48 PM

ok yeah! this is infact the cause, I logged in via my OVH panel and used the KVM -- after logging in I see `root tty1 - 15:47 42.00s 0.20s 0.07s -bash` I now close out the browser and it stays active - I guess the KVM never closes its login connection for some reason in OVH hosted servers. Your post helped me see this thanks!

terdon

12/14/22, 2:49 PM

ah, great news! Could you please post that as an answer and accept it, so that the next person with a similar problem can see it?

Jaquarh

12/14/22, 2:49 PM

Sure, but I'll keep my upvote on yours because your explanation helped me see it! Thanks Terdon!

Score:0

Ubuntu

Jaquarh

12/14/22, 3:01 PM

After thinking about @Terdons answer, and for future viewers, I found the TTY is the screen it is attached to when in PTS/<number> and in my case, I was using my providers browser KVM which is tty1 (no screen, stay alive), and the issue was killing the browser did not kill the KVM connection internally on the server.

If ran watch w and logged back into the root server via my KVM (internal access doesn't require the RSA key) I saw:

 15:51:54 up 12 days, 17:34,  2 users,  load average: 0.04, 0.05, 0.08
USER     TTY      FROM             LOGIN@   IDLE   JCPU   PCPU WHAT
root     tty1     -                15:47    4:33   0.20s  0.07s -bash
root     pts/0    xxxxxxxxxx      15:38    4:49   0.26s  0.00s watch w

Bingo. If no FROM address is stated (-), it is a physical login from the server.

To kill it I did:

$ ps -aef --forest | grep tty1

root     2355734       1  0 Aug13 tty1     00:00:00 /bin/login -p --
root     2687566 2355734  0 15:47 tty1     00:00:00  \_ -bash
root     2688963 2686083  0 15:54 pts/0    00:00:00          \_ grep --color=auto tty1

$ kill -9 2355734
$ w

 15:55:00 up 12 days, 17:37,  1 user,  load average: 0.03, 0.03, 0.06
USER     TTY      FROM             LOGIN@   IDLE   JCPU   PCPU WHAT
root     pts/0    xxxxxxxxx      15:38    4.00s  0.08s  0.01s w

0 + 0

Elon Musk

I sit in a Tesla and translated this thread with Ai:

EN: I am seeing something strange running the w command and need help understanding it

TH: ฉันเห็นบางสิ่งที่แปลกประหลาดในการเรียกใช้คำสั่ง w และต้องการความช่วยเหลือในการทำความเข้าใจ

RO: Văd ceva ciudat rulând comanda w și am nevoie de ajutor pentru a o înțelege

RU: Я вижу что-то странное при выполнении команды w, и мне нужна помощь, чтобы понять это.

VI: Tôi thấy điều gì đó lạ khi chạy lệnh w và cần trợ giúp để hiểu nó

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.