Get current ssh session's originating IP without being superuser

Question

I am trying to find out the current ssh session's originating IP address. I found the following to be useful, but it requires sudo:

$ sudo netstat -tapen | grep ssh | awk '{ print $5}' | sed '/0.0.0.0\|::/d'
192.168.1.1:60119
99.xxx.xxx.xxx:1213

Is there a way to get the 99.xxx.xxx.xxx information without a call to sudo?

(Answered! Question #1: How is it that piping to grep returns only the error?)

Question #2: Are there workarounds for getting WAN information with netstat? or...

Question #3: Are there better options for my goal?

Answer 1

You can use the SSH_CONNECTION and SSH_CLIENT variables:

$ echo $SSH_CONNECTION 
10.0.0.1 42276 10.0.0.2 22
$ echo $SSH_CLIENT    
10.0.0.1 42276 22
$ SSH_IP=${SSH_CONNECTION%% *}
$ echo $SSH_IP
10.0.0.1

From man 1 ssh:

 SSH_CONNECTION        Identifies the client and server ends of the
                       connection.  The variable contains four space-
                       separated values: client IP address, client port
                       number, server IP address, and server port number.

You can access each entry in SSH_CONNECTION more easily if you split it into a bash array:

ssh_details=($SSH_CONNECTION)

Then you can get each entry using its index:

$ echo $SSH_CONNECTION 
127.0.0.1 55719 127.0.0.1 22
$ ssh_details=($SSH_CONNECTION)
$ echo ${ssh_details[0]}
127.0.0.1
$ echo ${ssh_details[1]}
55719
$ printf "You are logging in from host IP %s from port # %d\n" ${ssh_details[0]} ${ssh_details[1]}
You are logging in from host IP 127.0.0.1 from port # 55719

For some reason, SSH_CLIENT is not documented in the English manpages.

Answer 2

Answer to 1 & 2:

The warning is from netstat, not from grep and its about the PID/Program name column of the netstat output:

$ netstat -tapen
(Not all processes could be identified, non-owned process info
 will not be shown, you would have to be root to see it all.)
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       User       Inode       PID/Program name

Using sudo:

$ sudo netstat -tapen
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       User       Inode       PID/Program name

The alert is self explanatory, you have to be root to view the process IDs and program names owned by other (all) users, otherwise you will only get the PID/names of programs owned by you although you will get the open socket listings for those processes.

The distinction is basically summed up by the following, from man netstat:

   PID/Program name
       Slash-separated pair of the process id (PID) and process name of
the process that owns the socket.  --program causes this column  to
be  included. You will also need superuser privileges to see this  
information on sockets you don't own. This identification information is  
not yet available for IPX sockets.

In you case, the program sshd is owned by root, so without using sudo all the socket info will appear in the output, not the program name and PID. As a result while using grep on the result of netstat -taepn you are getting the warning.

On the other hand if you use sudo, the PID/program name will appear in the netstat -taepn output and you can use grep to find the output.

The following will make you more clear (check the last column(PID/Program name)):

$ netstat -tapen
                                                        PID/Program name
tcp  0  0 0.0.0.0:22  0.0.0.0:* LISTEN  0   11088       -               

$sudo netstat -taepn
tcp  0  0 0.0.0.0:22  0.0.0.0:* LISTEN  0   11088       1002/sshd       

If you are running this from a client machine then you can just ignore it as the process in that case will be ssh (not sshd) and will be owned by you.

Answer to 3:

There are so many ways. I will add a few:

$ sudo netstat -taepn | grep "ssh" | tr -s ' ' | cut -d' ' -f4 | head -1
192.168.5.3:22

$ sudo netstat -taepn | grep -Po "\b(\d|\.)+:22(?= .*ssh)"
192.168.5.3:22

$ sudo netstat -taepn | sed -nr '/ssh/s/.* ([^:]+:22) .*/\1/p'
192.168.5.3:22

EDIT: Without sudo:

$ netstat -taepn 2>/dev/null | grep ":22 " | tr -s ' ' | cut -d' ' -f4 | head -1
192.168.5.3:22

$ netstat -taepn 2>/dev/null | grep -Po "\b(\d|\.)+:22\b"
192.168.5.3:22

$ netstat -taepn 2>/dev/null | sed -nr '/:22 /s/.* ([^:]+:22) .*/\1/p'
192.168.5.3:22

EDIT 2:

If you want to get the remote IP address connected to port 22 (ssh) of the server without using sudo, your best best would be to read the socket statistics via ss command and get the desired output from that.

$ ss -ant | grep -Po "(\d|\.)+:22\s+\K[^:]+"
192.168.6.4

$ ss -ant | sed -nr 's/.*([0-9]|\.)+:22 +([^:]+).*/\2/p'
192.168.6.4

$ ss -ant | grep -e "ESTAB" | grep ":22" | tr -s ' ' | cut -d' ' -f5 | cut -d':' -f1
192.168.6.4

We have run the above commands in the server and 192.168.6.4 is the IP address of the remote computer connected to the server via ssh on port 22.

Answer 3

The line is bellogs to error output, i.e. sterr. You could get rid of it with

netstat -tapen 2> /dev/null | grep ssh

For reference check this

As properly noted by heemayl , without sudo, netstat won't report that connection is established by the ssh server, only if it's established by ssh client.

Of course, you can still determine it by port number or using who -a utility, which will show logins and address, but it's not a guarantee somebody isn't logged in via telnet or remote desktop application.

Answer 4

Before reading on to read the SSH_CLIENT answer (it was that simple you know), you could also do:

pid=$(ps -xh -o pid,cmd | grep [s]shd | awk '{print $1}' | head -1) 
cat /proc/$pid/net/tcp | while read a b c d e; do echo $b $c $d; done |
    tail -n +2 | grep " 01" | while read a b c; do echo $b; done |
    cut -d: -f1 | sed "s/../& /g" | while read d c b a; do
    printf "%d.%d.%d.%d\n" 0x$a 0x$b 0x$c 0x$d; done

Actually the process contains the connections for all clients, not just your own. It is basically the main SSHD process. I don't know why it runs under your user.