Authorization process is not atomic

[dahlia]

The current way to modify .ssh/authorized_keys list is only half atomic. When add public keys to the list it's open()ed with append mode, but when remove public keys from it the whole file is removed and created again. The later process can be failed immediately after the file is removed but not created again yet.

[achimnol]

Maybe we could use file renaming when removing public keys.

• Step 1: Create a new temporary file containing only the geofront-master key.
• Step 2: fsync() to flush the file content.
• Step 3: Rename it to become the authorized_keys file. (The original file is overwritten)

However, this still does not gaurantee atomicity of each authorization request when there are multiple overlapped authorization requests to a single destination server.
If I understand correctly about the current assumption: low concurrency of Geofront users ("for small-scale teams"), such case is simple ignored right now, isn't it?

[dahlia]

Maybe we could use file renaming when removing public keys.

Seems the most feasible idea for the moment.

If I understand correctly about the current assumption: low concurrency of Geofront users ("for small-scale teams"), such case is simple ignored right now, isn't it?

Yes, although the assumption is merely for the sake of convenience. It would be better if we have a solution for that which is not that complicated.

[achimnol]

I realized that GCE pre-populates project-global user SSH keypairs automatically into instances (this may be disabled as an option when creating an instance though) -- so simply overwriting the authorized_keys file with the Geofront master key only may confuse GCE users.
So we need to keep the original content if authorized_keys has non-Geofront keypairs.

[dahlia]

Although it was deprecated more than a decade ago, OpenSSH server still recognizes authorized_keys2 as well.