feat: add ssh key table #1515
feat: add ssh key table #1515
Conversation
| created_at TIMESTAMP WITH TIME ZONE DEFAULT NOW(), | ||
| updated_at TIMESTAMP WITH TIME ZONE, | ||
| public_key BYTEA NOT NULL, | ||
| key_comment VARCHAR(255), |
There was a problem hiding this comment.
why 255? is there a hard limit?
There was a problem hiding this comment.
It's just a reasonable limit imo
There was a problem hiding this comment.
255 bytes should be enough for everybody ;)
| created_at TIMESTAMP WITH TIME ZONE DEFAULT NOW(), | ||
| updated_at TIMESTAMP WITH TIME ZONE, | ||
| public_key BYTEA NOT NULL, | ||
| key_comment VARCHAR(255), |
There was a problem hiding this comment.
255 bytes should be enough for everybody ;)
| id SERIAL PRIMARY KEY, | ||
| created_at TIMESTAMP WITH TIME ZONE DEFAULT NOW(), | ||
| updated_at TIMESTAMP WITH TIME ZONE, | ||
| public_key BYTEA NOT NULL, |
There was a problem hiding this comment.
i think juju displays hexadecimal md5 key signature when you run juju ssh-keys so i'm wondering if it would be worth storing that as well so that we can do the lookup
There was a problem hiding this comment.
Yes I was thinking about that too, but I don't expect users to have too many keys so we can just compute them from the public key
There was a problem hiding this comment.
but if it would enable us to do the lookup based on key fingerprint without requiring the user to specify the username explicitly..
There was a problem hiding this comment.
But I believe it would be incorrect to query the keys without the user specifying a username. It's a bit contrived but imagine I gave you my SSH key pair (or in the incredibly slim chance you happen to generate the same key). You could also upload the public key to the controller and then on login there are 2 keys that match.
It's the same principle as basic auth but without requiring a username. I don't know what the guarantees around uniqueness of SSH keys are (how long they are, their entropy, etc) but I'm fairly confident it would be wrong to query for keys without the "username" of the user attempting to login.
Description
This PR adds a database migration and gorm model for users' public SSH keys. I reviewed #1287 when making this PR
Some justifications for the types chosen:
byteaovertextfor the SSH public key. The Go ssh package has aPublicKeyinterface with aMarshalmethod returning a []byte. I expect this is what we will store in the database. The marshalled object also stores the key type.Fixes JUJU-7348
Engineering checklist