Skip to content
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

Merged
merged 2 commits into from
Jan 10, 2025
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
14 changes: 14 additions & 0 deletions internal/dbmodel/sql/postgres/020_add_ssh_keys_table.up.sql
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,
Copy link
Collaborator

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 lookup

Copy link
Contributor Author

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

Copy link
Collaborator

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..

Copy link
Contributor Author

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.

key_comment VARCHAR(255),
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why 255? is there a hard limit?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's just a reasonable limit imo

Copy link
Collaborator

Choose a reason for hiding this comment

The 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
23 changes: 23 additions & 0 deletions internal/dbmodel/sshkeys.go
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
}
35 changes: 35 additions & 0 deletions internal/dbmodel/sshkeys_test.go
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\".*")
}
Loading