How to protect identity on systems that share access to root #393
-
|
My somewhat limited knowledge makes me wonder how to use the id_ecdsa key in an environment where a team has shared root access? I did try ssh-keygen -p -f id_ecdsa but it doesn't prompt me for the password. Is there a method to put a password on the opkssh generated private key? |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment 2 replies
-
|
Do I understand your question correct? The SSH client is running on a system in which multiple people have root access and you wish to protect the generated SSH keys? In general credentials can not be protected against an attacker that has root. An attacker with root could modify the tool you use to encrypt the credentials and either leak the credential or the password to the attacker. Alternatively an attacker with root could modify SSH to steal your credential when SSH sees it. The best you can to is limit your window of exposure. By default opkssh SSH keys expire after 24 hours, limiting the window of exposure. If you want a much shorter window of exposure, I'd suggest writing a script that wraps SSH, so it automatically calls I'd also look into opkssh-renewer, which lets you set very short expiry times for opkssh keys and then has a process that renews automatically renews them. You could set this up so that as soon as you logout, it kills this process and deletes your opkssh keys. I haven't had time to add ssh-agent support to opkssh, but if with ssh-agent you can use a password to store all the ssh keys you store in ssh-agent. That is the cleanest long term solution. |
Beta Was this translation helpful? Give feedback.
-
|
Yes - you do have the correct gist of the question. And I appreciate the response. The environment is government so there is audit and an overarching security principle that elevation to a privileged account be visible in terms of the individual account. Clearly root does have the opportunity to overcome this, so I am probably seeking some mitigations that could be put in place - which is possibly only deluding myself. However, the separation of access between windows and linux, means that linux admins when using a windows jump host do not have admin/root (only on linux systems). Thanks for the reference to opkssh-renewer. I'm sure you are quite busy but enabling a password on the generated key supplied by the user wouldn't hurt. |
Beta Was this translation helpful? Give feedback.
-
|
Would SSH-agent's password protections met your requirements? OPKSSH doesn't currently support SSH agent, but it is on the near term roadmap. |
Beta Was this translation helpful? Give feedback.
Do I understand your question correct? The SSH client is running on a system in which multiple people have root access and you wish to protect the generated SSH keys?
In general credentials can not be protected against an attacker that has root. An attacker with root could modify the tool you use to encrypt the credentials and either leak the credential or the password to the attacker. Alternatively an attacker with root could modify SSH to steal your credential when SSH sees it. The best you can to is limit your window of exposure.
By default opkssh SSH keys expire after 24 hours, limiting the window of exposure.
If you want a much shorter window of exposure, I'd suggest writing a script…