Linux - GeneralThis Linux forum is for general Linux questions and discussion.
If it is Linux Related and doesn't seem to fit in any other forum then this is the place.

Notices

Welcome to LinuxQuestions.org, a friendly and active Linux Community.

You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!

Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.

If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.

Having a problem logging in? Please visit this page to clear all LQ-related cookies.

Introduction to Linux - A Hands on Guide

This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.

If you run the command you will see that you can determine that based upon the "FROM" and the "WHAT" if the "WHAT" has an sshd: you know they are ssh'ed. If the from is an external address you know they are accessing externally.

Actually, I just tried logging in remotely with ssh and the WHAT listed was "-bash." This sounds like it would be hard to pin down the exact algorithm for figuring out who was at the desktop. I don't mean to sound ungrateful, but is there anything else? For example, is there a way to examine the tty column and figure out which one(s) is/are, they physical desktop?

The what can be different based upon your sshd config but the FROM should be pretty obvious. You can dig into the actual proc files and look at the /var/log/secure and /var/log/audit/audit.log as these should be logging your external connections but I'm curious as to why the FROM isn't enough for you?

Actually, I just tried logging in remotely with ssh and the WHAT listed was "-bash." This sounds like it would be hard to pin down the exact algorithm for figuring out who was at the desktop. I don't mean to sound ungrateful, but is there anything else? For example, is there a way to examine the tty column and figure out which one(s) is/are, they physical desktop?

Thanks again.

How about the FROM column? Mine shows :0.0 or :0.1 for local, or the hostname that they SSHd in from for remote connections. You can also look at the TTY column, mine shows pts/# for most connections, and tty# for whoever is actually logged in locally.

The FROM column is totally optional (which is why it is blank in some cases). The convention is that it contains the remote host IP number where the connection is from.... But that can be masked.

A local login is always using a tty number. These are the virtual consoles (tty0-62), though none I have seen have ever created that many.

Attached serial devices (ttyS0/ttyS1 ...) might be considered local, but if they are attached to a dialup style modem, they aren't (and the FROM column will still be blank).

Network connections nearly always use pseudo terminals (the pts/nnn format), but it isn't necessary. Ssh has a login that doesn't use a tty... and therefore the who/w commands don't even show them.

Try "ssh remotehost w", give the password and see.

For an even more impressive example do "ssh remotehost sh". You don't usually see a prompt, but give the w command, and then try "tty" (you will get "not a tty" because what you have is a socket). This also applies to using scp - it is a login, but again, no tty is initialized.

BTW, you get the equivalent of "scp remote:file newfile" by doing "ssh remote cat file >newfile" but it is longer to type...

Another similar case -but looks odd, Do a "ssh -X remotehost xterm -ut". This assumes that the xterm utility is installed. This is the basic terminal emulator (using a pts/nnn device), and will/should show a terminal window that is logged in on the remote system. Do a who (or w) command in the window.
No utmp/wtmp entry is created at all - so you can't even see the login even with a terminal.

In these cases, you have a remote login... but no entry in the utmp/wtmp file, and thus, the who command cannot display anything about it.

I am still not sure from this discussion what the actual algorithm is. Using the FROM column or, if someone prefers, the TTY column, what is the exact algorithm to distinguish logins originating on the physical desktop machine?

You can assume that if the "who" command shows "tty<n>" that it is local.

But as I said, it is up to HOW the user logs in as whether that field is valid or even provided. It will not show active cron jobs being run by the user (it still counts as a login though, just no terminal). It will not show any detached background jobs either (same reason).

A lot of this depends on why you need to know. If you are getting ready to shutdown/reboot, then ps -fu is a better judge of activity if you want to avoid impacting a users work.

Thanks. I'll tell you why I need to know. For various operations initiated from a remote master terminal, such as VNCing into the local machine or re-booting it, I have to ask permission of somoene on that local machine. I have to pop up a box saying essentially, "We want to reboot your machine. Is this okay?" I feel that most of the time, there will be only 0-1 users. However, as a programmer, I have to consider the possibility that there might be several people logged in. If this is the case, then I want to ask the one who is actually sitting at the desktop.

Might be an issue with remote desktops... but that should affect servers more than a users workstation.

One thing - the "local" user of a workstation could be in a conference room and performing a remote display... A reboot at that time would not necessarily be a good thing even though he is using it remotely...