2

For instance, if one wants to access the account bob on a machine on a local network behind a router, they would simply type:

$ ssh -p xx bob@example.com`

However, how does ssh handle the possibility of two machines on the local network having the same username? Is there a flag to differentiate between user bob on machine A vs a different user bob on machine B, or does ssh throw an error?

  • 3
    The example.com host part would be different, no? – Jeff Schaller Jul 20 '18 at 20:39
  • 4
    ... or perhaps the port would be different, if you are forwarding to multiple hosts across a single NAT – steeldriver Jul 20 '18 at 20:44
  • 10
    I think there's a fundamental misunderstanding here: ssh never uses the username to decide which computer to connect to. It simply connects to a specified destination IP address (maybe specified via a name) and TCP port number; that might get redirected by a NAT router to a local computer, but if so that's done based on the IP and port numbers, not the username. – Gordon Davisson Jul 20 '18 at 23:53
  • The same username on different servers, or different clients, doesn't matter. However, if the username is the same on the client and server (for one connection), ssh can default it: e.g. if you are logged-in to this as alice, then ssh that (no user@) attempts to connect to that and log in as alice there. (And the same for scp and sftp, which use ssh, and sometimes other things like rsync and git etc.) – dave_thompson_085 Jul 21 '18 at 12:33
17

Why would ssh care about reiterating usernames on different hosts? It is absolutely expected that this will happen. Hint: the root user is omnipresent, is it not?

So the answer to your questions is: ssh handles it the same way everything else would handle it: by not caring about which user is being referenced until talking to the host in question.

A simplified expansion on the above:

The first thing that happens is that the ssh client attempts to establish a conversation with the remote ssh server. Once a communications channel is opened, the client looks to see if it's a known host (e. g. an entry is present in ~/.ssh/known_hosts), and handle things properly if it's either an unknown host or a known host with invalid credentials (e. g. the host key had changed).

Now that all that is out of the way and a line of communication is properly open between the ssh server and client, the client will say to the server "I would like to authenticate for the user bob". Naturally, the server won't care about any other bobs on the network; only itself.

4

I think Gordon Davisson's comment correctly identifies your misunderstanding:

I think there's a fundamental misunderstanding here: ssh never uses the username to decide which computer to connect to. It simply connects to a specified destination IP address (maybe specified via a name) and TCP port number; that might get redirected by a NAT router to a local computer, but if so that's done based on the IP and port numbers, not the username.

And this is 100% true for standard installations of SSH: if you connect to bob@example.com, it will not go looking at any other hosts for the username.

However, it is possible that example.com can redirect the connection to another computer. I have sometimes seen systems that allow ssh to connect first, and then redirect based on the username. However, this is not standard SSH behaviour, and the target will depend completely on the redirection rules set on the server.

  • Of course, this assumes that the destination is observing standard layering. Some systems don't, so you could have (for example) the TCP/IP stack doing deep packet inspection and rerouting your SSH connection based on the user. But that's an extremely uncommon setup. – Kevin Jul 21 '18 at 16:53
2

Regarding your actual question:

However, how does ssh handle the possibility of two machines on the local network having the same username? Is there a flag to differentiate between user bob on machine A vs a different user bob on machine B, or does ssh throw an error?

Every Linux system, by default, manages its own users, groups & passwords locally in 3 files.

  • /etc/password

    $ head -4 /etc/passwd
    root:x:0:0:root:/root:/bin/bash
    bin:x:1:1:bin:/bin:/sbin/nologin
    daemon:x:2:2:daemon:/sbin:/sbin/nologin
    user1:x:1001:1001::/home/user1:/bin/bash
    
  • /etc/shadow

    $ head -4 /etc/shadow
    root:$1$jmJYUghS$AxysSW9MzG6AmmweysZsi1::0:99999:7:::
    bin:*:17110:0:99999:7:::
    daemon:*:17110:0:99999:7:::
    user1:!!:17717:0:99999:7:::
    
  • /etc/group

    $ head -4 /etc/group
    root:x:0:
    bin:x:1:
    daemon:x:2:
    user1:x:1001:
    

Within these files are actual numbers. You can see them on this line from the /etc/password file:

    user1:x:1001:1001::/home/user1:/bin/bash

Which equates to the user ID (UID) & group ID (GID) of 1001 & 1001. If we were to list the home directory of this user1, you'll see these same numbers there as well:

$ ls -lnd /home/user1
drwx------ 4 1001 1001 4096 Jul 12 00:05 /home/user1

NOTE: In the above command we're instructing ls to display number's it defaults to display names otherwise:

$ ls -ld /home/user1
drwx------ 4 user1 user1 4096 Jul 12 00:05 /home/user1

What about SSH

When you ssh to another server and you include the user to log in as:

$ ssh user1@server1.mydom.com

you're authenticating against that server's locally stored "details" about a given user. With SSH it's a bit more complicated since you'll typically be using a private/public key pair to log into a server via ssh.

example key pair files
$ ls -l ~/.ssh/id_rsa*
-rw------- 1 root root 1675 Jul 21 00:50 /root/.ssh/id_rsa
-rw-r--r-- 1 root root  394 Jul 21 00:50 /root/.ssh/id_rsa.pub

In this scenario when you ssh, you're sending "secrets" to the remote server, using your user's private portion of the SSH key pair, on the server is the public portion of the key pair, which the server can use to confirm that you are in fact who you say you are.

Here, for example is your private key portion:

my laptop
$ ssh-keygen -l -f ~/.ssh/id_rsa
2048 SHA256:HvNN38AS9H7tIHaaE+51lqv6bgL7AmyDdqHIZIyBimg root@centos7 (RSA)

If we look to a client where this user is able to ssh into using a key pair:

remote server X
$ ssh-keygen -l -f ~user1/.ssh/authorized_keys
2048 SHA256:HvNN38AS9H7tIHaaE+51lqv6bgL7AmyDdqHIZIyBimg root@centos7 (RSA) 

Notice the keys match.

  • Please say that's not your real hash... – wizzwizz4 Jul 21 '18 at 8:06
  • @wizzwizz4 - come on, you have to ask? I've only been doing this for like 20+ yrs. Jeesh! 8-) – slm Jul 21 '18 at 14:25

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.