Bug 1716551 - RFE: Support loading ssh keys from github
Summary: RFE: Support loading ssh keys from github
Keywords:
Status: NEW
Alias: None
Product: Fedora
Classification: Fedora
Component: anaconda
Version: rawhide
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Anaconda Maintenance Team
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2019-06-03 15:03 UTC by Jakub Jelen
Modified: 2020-02-21 11:38 UTC (History)
10 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed:
Type: Bug


Attachments (Terms of Use)

Description Jakub Jelen 2019-06-03 15:03:45 UTC
It can be helpful to preconfigure installed system with ssh keys for convenient remote access during installation. Although it is not handy to do this by writing the key from memory, importing the keys from github.com, where they are publicaly available can be simple and handy with this url: https://github.com/<username>.keys

The kickstarts already support arguments for ssh public keys so this is mostly matter of UI.

This can be also very good alternative to allowing root logins with passwords (bug #1716282).

Comment 1 Martin Kolman 2019-06-05 15:12:20 UTC
So, lets try to flash out how an initial implementation of this could look like. :)

I would recommend starting with these constraints for the initial version:
- GUI only, no TUI support
- only for the root account, as it's the most pressing there

For the UI part, I can see basically 3 new elements that would have to be added:
- a URL input field to host the URL pointing to the keys file
- a button that initializes the fetching & validation of the keyfile
- some status indication of the process being successful or not

Given the current simple uncluttered design of the root password spoke (basically two
input fields and some status indicators) it would make sense to me to have the key fetching
available via a dialog rather than to clutter the spoke screen, in a similar way the
user spoke has the advanced options dialog.

Adding Mairin Duffy, who designed most of the current UI principles to CC for possible other ideas of how to do this. :)

And on the backend side, one simple needs to add the new key to the SSH key list using SetSshKeys() via DBus:
https://github.com/rhinstaller/anaconda/blob/master/pyanaconda/modules/users/users_interface.py#L173

Comment 2 Stephen Gallagher 2019-06-19 15:58:35 UTC
(In reply to Martin Kolman from comment #1)
> So, lets try to flash out how an initial implementation of this could look
> like. :)
> 
> I would recommend starting with these constraints for the initial version:
> - GUI only, no TUI support

See below; the implementation should be easy enough that the TUI could just be `--ssh-keys-github-user=<github_username>` or similar.

> - only for the root account, as it's the most pressing there

I don't really see the value in restricting it to the root user. Especially if we're advocating for the use of keys rather than passwords in general.

> 
> For the UI part, I can see basically 3 new elements that would have to be
> added:
> - a URL input field to host the URL pointing to the keys file
> - a button that initializes the fetching & validation of the keyfile
> - some status indication of the process being successful or not
> 

Github actually has a public API for retrieving verified public keys, so realistically we only need to know the user's github username. We don't even need them to provide login information. Anaconda will just need to query https://api.github.com/users/<github_username>/keys and process the JSON in the format:

[
  {
    "id": 12345678,
    "key": "ssh-rsa AAAAB..."
  }
  {
    "id": 12345679,
    "key": "ssh-rsa AAAAC..."
  }
]

Just extract the text of the result[index]['key'] values and write them out to the SetSshKeys() function. Also, yes: Github permits multiple keys and we should just copy them all into the authorized_keys file.


> Given the current simple uncluttered design of the root password spoke
> (basically two
> input fields and some status indicators) it would make sense to me to have
> the key fetching
> available via a dialog rather than to clutter the spoke screen, in a similar
> way the
> user spoke has the advanced options dialog.
> 
> Adding Mairin Duffy, who designed most of the current UI principles to CC
> for possible other ideas of how to do this. :)
> 
> And on the backend side, one simple needs to add the new key to the SSH key
> list using SetSshKeys() via DBus:
> https://github.com/rhinstaller/anaconda/blob/master/pyanaconda/modules/users/
> users_interface.py#L173

