Bug 1716551

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

(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

(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

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

(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. :)

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

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?

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.

This is a good idea, but the core developer team does not have the capacity to handle it. If anyone wants to step up and make this, we would be happy get this into Anaconda as a Pure Community Feature.

https://anaconda-installer.readthedocs.io/en/latest/contributing.html#pure-community-features

Alternatively, it can be an addon, as mentioned above.