feat: add ability to check for multiple default ssh key locations by a-dubs · Pull Request #406 · canonical/pycloudlib

a-dubs · 2024-08-26T15:21:46Z

Since Ubuntu 24.04 LTS and newer, the default location for ssh keys is
~/.ssh/id_ed25519 instead of ~/.ssh/id_rsa. Thus, when no ssh key
path is specified, this commit changes pycloudlib to check for an
existing ssh key at either ~/.ssh/id_ed25519 or ~/.ssh/id_rsa.

Fixes GH #341

Testing of changes

Testing id_ed25519 can be found

made sure no key exists at ~/.ssh/id_rsa
created new key at ~/.ssh/id_ed25519
removed public_key_path and private_key_path from [oci] config in my pycloudlib.toml config file
ran the oracle example script: python3 examples/oracle.py
made sure the following line showed up in the log (was one of the first few lines logged):

INFO:pycloudlib.cloud.OCI:using SSH pubkey: /home/a-dubs/.ssh/id_ed25519.pub

Testing error is raised when neither default key is found

Removed keys at ~/.ssh/id_ed25519
ran the oracle example script: python3 examples/oracle.py
Ensured error stating the following was thrown:

pycloudlib.errors.PycloudlibError: No public key path provided and no key found in default locations: '~/.ssh/id_rsa.pub' or '~/.ssh/id_ed25519.pub'

Testing error is raised when key from config does not exist:

set public_key_path in [oci] config in my pycloudlib.toml config file to be ~/.ssh/nonexistant-key.pub
ran the oracle example script: python3 examples/oracle.py
Ensured error stating the following was thrown:

pycloudlib.errors.PycloudlibError: Provided public key path '/home/a-dubs/.ssh/oracle-ipv6-testing.pub1' does not exist

a-dubs · 2024-08-29T00:08:38Z

putting this into draft until i fix tests.

a-dubs · 2024-08-29T00:09:43Z