Comment 3 Martin Kolman 2019-06-19 16:07:53 UTC
(In reply to Stephen Gallagher from comment #2)
> (In reply to Martin Kolman from comment #1)
> > So, lets try to flash out how an initial implementation of this could look
> > like. :)
> > 
> > I would recommend starting with these constraints for the initial version:
> > - GUI only, no TUI support
> 
> See below; the implementation should be easy enough that the TUI could just
> be `--ssh-keys-github-user=<github_username>` or similar.
Sure, but one should still do some error checking, validation of the result, 
possibly also check if network is available, etc.

> 
> > - only for the root account, as it's the most pressing there
> 
> I don't really see the value in restricting it to the root user. Especially
> if we're advocating for the use of keys rather than passwords in general.
Sure, what I was describing was simply the simplest solution I could come up with. To support also regular users,
you need to change yet another set of spokes (User config spoke), not just one set (Root password spoke).
The "backend" code would of course be the same.

> 
> > 
> > For the UI part, I can see basically 3 new elements that would have to be
> > added:
> > - a URL input field to host the URL pointing to the keys file
> > - a button that initializes the fetching & validation of the keyfile
> > - some status indication of the process being successful or not
> > 
> 
> Github actually has a public API for retrieving verified public keys, so
> realistically we only need to know the user's github username. We don't even
> need them to provide login information. Anaconda will just need to query
> https://api.github.com/users/<github_username>/keys and process the JSON in
> the format:
> 
> [
>   {
>     "id": 12345678,
>     "key": "ssh-rsa AAAAB..."
>   }
>   {
>     "id": 12345679,
>     "key": "ssh-rsa AAAAC..."
>   }
> ]
> 
> Just extract the text of the result[index]['key'] values and write them out
> to the SetSshKeys() function. Also, yes: Github permits multiple keys and we
> should just copy them all into the authorized_keys file.
> 
> 
> > Given the current simple uncluttered design of the root password spoke
> > (basically two
> > input fields and some status indicators) it would make sense to me to have
> > the key fetching
> > available via a dialog rather than to clutter the spoke screen, in a similar
> > way the
> > user spoke has the advanced options dialog.
> > 
> > Adding Mairin Duffy, who designed most of the current UI principles to CC
> > for possible other ideas of how to do this. :)
> > 
> > And on the backend side, one simple needs to add the new key to the SSH key
> > list using SetSshKeys() via DBus:
> > https://github.com/rhinstaller/anaconda/blob/master/pyanaconda/modules/users/
> > users_interface.py#L173

Comment 4 Stephen Gallagher 2019-06-19 16:57:00 UTC
(In reply to Martin Kolman from comment #3)
> (In reply to Stephen Gallagher from comment #2)
> > (In reply to Martin Kolman from comment #1)
> > > So, lets try to flash out how an initial implementation of this could look
> > > like. :)
> > > 
> > > I would recommend starting with these constraints for the initial version:
> > > - GUI only, no TUI support
> > 
> > See below; the implementation should be easy enough that the TUI could just
> > be `--ssh-keys-github-user=<github_username>` or similar.
> Sure, but one should still do some error checking, validation of the result, 
> possibly also check if network is available, etc.
> 

Network availability, maybe. But as for validation, I'm pretty sure the only real check is "not the empty string". Because otherwise, you can't actually validate the contents without having the private key to challenge it.

Comment 5 Martin Kolman 2019-06-20 10:16:24 UTC
(In reply to Stephen Gallagher from comment #4)
> Network availability, maybe. But as for validation, I'm pretty sure the only
> real check is "not the empty string". Because otherwise, you can't actually
> validate the contents without having the private key to challenge it.
Well, you can check the length looks about right, but otherwise yes, the first SSH login attempt will be the real validation. :)

Comment 6 Jakub Jelen 2019-06-24 08:48:47 UTC
If you have access to ssh-keygen in the installation, it should be possible to generate at least the fingerprint of the ssh key so the users can verify it against their private key on different screen. I think this would be very desirable. For example the following output is something that can be verified by the user, making sure the key is not malformed and matches their private part:

$ ssh-keygen -lf ~/.ssh/id_rsa.pub
4096 SHA256:N6rTuZq5m69Tw2Nh5SicH5tysCOcnLeSE4UqEwJVrbw RSA jjelen@t470s.jjelen.redhat.com (RSA)

Alternatively, there are other ways to generate the same fingerprint using sha256sum, base64 and other tools. But if possible, I would recommend sticking with the ssh-keygen.

Comment 7 Jakub Jelen 2020-02-19 15:31:27 UTC
FYI, I just stumbled upon a tool ssh-import-id, which does exactly this and which could be used internally:

http://manpages.ubuntu.com/manpages/bionic/man1/ssh-import-id.1.html

It can do the import from github (not that simple wget would not do that), but it is additionally focused on Ubuntu and Launchpad accounts, but it might be possible to extend to pull ssh keys from FAS (or new FAS as it will be done).

Out of the curiosity, is there any progress or plans to follow up on this?

Comment 8 Vendula Poncova 2020-02-21 11:38:32 UTC
Hi, at this moment, there are no plans for implementing this feature in Anaconda. However, I don't think it needs to be implemented in Anaconda, the same functionality could be provided by a nice little addon.


Note You need to log in before you can comment on or make changes to this bug.