SSH Interface is missing

[Nicholas Skaggs]

Attempting to call /usr/bin/ssh is denied. There are legitmate use cases for snaps to call ssh; an interface would be useful to make this available to snaps.

This includes access to ssh keys.

[Oliver Grawert (ogra)]

you mean so that your snap can call "ssh localhost" and get full system access to everything ?
:P

[Nicholas Skaggs (nskaggs)]

Sounds dangerous :-) -- but presumably we could do it sanely? Requiring keys helps. I'm open to thoughts, but I know for instance spread uses ssh :-)

[Oliver Grawert (ogra)]

and you can not ship your own ssh client inside the snap ?

[Seth Arnold (seth-arnold)]

.. or ssh server, as required?

[Oliver Grawert (ogra)]

right ... what you want though is readonly access to the ssh keys ... for this we definitely need an interface, but you can not really rely on each and every target system having ssh installed (or even a version that supports the protocols you use), so to make your snap universally usable on all possible distros you should ship the binaries yourself.

[Nicholas Skaggs (nskaggs)]

On shipping an ssh client in the snap itself, it seems like core snap contains an openssh binary. If this is a promise, I shouldn't have to ship this bundled myself right?

[Jamie Strandboge (jdstrand)]

An interface allowing access to /home/user/.ssh and the core binaries could be written. For series 16, we can rely on the core image from Ubuntu to have the ssh binaries since this series is stable (it would be good to have someone like Jamie Bennett confirm that assertion). Future series or other core snaps may not. I don't think it is necessarily a problem to provide access to the ssh binaries in core because the snap could always choose to ship its own ssh binaries. Certainly if we exposed the binaries as an interface, they would have to be present.

Note two things though:

- the snap's HOME is set to ~/snap/name/revision, so an ssh client would be able to read its configuration and keys in ~/snap/name/revision/.ssh. If the snap shipped its own ssh binaries, it wouldn't need to use anything but the network interface to create and use its own keys. I suspect this is likely going to work for many scenarios where you want to use different keys for different things (eg, a github key, a juju key, etc)
- because the snap's HOME is set to ~/snap/name/revision and not what getpwent() returns (eg, /home/user), ssh shipped in the snap or not may need to be told where the .ssh directory is. This is bug #1636229 (see comment 11 in particular)

If this interface were going to be written, I suspect it would look like:

1. we allow access to the ssh binaries by default, but not the keys
2. we create a ssh-observe interface that allows read access access to everything in .ssh
3. we create a ssh-control interface that allows write access to everything in .ssh
4. the base declaration denies auto-connection for both ssh-observe and ssh-control

[Michael Hudson-Doyle (mwhudson)]

On 14 January 2017 at 04:31, Jamie Strandboge <email address hidden> wrote:

>
> Note two things though:
>
> - the snap's HOME is set to ~/snap/name/revision, so an ssh client would
> be able to read its configuration and keys in ~/snap/name/revision/.ssh.

I'm not quite reading this closely enough to be sure, but you know that ssh
uses getpwent, not the value of $HOME, to find the .ssh directory, right?

Cheers,
mwh

[Vincent Ladeuil (vila)]

> I'm not quite reading this closely enough to be sure,

Same here.

> ssh uses getpwent, not the value of $HOME,

Confirmed, I had to check the source while tracking a related issue.

And I have least tests that will break if ssh starts to obey $HOME so I suspect upstream won't take a change from getpwent to expanding $HOME lightly.

From a dev perspective, I'd feel better with keeping ssh work this way, knowing that keys need to be created/deleted in ~/.ssh, that the config and known_hosts are kept there as well and all other uses can just read them there.

I.e. ssh-control gives access to ~/.ssh and ssh-observe give read access to ~/.ssh.

Managing known_hosts is tricky though... as it would require ssh-control.

Just my 2 cents.

[Jamie Strandboge (jdstrand)]

@Michael: while I left out a word, that is precisely what I was getting at with this comment:

"because the snap's HOME is set to ~/snap/name/revision and not what getpwent() returns (eg, /home/user), ssh shipped in the snap [sic. may] or not may need to be told where the .ssh directory is. This is bug #1636229 (see comment 11 in particular)"

Since the use of getpwent() is now confirmed, I believe what I outlined in https://bugs.launchpad.net/snappy/+bug/1606574/comments/7 as a possible design is how this interface should be written, if it is going to be implemented.

Note that people shouldn't feel blocked by this: people can ship their own ssh binaries and use 'ssh -F $HOME/.ssh/config -i $HOME/.ssh/id... ...' with any other options to have ssh use the files in /home/<user>/snap/$SNAP/$SNAP_REVISION/.ssh (ie, the value of $HOME with the 'ssh -i' command) such as -S, -o, etc.

[Jamie Strandboge (jdstrand)]

This is now committed to master via https://github.com/snapcore/snapd/pull/4100. This will also be in 2.30.