I added a VITE_ENABLE_SSH_KEYS feature toggle, and enabled both this and VITE_ENABLE_TASKS in the CI build. I also modified the implementation to do as little as possible with ~/.ssh.

@mkitti As discussed, we agree about "treating .ssh as read-only as much as possible". To minimize complexity and because for now this feature has a very small user base, I've modified the GUI to do the most minimal thing possible to ~/.ssh, namely: if id_ed25519 does not exist, this tool can create one for you and add it to authorized_keys using cat. I've removed functionality around managing multiple keys, and all functionality that deletes keys. This minimizes risks to user's existing SSH keys and setups.

In a few places we still read the private key into resident memory of the Python process as an immutable Python string. This is not good. Core dumps of the Python process may contain the contents of the private key.

Rather than loading file contents into an immutable string, we should read the contents into a mutable bytearray and then explicitly overwrite the contents of the bytearray when the contents are no longer needed.

import os

key_path = "private_key.pem"
file_size = os.path.getsize(key_path)

# 1. Pre-allocate mutable memory
sensitive_data = bytearray(file_size)

# 2. Read directly into the pre-allocated buffer
with open(key_path, "rb") as f:
    f.readinto(sensitive_data)

# Use the bytes as needed

# 3. Securely overwrite the memory with zeros
for i in range(len(sensitive_data)):
    sensitive_data[i] = 0

# 4. Now safe to remove the reference
del sensitive_data

References:

1. https://stackoverflow.com/questions/728164/securely-erasing-password-in-memory-python#:~:text=The%20correct%20solution%20is%20to,bytearray%22%20instead%20of%20python%20strings.
2. https://softwareengineering.stackexchange.com/questions/270113/using-a-bytearray-rather-than-a-string-to-store-password-in-memory#:~:text=Using%20a%20bytearray%20datatype%20to,in%20python%203.4%20using%20bytearray?

Consider using a bytearray and perhaps a context manager to minimize time that a private key spends in resident memory of the Python process.

Great ideas, @mkitti. However, this level of security is not priority given that we are running this on our private network and on a server accessible only by a few administrators. I'll add it to our backlog in case anyone has time to revisit it later.

If I understand correctly, the exclusive user of the private key should be Seqera alone. The private key does not need to be used by the user for any other purpose. Why do we need to store the private or public key to disk at all other than adding it to the authorized_keys file?

Rather we only need to transiently show the private key to the user via the web interface to copy into Seqera. If they fail to do so, then we just generate another private key anew the next time.

That process would work more like how Github personal access tokens work. Take a look at how the user interface works for tokens.

If you push the "Generate a new token" button and fill out the form, it will show you the token once in this example (I deleted the key before posting the screenshot):

It warns that you will not be able to see the personal access token again. Similarly, we can issue the same warning when showing the user the private key for Seqera. If they lose the key, we can just generate another private key.

In summary, there is no need to write the private key to ~/.ssh/id_ed25519 or the public key to ~/.ssh/id_ed25519.pub. Rather we can generate the private key and the public key at some temporary file location or just just store it transiently in memory. All we need to do is add the public key to the ~/.ssh/authorized_keys file, preferably with restrictions and a comment, and show the private key to the user once via the web interface. The private key never needs to be seen again.