0

I have 2 users and their distinct ssh keys, and a ssh server only accepting keys

  • user_1: a normal account with ssh and sftp accesses. Trusted. It can escape its home and download anything it can read.
  • user_2: an account with sftp access only, chrooted to a directory. NOT trusted.

If user_2 connects via sftp with its own key but user_1 username, it ends up in user_1 home, and can roam anywhere from there.

How can I ensure any connections done with user_2 key will be chrooted ? Or link usernames and authorized_keys files to prevent users from borrowing others usernames ?

Match User user_2 ForceCommand internal-sftp ChrootDirectory /data2 AuthorizedKeysFile /data2/.ssh/authorized_keys 

Edit: Adding connection examples. Both connections use the same key. Only the username changes.

# User name = user_2 admin@laptop:~$ sftp -P 12345 -i ~/.ssh/user_2_id_ed25519 [email protected] Connected to myserver.com. sftp> pwd Remote working directory: / sftp> ls lost+found upload sftp> quit # User name = user_1 admin@laptop:~$ sftp -P 12345 -i ~/.ssh/user_2_id_ed25519 [email protected] Connected to myserver.com. sftp> pwd Remote working directory: /home/user_1 sftp> ls Documents Maildir Repository sftp> quit 

Edit 2: Each user has its own key pair. I made a mistake while testing this locally and did not change the key used as shown above. Yet I was able to connect

root@myserver:# cat /data2/.ssh/authorized_keys ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIDQl+BIxhxKSGBTIQlwViAJ/<redacted> user_2@laptop --> user_2@myserver root@myserver:# root@myserver:# cat /home/user_1/.ssh/authorized_keys ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIN2fc8bLk0+DD+qY0W/8UyMT3onybgey/<redacted> user_1@laptop --> user_1@myserver root@myserver:# 
2
  • Probably wrong access set to the home directories under /home . Commented Nov 4 at 17:30
  • thanks for the edit! As said thrice now, you must have configured user_1 to use the centralized AuthorizedKeysFile as user_2. Commented Nov 4 at 17:52

1 Answer 1

0

If user_2 connects via sftp with its own key but user_1 username,

That can't happen. Keys don't work for other users.

Or link usernames and authorized_keys files to prevent users from borrowing others usernames ?

that's how it is. Nothing needs to be done; user_2's key can't be used to authenticate as user_1, and vice versa.

5
  • I can connect 2 different users with the same key though. Please have a look at the edited post Commented Nov 4 at 17:20
  • It seems you're doing a very questionable thing: instead of using per-user authorized_keys files, you have one for multiple users?? why?? That's really going against the whole point of having public keys? I'm not sure in which situation you would ever want this, so I guess this is a mistake. Give each user their own authorized_keys files, which is the default. So, simplest solution: remove the AuthorizedKeysFile directive alltogether, or use a different file for each user. Commented Nov 4 at 17:22
  • Each user has its own key. But during testing, I made a mistake and did not change the key while changing the username, resulting in the observation above. I'll add another edit Commented Nov 4 at 17:47
  • 1
    as said, you seem to be using one central AuthorizedKeys file, so that really seems to be the problem. Commented Nov 4 at 17:49
  • Cheers. I'll look in that direction Commented Nov 4 at 17:52

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.