Initial tunnel changes

[XavierChanth]

Summary of conversation with @gkc:

• -u will be the username for initial tunnel and ssh session
• -U will override the initial tunnel username
• flag to disable the use of ephemeral keys

[gkc update]

• if flag to disable use of ephemeral keys is set, then an identity keyPair is required; so if one wasn't suppled then we will need to throw an error

[gkc]

@XavierChanth Expect a PR from me tomorrow

[gkc]

@XavierChanth #586 addresses the '-U' parameter. Working on another PR for the flag to disable use of ephemeral keys. Note that if the flag to disable use of ephemeral keys is set, then an identity keyPair is required; therefore if an identity keyPair wasn't suppled, and this flag is set, then we will throw an error

[gkc]

@XavierChanth Thinking more about this this morning, "disable use of ephemeral keys" is not the right flag.

We've got two questions to answer:

• A. Should we create an initial tunnel?

  • (If no, then we just set up the rvd socket relay, and let the caller decide what to do next)

• B. Should we use the ephemeral keys for the initial tunnel?

• A==true && B==true : current behaviour

• A==true && B==false : kind of weird - if going to create a tunnel, using ephemeral keys is better

  • thus, ephemeral keys question doesn't matter

• A==false : ephemeral keys question doesn't matter

Therefore I think we only need to answer this question: "Do you (the caller / calling code) want sshnp to set up an initial tunnel or not?"

• If the answer is yes, then we use the ephemeral keys to do so (no reason not to)
• If the answer is no, then we don't set up an initial ssh tunnel; we just set up the rv socket relay

[XavierChanth]

What happens with -U when there's no tunnel, what happens with --add-forwards-to-tunnel?

Seems logical to disable both when there's no tunnel.

[XavierChanth]

tunnel or no tunnel?

--[no-]tunnel - default true.

OpenSsh Implementation - no tunnel means do nothing besides setup socket relay and output command (ssh command to sshrvd).

Dart Implementation - no tunnel means we create a client as the remoteUsername, and returns an SSHClient object.

[XavierChanth]

A==true && B==false - doesn't have a clear use-case today, so we will only add flag A for now as --[no-]tunnel

[gkc]

@XavierChanth Thinking about this further, I believe we should not add the --[no-]tunnel flag, the reason being that, while there is (currently) a throughput cost when using the pure dart client to run a second session over an ssh tunnel, that cost is worth it given the security benefits of using ephemeral keys for the ssh tunnel (e.g. this recent exploit)

[XavierChanth]

@gkc Then in order to be pure dart, I think we need to do the following:

The initial tunnel needs to forward the remote sshd port to a dart stream. Then the dart ssh client (for the interactive session) will need to connect over that stream.

Otherwise we can't support mobile.

[XavierChanth]

I think we can close this now @gkc

The initial tunnel changes are done:

• Pure Dart Tunnel Handler returns an SSH Client object.
• -U flag for tunnel username has been added.
• We've decided that ephemeral keys should always be required.

[gkc]

@XavierChanth OK; I will create a new ticket to complete the pure dart client as per our discussions