explore split-ssh implementation

[mfc]

this feature would appeal to developers and sysadmins, the idea is to implement a feature for SSH similar to that which current exists for GPG.

This would protect users against SSH vulnerabilities including these recent ones:

• http://arstechnica.com/security/2015/07/bug-in-widely-used-openssh-opens-servers-to-password-cracking/
• http://arstechnica.co.uk/security/2016/01/bug-that-can-leak-crypto-keys-just-fixed-in-widely-used-openssh/

it has been referenced previously on the qubes mailing lists:

• https://groups.google.com/d/msg/qubes-users/ZYqMF0oqCP8/bJ5iRsdFAQAJ

[marmarek]

Should be pretty simple using ssh-agent and socat. Good material for community contribution.

[marmarek]

Should be pretty simple using ssh-agent and socat. Good material for community contribution.

[evadogstar]

This issue can be solved by moving to New GPG version and not
need to realize something for SSH as suggested, because of GnuPG 2.1 seems support
them by default with --enable-ssh-support key

Proof link, search for ssh term on the page:
https://gnupg.org/faq/whats-new-in-2.1.html

[evadogstar]

This issue can be solved by moving to New GPG version and not
need to realize something for SSH as suggested, because of GnuPG 2.1 seems support
them by default with --enable-ssh-support key

Proof link, search for ssh term on the page:
https://gnupg.org/faq/whats-new-in-2.1.html

[andrewdavidwong]

Would you be interested in doing this, @evadogstar?

[andrewdavidwong]

Would you be interested in doing this, @evadogstar?

[evadogstar]

Currently, I do not know the Qubes system as well as need to do that.

#474 Related ticket! Link it please.

And @marmarek say that

While we use GPG 2.1 (as it is in Fedora 23), split-gpg doesn't take advantage of its new agent architecture. Take a look at linked PoC above.

Split-gpg already used gpg2 under the hood?

[evadogstar]

Currently, I do not know the Qubes system as well as need to do that.

#474 Related ticket! Link it please.

And @marmarek say that

While we use GPG 2.1 (as it is in Fedora 23), split-gpg doesn't take advantage of its new agent architecture. Take a look at linked PoC above.

Split-gpg already used gpg2 under the hood?

[marmarek]

On Tue, Jul 05, 2016 at 10:09:07AM -0700, evadogstar wrote:

But why I'm on 3.2RC1 on dom0 have old version?
https://i.imgur.com/nsPuKFK.png

