Ssh-read personal-files request for jhack

Hi all, yet another personal-files request for jhack.

Jhack is going to need read access to ~/.ssh in order to be able to run juju ssh on LXD models.

    interface: personal-files
      - $HOME/.ssh

See the issue: and the solution proposed and tester by the one who found the problem:

Given the sensitive nature of the data, I’m fine if this is not autoconnect-enabled.

are the existing ssh-public-keys or ssh-keys snap interfaces not suitable for this ?

Uh. Didn’t know they existed. I find it hard to guess what already has an interface and what requires a custom personal-files one.

Anyway, the juju snap appears to use ssh-keys. Will give it a try with that one and see if it’s sufficient.

Thanks for the tip!

to find existing interfaces, there is an overview at:

yeah I was aware of that. The question is more: my snap needs (read/write?) access to /this/path. Is there an interface that provides it? How do I find that interface?

ah, there are two ways:

you simply install the snappy-debug snap and run it alongside of your app, it will print interface suggestions for all DENIED messages that appear when your app tries to access the dirs …

…or you could clone the snapd source and grep through the interfaces/builtin directory, permitted filesystem locations are usually explicitly mentioned in the code or at least have a regex that starts with the toplevel dir:


Come to think of it, it would be handy if this interface were autoconnect-enabled. Does it qualify?

Yes it is possible to get a store declaration to auto-connect ssh-keys - can you please provide some justification on why this is needed and in particular why auto-connect is appropriate?

It seems to be what people expect:

So from the linked thread I can only see one user suggesting this - I wonder if it would be possible that when trying to use jhack for ssh, whether jhack could first detect if ssh-keys is connected via snapctl is-connected ssh-keys and if not then it could ask the user if they wish to connect it first?

@ppasotti - ping, can you please provide the requested information?

Ah, sorry, missed the notification. So what @alexmurray suggests could ‘work’, but

  • it complicates the implementation
  • jhack wraps effectively the local juju client, so the reasonable expectation is that it has all access that the juju snap has. Seeing juju ssh work, but jhack-generated ‘juju ssh’ commands fail is unexpected. Forcing users to go through one more step to provide that access seems unnecessary.

one more:

Ok so this seems like a more common use-case.

+1 from me for auto-connect of ssh-keys for jhack. I have gone ahead and granted this my one vote but if other @reviewers disagree we can revert it.