Timeline for How do I stop a sftp-chrooted user from escaping by changing its username?
Current License: CC BY-SA 4.0
6 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Nov 4 at 17:52 | comment | added | Sandrew Cheru | Cheers. I'll look in that direction | |
| Nov 4 at 17:49 | comment | added | Marcus Müller | as said, you seem to be using one central AuthorizedKeys file, so that really seems to be the problem. | |
| Nov 4 at 17:47 | comment | added | Sandrew Cheru | 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 | |
| Nov 4 at 17:22 | comment | added | Marcus Müller | 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. | |
| Nov 4 at 17:20 | comment | added | Sandrew Cheru | I can connect 2 different users with the same key though. Please have a look at the edited post | |
| Nov 4 at 16:34 | history | answered | Marcus Müller | CC BY-SA 4.0 |