1. It's irrelevant what gpg version is in dom0 for split-gpg/split-ssh
2. Take a look at gpg2 (it's how Fedora package it).

Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

[marmarek]

On Tue, Jul 05, 2016 at 10:09:07AM -0700, evadogstar wrote:

But why I'm on 3.2RC1 on dom0 have old version?
https://i.imgur.com/nsPuKFK.png

1. It's irrelevant what gpg version is in dom0 for split-gpg/split-ssh
2. Take a look at gpg2 (it's how Fedora package it).

Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

[evadogstar]

gpg-agent can work as ssh-agent after the feature enabled at ~/.gnupg/gpg-agent.conf with enable-ssh-support.
To connect to gpg-agent ssh-client use this socket: SSH_AUTH_SOCK=$HOME/.gnupg/S.gpg-agent.ssh

https://incenp.org/notes/2015/gnupg-for-ssh-authentication.html

I suppose that

1. Qubes gpg-split-client must open socket at AppVM and setup environment SSH_AUTH_SOCK with it for ssh-client
2. Then forward this socket to gpg-agent at gpg-domain(vault) through qubes-split-gpg-server
3. All other key management carried at gpg-domain with standard gpg tools. Authorization with OpenGPG (key/subkey) is also possible and it's very interesting feature instead of using only regular SSH keys.

Is it secure to forward ssh-client(appvm) socket to gpg-agent at vault without validation? Seems not...
Transfered data must be somehow validated at qubes-gpg-server

[evadogstar]

gpg-agent can work as ssh-agent after the feature enabled at ~/.gnupg/gpg-agent.conf with enable-ssh-support.
To connect to gpg-agent ssh-client use this socket: SSH_AUTH_SOCK=$HOME/.gnupg/S.gpg-agent.ssh

https://incenp.org/notes/2015/gnupg-for-ssh-authentication.html

I suppose that

1. Qubes gpg-split-client must open socket at AppVM and setup environment SSH_AUTH_SOCK with it for ssh-client
2. Then forward this socket to gpg-agent at gpg-domain(vault) through qubes-split-gpg-server
3. All other key management carried at gpg-domain with standard gpg tools. Authorization with OpenGPG (key/subkey) is also possible and it's very interesting feature instead of using only regular SSH keys.

Is it secure to forward ssh-client(appvm) socket to gpg-agent at vault without validation? Seems not...
Transfered data must be somehow validated at qubes-gpg-server

[sjug]

Not sure why this is not a higher priority feature?

What is the proposed secure solution until this is fixed? Just have private ssh keys in an AppVm?

[sjug]

Not sure why this is not a higher priority feature?

What is the proposed secure solution until this is fixed? Just have private ssh keys in an AppVm?

[andrewdavidwong]

@sjug: I've increased the priority, but bear in mind that this is a "help wanted" issue, which means that we'll require help from the community in order to implement it.

[andrewdavidwong]

@sjug: I've increased the priority, but bear in mind that this is a "help wanted" issue, which means that we'll require help from the community in order to implement it.

[jpouellet]

From the OpenSSH 7.4 release notes:

New Features
------------

 * ssh(1): Add a proxy multiplexing mode to ssh(1) inspired by the
   version in PuTTY by Simon Tatham. This allows a multiplexing
   client to communicate with the master process using a subset of
   the SSH packet and channels protocol over a Unix-domain socket,
   with the main process acting as a proxy that translates channel
   IDs, etc.  This allows multiplexing mode to run on systems that
   lack file- descriptor passing (used by current multiplexing
   code) and potentially, in conjunction with Unix-domain socket
   forwarding, with the client and multiplexing master process on
   different machines. Multiplexing proxy mode may be invoked using
   "ssh -O proxy ..."

[jpouellet]

From the OpenSSH 7.4 release notes:

New Features
------------

 * ssh(1): Add a proxy multiplexing mode to ssh(1) inspired by the
   version in PuTTY by Simon Tatham. This allows a multiplexing
   client to communicate with the master process using a subset of
   the SSH packet and channels protocol over a Unix-domain socket,
   with the main process acting as a proxy that translates channel
   IDs, etc.  This allows multiplexing mode to run on systems that
   lack file- descriptor passing (used by current multiplexing
   code) and potentially, in conjunction with Unix-domain socket
   forwarding, with the client and multiplexing master process on
   different machines. Multiplexing proxy mode may be invoked using
   "ssh -O proxy ..."

[henn]

FYI - I put something together for this, though it's a ways from being as nicely packaged/documented as split-gpg. Pull requests welcomed!

You can find it at https://github.com/henn/qubes-app-split-ssh

[henn]

FYI - I put something together for this, though it's a ways from being as nicely packaged/documented as split-gpg. Pull requests welcomed!

You can find it at https://github.com/henn/qubes-app-split-ssh

[marmarek]

Thanks @henn!
I was wondering about some active proxy for ssh-agent - for example to filter requests based on public key requested, or to limit requests count in a single connection. But unfortunately the protocol doesn't look friendly for this.

[marmarek]

Thanks @henn!
I was wondering about some active proxy for ssh-agent - for example to filter requests based on public key requested, or to limit requests count in a single connection. But unfortunately the protocol doesn't look friendly for this.

[henn]

Thanks, @marmarek!

To stop connection-reuse, I think either "ssh-add -c" or implementing a proxy could work, though for now I'm happy since VMs have to ask at least once. It looks like this project has python code for a proxy that could be repurposed pretty easily.

RE: which key was requested, I picture the user having separate ssh-vaults for each private key, so haven't worried about this at this point.

Do you have any suggestions on how I could better package these scripts for distribution?

Also, I tried to automate the initial "ssh-add" for the ssh-vault by adding it to the /rw/config/rc.local file, but it didn't work (I think because of some combination of it being too early in the boot and not running within the GUI which set $SSH_AUTH_SOCK).
Do you have any suggestions on how to run something at AppVM startup under the GUI?

[henn]

Thanks, @marmarek!

To stop connection-reuse, I think either "ssh-add -c" or implementing a proxy could work, though for now I'm happy since VMs have to ask at least once. It looks like this project has python code for a proxy that could be repurposed pretty easily.

RE: which key was requested, I picture the user having separate ssh-vaults for each private key, so haven't worried about this at this point.

Do you have any suggestions on how I could better package these scripts for distribution?

Also, I tried to automate the initial "ssh-add" for the ssh-vault by adding it to the /rw/config/rc.local file, but it didn't work (I think because of some combination of it being too early in the boot and not running within the GUI which set $SSH_AUTH_SOCK).
Do you have any suggestions on how to run something at AppVM startup under the GUI?

[mig5]

@henn I found I could auto-add the SSH key by creating a ~/.config/autostart/ssh-add.desktop file

[Desktop Entry]
Name=ssh-add
Exec=ssh-add
Type=Application

[mig5]

@henn I found I could auto-add the SSH key by creating a ~/.config/autostart/ssh-add.desktop file

[Desktop Entry]
Name=ssh-add
Exec=ssh-add
Type=Application

[jpouellet]

xref discussion of @henn's impl: https://groups.google.com/d/topic/qubes-users/TPZBZlixqsI/discussion

[jpouellet]

xref discussion of @henn's impl: https://groups.google.com/d/topic/qubes-users/TPZBZlixqsI/discussion

[jpouellet]

xref env var propagation: https://groups.google.com/d/topic/qubes-devel/gXj5KWSkPIM/discussion

[jpouellet]

xref env var propagation: https://groups.google.com/d/topic/qubes-devel/gXj5KWSkPIM/discussion

[reynir]

Hi, I've been working on an implementation in OCaml using Mirage: https://github.com/reynir/qubes-mirage-ssh-agent

It's very much work in progress and there are some bugs, but it works well enough that I have been using it for a few days with two ssh keys. Building it from scratch without an existing OCaml setup is some work and the documentation could be improved in that regard. Feedback appreciated!

[reynir]

Hi, I've been working on an implementation in OCaml using Mirage: https://github.com/reynir/qubes-mirage-ssh-agent

It's very much work in progress and there are some bugs, but it works well enough that I have been using it for a few days with two ssh keys. Building it from scratch without an existing OCaml setup is some work and the documentation could be improved in that regard. Feedback appreciated!