NoPorts Release 4.0.0

[gkc]

Is your feature request related to a problem? Please describe.

noports release 4.0.0 will have multiple stability and functionality enhancements and should be done as soon as is practical

Describe the solution you'd like

### Remaining Items for 4.0.0 Release
- [ ] https://github.com/atsign-foundation/sshnoports/issues/537
- [x] Update documentation to clearly explain the `--legacy-daemon` flag behaviour
- [x] Create good release notes explaining compatibility. (TL;DR: old clients are fully compatible with new daemons; new clients are fully compatible with old daemons **IF** the `--legacy-daemon` flag is set

### Ready for Release
- [ ] https://github.com/atsign-foundation/sshnoports/issues/520
- [x] Fix Windows build CI (Sshnoports)
- [ ] https://github.com/atsign-foundation/sshnoports/issues/104
- [ ] https://github.com/atsign-foundation/sshnoports/issues/572
- [ ] https://github.com/atsign-foundation/sshnoports/issues/588
- [ ] https://github.com/atsign-foundation/sshnoports/issues/573
- [x] Implement direct ssh
- [x] Implement cryptographic signing of requests from sshnp to sshnpd, and signature verification by sshnpd
- [x] Implement cryptographic signing of responses from sshnpd to sshnp, and signature verification by sshnp
- [x] In sshnpd, replace the use of `-o ForkAfterAuthentication` with the equivalent `-f` which has been available in openssh for longer. This will allow sshnpd to run on older linux distributions e.g. Debian 10 and partially resolve [this ticket](#299)
- [x] Switch the new sshnp flag `--legacy-daemon` from default true to default false, and update the e2e tests so that direct ssh is tested as well as the existing reverse ssh
- [x] Update documentation to clearly explain that when using v4 client and daemon, direct ssh is the default - reverse ssh is still supported if user chooses not to use an rvd socket tunnel
- [x] Remove init() from the public interface, (run() can call init() internally in existing implementations)
- [x] Test for Windows
- [ ] https://github.com/atsign-foundation/sshnoports/issues/547
- [ ] https://github.com/atsign-foundation/sshnoports/issues/578

[gkc]

@XavierChanth @cconstab @JeremyTubongbanua Please add tasks for any other things we need in v4.0.0

[cconstab]

Been giving the use of ephemeral ssh keys in the forward use of sshnp (i.e sshnpd extends sshd via sshrv) some thought.

Currently we use ephemeral keys for the reverse ssh so that we can get to the remote sshd on localhost.

Whilst strictly speaking if you have an account on the remote machine you should be able to use those ssh keys to get port 22 extended. But in some cases the remote sshd will be asking for additional auth and that may upset the flow of the forward ssh.

So it may be worth thinking again and using ephemeral ssh keys to get to the sshd port so when the user runs the ssh command they can auth via whatever mechanism is added to the sshd (for instance CyberArk).

This could mean for instance a standard sshd runnning on say port 22000 for use with sshnp and then extending to 22 where the Cyberark sshd is running..

So options for ephemeral keys and talking to a sshd not on the standard port 22 (sshnp non standard port for sshd was added in a draft PR this weekend)

Discussion before code :-)

[XavierChanth]

@gkc we likely also want to include any changes to the sshnpd installer in this release as well. It might be time that I implement config files for sshnpd so we can start supporting init systems

[gkc]

Will aim to get v4 out the door during PR70

[XavierChanth]

@gkc @cconstab I plan to modify how ssh key management works in ssh no ports across the board: Adding -i which will allow you to specify either the private or publickey, see the man page entry for ssh -i:

-i identity_file
             Selects a file from which the identity (private key) for public key authentication is read.  You can also
             specify a public key file to use the corresponding private key that is loaded in ssh-agent(1) when the
             private key file is not present locally.

In addition, -s will change from a String option to a boolean flag, and it will simply send the public key associated with the identity specified by -i. (BREAKING CHANGE)

The reason for these changes is that it is no longer viable to pass around file paths in the core code, due to mobile sandboxing issues. So when the CLI receives a file path it will read the file in and carry that around as part of the parameters instead, this way the keys are fully portable.

[XavierChanth]

Adding another mixin to the SSHNPImpl Family:

classDiagram
    class SSHNP{
        <<abstract interface>>
      Exports public API
    }
    class SSHNPImpl{
        <<abstract>>
      Implements common code between all implementations
    }

    class SSHNPForwardDartImpl {
        forward pure-dart client
    }
    class SSHNPForwardExecImpl {
        forward ssh exec client
    }
    class SSHNPReverseImpl {
        reverse ssh client for non-sshrvd hosts
    }
    class SSHNPLegacyImpl {
        reverse ssh client for <4.0.0 daemons
    }

    class SSHNPForwardMixin{
      <<mixin>>
      Implements common forward code
    }
    class SSHNPReverseMixin{
      <<mixin>>
      Implements common reverse code
    }
    class SSHNPLocalFileMixin{
      <<mixin>>
      Implements file system bindings for support client types
    }
    SSHNP <|.. SSHNPImpl

    SSHNPImpl <|.. SSHNPForwardDartImpl
    SSHNPImpl <|.. SSHNPForwardExecImpl
    SSHNPImpl <|.. SSHNPReverseImpl
    SSHNPImpl <|.. SSHNPLegacyImpl

    SSHNPForwardDartImpl *-- SSHNPForwardMixin
    SSHNPForwardExecImpl *-- SSHNPForwardMixin

    SSHNPForwardExecImpl *-- SSHNPLocalFileMixin
    SSHNPReverseImpl *-- SSHNPLocalFileMixin
    SSHNPLegacyImpl *-- SSHNPLocalFileMixin

    SSHNPReverseImpl *-- SSHNPReverseMixin
    SSHNPLegacyImpl *-- SSHNPReverseMixin

[gkc]

@gkc @cconstab I plan to modify how ssh key management works in ssh no ports across the board: Adding -i which will allow you to specify either the private or publickey, see the man page entry for ssh -i:

-i identity_file
             Selects a file from which the identity (private key) for public key authentication is read.  You can also
             specify a public key file to use the corresponding private key that is loaded in ssh-agent(1) when the
             private key file is not present locally.

In addition, -s will change from a String option to a boolean flag, and it will simply send the public key associated with the identity specified by -i. (BREAKING CHANGE)

The reason for these changes is that it is no longer viable to pass around file paths in the core code, due to mobile sandboxing issues. So when the CLI receives a file path it will read the file in and carry that around as part of the parameters instead, this way the keys are fully portable.

Perfect, thanks Xavier - this has been a code smell for a while

[cconstab]

Old hack temoved 4.0.0 release is the time to break things TY

[XavierChanth]

Another behaviour thing I'm fixing: remote username is expected to be shared or manually set by the client, this should automatically fallback to the current local username like ssh, but right now it throws an error.