1 |
On 7/14/22 8:48 AM, Neil Bothwick wrote: |
2 |
> Is this user only used as a gateway to root access, or can you set |
3 |
> up such a user? If so you could use key-based authentication for |
4 |
> that user, with a passphrase, and add command="/bin/su --login" |
5 |
> to the authorized_keys line. That way you still need three pieces |
6 |
> of information, |
7 |
|
8 |
Be mindful that despite the fact that this protects things on the |
9 |
surface, it is / can be a way to boot strap changing this. |
10 |
|
11 |
After all, nothing about this forced command prevents the user from |
12 |
using the acquired root access to modify the ~/.ssh/authorized_keys file |
13 |
enforcing the command. |
14 |
|
15 |
This is one of the pitfalls that I alluded to in my earlier reply about |
16 |
security vs automation. Quite simply, this is NOT security as it's |
17 |
trivial to use the access (su -) to gain more access (edit the |
18 |
~/.ssh/authorized_keys file). |
19 |
|
20 |
> replacing the user's password with the user's key passphrase. |
21 |
|
22 |
This is another slippery slope. SSH key pass phrases can be brute |
23 |
forced in an offline fashion. Conversely, system passwords are more of |
24 |
an online attack. Assuming that standard system protections are in |
25 |
place for /etc/shadow*. -- It's easier to get a copy of someone's |
26 |
private SSH key file, especially if they are somewhat lax about it's |
27 |
security believing that the passphrase will protect it. |
28 |
|
29 |
|
30 |
|
31 |
-- |
32 |
Grant. . . . |
33 |
unix || die |