Add a portal to manage ssh keys

[bilelmoussaoui]

Currently, on Sequeler, we do add an access to $HOME/.ssh to have access to the public/private keys in order to allow a connection to a database using a SSH tunnel.

It would be nice to have a portal to handle this, this way the user can enable/disable that from the application settings.

[matthiasclasen]

Hmm, is access to ssh keys the best we can do here?

Is it possible to make a portal that offers "Open an ssh tunnel to ..." ?

[bilelmoussaoui]

But what if you want to use a Github client and sign your commits (or just an IDE like Builder if they ever support Github/Gitlab). There will be a need to access to the keys and instead of having access to everything, the portal could ask the user which key they want to use and only that key could be used.

This might require more thinking to properly implement it I guess.

[matthiasclasen]

well, you were talking about tunnels, not signing

[bilelmoussaoui]

I mentioned what is needed for Sequeler in order to remove $HOME/.ssh filesystem permission. Other apps might require something else

[nanonyme]

Isn't this basically done through flatpak/flatpak#1438?

[Doomsdayrs]

Isn't this basically done through flatpak/flatpak#1438?

@GeorgesStavracas Sorry for the bump, Is this portal still required when we have a socket permission for it?

[GeorgesStavracas]

I don't really know, but my general assumption is that static permissions should be deprecated as much as possible, so without further context I'd say this is still necessary

[nanonyme]

Eh, what exactly would portal buy here? ssh-agent already operates with user consent, isolates secret material to host and access is revokable by user with Flatseal.

[costela]

Not all desktop environments support user consent (e.g. gnome). This might be fine for the trust model of the desktop environment, but not for apps running inside flatpak. Being able enforce consent via portal to an otherwise consent-free agent seems like an improvement, right?

For the record: there are probably other workarounds, like running multiple ssh-agents, explicitly adding ones keys with -c and sharing only that ssh-agent via --socket=ssh-auth. But that's hardly user-friendly.

[nanonyme]

gnome definitely supports user consent if your SSH keys are password protected like they should be.