-
Notifications
You must be signed in to change notification settings - Fork 8
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: add ssh key table #1515
feat: add ssh key table #1515
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,14 @@ | ||
-- Add the ability to store users' SSH public keys | ||
|
||
CREATE TABLE ssh_keys ( | ||
id SERIAL PRIMARY KEY, | ||
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. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. why 255? is there a hard limit? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. It's just a reasonable limit imo There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. 255 bytes should be enough for everybody ;) |
||
identity_name TEXT NOT NULL, | ||
FOREIGN KEY (identity_name) REFERENCES identities(name), | ||
CONSTRAINT unique_identity_ssh_key UNIQUE(identity_name, public_key) | ||
); | ||
|
||
CREATE INDEX idx_ssh_keys_user_id ON ssh_keys (identity_name); | ||
kian99 marked this conversation as resolved.
Show resolved
Hide resolved
|
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,23 @@ | ||
// Copyright 2025 Canonical. | ||
|
||
package dbmodel | ||
|
||
import "time" | ||
|
||
// SSHKey holds a user's public SSH key. | ||
type SSHKey struct { | ||
// Note this doesn't use the standard gorm.Model to avoid soft-deletes. | ||
|
||
ID uint `gorm:"primarykey"` | ||
CreatedAt time.Time | ||
UpdatedAt time.Time | ||
|
||
// IdentityName is the unique name (email or client-id) of this entity. | ||
IdentityName string `gorm:"uniqueIndex:unique_identity_ssh_key"` | ||
Identity Identity `gorm:"foreignKey:IdentityName;references:Name"` | ||
|
||
// PublicKey holds the user's public SSH key. | ||
PublicKey []byte `gorm:"uniqueIndex:unique_identity_ssh_key"` | ||
// KeyComment holds a user provided comment. | ||
KeyComment string | ||
} |
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,35 @@ | ||
// Copyright 2025 Canonical. | ||
|
||
package dbmodel_test | ||
|
||
import ( | ||
"testing" | ||
|
||
qt "github.com/frankban/quicktest" | ||
|
||
"github.com/canonical/jimm/v3/internal/dbmodel" | ||
) | ||
|
||
func TestSSHKeyUniqueConstraint(t *testing.T) { | ||
c := qt.New(t) | ||
db := gormDB(c) | ||
|
||
u, err := dbmodel.NewIdentity("bob@canonical.com") | ||
c.Assert(err, qt.IsNil) | ||
|
||
c.Assert(db.Create(u).Error, qt.IsNil) | ||
|
||
key := dbmodel.SSHKey{ | ||
PublicKey: []byte("test"), | ||
Identity: *u, | ||
KeyComment: "foo", | ||
} | ||
c.Assert(db.Create(&key).Error, qt.IsNil) | ||
|
||
newKey := dbmodel.SSHKey{ | ||
PublicKey: []byte("test"), | ||
Identity: *u, | ||
KeyComment: "bar", | ||
} | ||
c.Assert(db.Create(&newKey).Error, qt.ErrorMatches, ".*duplicate key value violates unique constraint \"unique_identity_ssh_key\".*") | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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 lookupThere was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.