Also, should i add new unit tests that verify the functionality of the added changes? @holmanb (tag you're it)

holmanb

Also, should i add new unit tests that verify the functionality of the added changes? @holmanb (tag you're it)

Pycloudlib's test coverage is unfortunately very light on tests, but in this case the feature being tested is something that a user would immediately notice if it isn't working.

I'm honestly not sure whether it would be worth the effort in this case to write and maintain a test given the infrequency of changes to this part of the code and the immediate feedback that we would receive.

What do you think?

holmanb · 2024-09-09T20:12:33Z

pycloudlib/cloud.py

        self._check_and_set_config(config_file, required_values)

        user = getpass.getuser()
+        # check if id_rsa or id_ed25519 keys exist in the user's .ssh directory


This turns __init__() mostly into a key-handling function. I would prefer a helper method _get_ssh_keys()[1] to contain this logic and get called from __init__()

[1] maybe a better name, I didn't put any thought into that one

Haha agreed! Way too much going on there. And would allow for actually unit testing that (if so desired)

a-dubs · 2024-09-09T20:29:57Z

Also, should i add new unit tests that verify the functionality of the added changes? @holmanb (tag you're it)

Pycloudlib's test coverage is unfortunately very light on tests, but in this case the feature being tested is something that a user would immediately notice if it isn't working.

I'm honestly not sure whether it would be worth the effort in this case to write and maintain a test given the infrequency of changes to this part of the code and the immediate feedback that we would receive.

What do you think?

Let me go fix the existing unit tests that this change broke, and see if this change gets inherently tested that way. If not, it should be sufficient to just test the helper function that I'll create encapsulating this functionality.

a-dubs · 2024-09-24T14:57:49Z

@holmanb ready for re-review!

holmanb

@a-dubs Nit: I see some unnecessary whitespace changes in diff, but other than that everything else looks good. Please clean up the whitespace changes, then feel free to merge.

tests/unit_tests/azure/test_cloud.py

tests/unit_tests/qemu/test_qemu_cloud.py

tests/unit_tests/lxd/test_cloud.py

tests/unit_tests/openstack/test_cloud.py

tests/unit_tests/test_cloud.py

a-dubs · 2024-10-15T13:03:37Z

@a-dubs Nit: I see some unnecessary whitespace changes in diff, but other than that everything else looks good. Please clean up the whitespace changes, then feel free to merge.

@holmanb all those double whitespaces are because they are between classes not functions and this is the formatting enforced by ruff. to verify, I removed the double whitespace then ran tox -e format and it added the second newline back in.

Since Ubuntu 24.04 LTS and newer, the default location for ssh keys is `~/.ssh/id_ed25519` instead of `~/.ssh/id_rsa`. Thus, when no ssh key path is specified, this commit changes pycloudlib to check for an existing ssh key at either `~/.ssh/id_ed25519` or `~/.ssh/id_rsa`. Fixes GH canonical#341

In PR canonical#406, two pytest marks were added to help with mocking ssh keys in unit tests, but the marks were not registered with pytest so it was raising errors. This commit fixes that!

In PR canonical#406, two pytest marks were added to help with mocking ssh keys in unit tests, but the marks were not registered with pytest so it was raising errors. This commit fixes that! Also, migrate existing pytest configuration from tox.ini to pyproject.toml

In PR #406, two pytest marks were added to help with mocking ssh keys in unit tests, but the marks were not registered with pytest so it was raising errors. This commit fixes that! Also, migrate existing pytest configuration from tox.ini to pyproject.toml

PR canonical#406 broke some end consumers/users of pycloudlib on systems where 1) ssh keys are not set in the pycloudlib.toml and the ssh key is later set using the Cloud.use_key() method 2) no ssh keys exist at the default paths of '~/.ssh/id_rsa.pub' or '~/.ssh/id_ed25519.pub'. This commit removes/reverts the error that gets raised at the Cloud class instantation when those two cases are true. There was no way for an end user to override/prevent pycloudlib from erroring out besides for creating a fake ssh key at one of the two default paths. Now, a warning is just logged instead, restoring the flexibility pycloudlib preivously provided to end users for setting their ssh keys.

This commit will once again allow for setting ssh keys at runtime using the `Cloud.use_key()` method when default ssh keys dont exist on the system and no ssh key paths are provided in pycloudlib.toml. Further context: PR canonical#406 broke some end consumers/users of pycloudlib on systems where 1) ssh keys are not set in the pycloudlib.toml and the ssh key is later set using the Cloud.use_key() method 2) no ssh keys exist at the default paths of '~/.ssh/id_rsa.pub' or '~/.ssh/id_ed25519.pub'. This commit removes / reverts the error that was introduced in PR canonical#406 which gets raised at the Cloud class instantation when those two cases are true. The biggest issue with this change, is there was no way for an end user to override/prevent pycloudlib from erroring out if those cases are true - besides for creating a fake ssh key at one of the two default paths. Now, a warning is just logged instead, restoring the flexibility pycloudlib preivously provided to end users for setting / using ssh keys. If both scenarios 1 and 2 are true (ssh key is unset/doesn't exist), a new exception type `UnsetSSHKeyError` will be raised with verbose exception message explaining why this happened and how to fix.

This commit will once again allow for setting ssh keys at runtime using the `Cloud.use_key()` method when default ssh keys dont exist on the system and no ssh key paths are provided in pycloudlib.toml. Further context: PR #406 broke some end consumers/users of pycloudlib on systems where 1) ssh keys are not set in the pycloudlib.toml and the ssh key is later set using the Cloud.use_key() method 2) no ssh keys exist at the default paths of '~/.ssh/id_rsa.pub' or '~/.ssh/id_ed25519.pub'. This commit removes / reverts the error that was introduced in PR #406 which gets raised at the Cloud class instantation when those two cases are true. The biggest issue with this change, is there was no way for an end user to override/prevent pycloudlib from erroring out if those cases are true - besides for creating a fake ssh key at one of the two default paths. Now, a warning is just logged instead, restoring the flexibility pycloudlib preivously provided to end users for setting / using ssh keys. If both scenarios 1 and 2 are true (ssh key is unset/doesn't exist), a new exception type `UnsetSSHKeyError` will be raised with verbose exception message explaining why this happened and how to fix.

a-dubs force-pushed the GH-341-check-multiple-pubkeys branch 6 times, most recently from 6d98b02 to 2e1190a Compare August 28, 2024 22:19

a-dubs marked this pull request as draft August 29, 2024 00:08

holmanb self-assigned this Aug 30, 2024

holmanb reviewed Sep 9, 2024

View reviewed changes

a-dubs force-pushed the GH-341-check-multiple-pubkeys branch 2 times, most recently from e540971 to 92b30f6 Compare September 24, 2024 14:54

a-dubs marked this pull request as ready for review September 24, 2024 14:57

a-dubs requested a review from holmanb September 24, 2024 14:57

a-dubs force-pushed the GH-341-check-multiple-pubkeys branch 4 times, most recently from 880791c to 2b0eb2b Compare October 14, 2024 20:57

holmanb approved these changes Oct 14, 2024

View reviewed changes

a-dubs force-pushed the GH-341-check-multiple-pubkeys branch from 2b0eb2b to bbb2e80 Compare October 15, 2024 13:04

a-dubs merged commit 335c4a4 into canonical:main Oct 15, 2024

a-dubs mentioned this pull request Nov 19, 2024

fix(ssh): don't raise exception when default ssh keys can't be found #452

Merged

a-dubs mentioned this pull request Feb 26, 2025

Use priority list for pubkey names #341

Closed

Conversation

a-dubs commented Aug 26, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Testing of changes

Testing id_ed25519 can be found

Testing error is raised when neither default key is found

Testing error is raised when key from config does not exist:

Uh oh!

a-dubs commented Aug 29, 2024

Uh oh!

a-dubs commented Aug 29, 2024

Uh oh!

holmanb left a comment

Choose a reason for hiding this comment

Uh oh!

holmanb Sep 9, 2024

Choose a reason for hiding this comment

Uh oh!

a-dubs Sep 9, 2024

Choose a reason for hiding this comment

Uh oh!

a-dubs commented Sep 9, 2024

Uh oh!

a-dubs commented Sep 24, 2024

Uh oh!

holmanb left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

a-dubs commented Oct 15, 2024

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

a-dubs commented Aug 26, 2024 •

edited

Loading