SSH actually requires you to configure different keys for different users.
Each user account on the destination machine has its own ~/.ssh/authorized_keys
(doesn't necessarily have to have, it might not exist).
Let's assume you have server
and client
.
server
has users set up as follows:
/home/srv_user01
/.ssh/authorized_keys
--> contains public key of cli_user01
and public key of cli_user03
/home/srv_user02
/.ssh/authorized_keys
--> empty or non-existing
/home/srv_user03
/.ssh/authorized_keys
--> contains public key of cli_user03
client
has three accounts cli_user01
, cli_user02
, and cli_user03
.
On client
machine:
cli_user01
can execute ssh srv_user01@server
and login to server
as srv_user01
cli_user02
cannot connect to server
at all
cli_user03
can execute:
ssh srv_user01@server
and login to server
as srv_user01
, or
ssh srv_user03@server
and login to server
as srv_user03
- no user can connect and login as
srv_user02
on server
In the example above I used different names on client and server side, but if account name was the same on client
and server
, user doesn't have to specify the account name in ssh
command, thus making the impression of "logging to server". So if I am logged on as user
on client and execute ssh server
ーit is the same as ssh user@server
.
On server
one sshd
process listens on port 22 (default) and receives connections from each of the connecting users.
~/.ssh/authorized_keys
(doesn't necessarily have to have, it might not exist). Onesshd
serves many users.~
in the path~/.ssh/authorized_keys
stands for/home/username/
.