Replace ssh.exe/scp.exe with plink.exe/pscp.exe

[jgriegershs]

Problem

K2s relies on ssh.exe and scp.exe being present on the host machine, not pinning down any version which lead to issues with "older" Windows versions (and therefore older versions of SSH) in the past.

Solution Proposal

• Use plink.exe instead of ssh.exe
• Use pscp.exe instead of scp.exe

The binaries of plink.exe and pscp.exe are located in the <K2s-dir>\bin folder.

[achimkist]

Yes we can try that. For this we need to generate key pairs with puttygen instead of ssh-keygen. This could be done only on Linux side since the puttygen.exe for Windows only provides a graphical interface to generate a key pair.

[jgriegershs]

For an interactive session, I tried different approaches:

• Go's SSH implementation golang.org/x/crypto/ssh:
  • Good: fastest option due to in-proc session creation
  • Good: no additional binaries needed
  • Bad: no terminal features like auto-completion or command history, even with an xterm session
  • Bad: issues with \r and \n in both commands execution and terminal display
• ssh.exe in separate process:
  • Good: best user experience (auto-completion, colorful terminal, command history, etc.)
  • Good: already installed on modern Windows machines (openSSH)
  • Bad: no version pinning of SSH, version present on the host system might be outdated or lack required features
  • Bad: either present SSH version must be checked or a certain ssh.exe version must be delivered with K2s
• plink.exe in separate process:
  • Good: is already available (deployed by K2s) and version is pinned
  • Bad: lacks certain terminal features like command history
  • Bad: the authors state that "Plink is probably not what you want if you want to run an interactive session in a console window"[Source]
  • Bad: needs PuTTY key format (ssh.exe uses PEM format) which must be created by using puttygen.exe that does not provide a command-line interface on Windows to run it in terminal-only mode
• putty.exe in separate process:
  • Good: provides same good user experience as calling ssh.exe (maybe less colorful)
  • Bad: opens in a separate terminal (assuming the user expects to stay in the k2s terminal)
  • Bad: needs PuTTY key format (ssh.exe uses PEM format) which must be created by using puttygen.exe that does not provide a command-line interface on Windows to run it in terminal-only mode

Given that, I personally tend to use the option "ssh.exe in separate process". Whether we check a certain version as a prerequisite or we deliver ssh.exe as a binary would be still out for debate.

What do you think?

[jgriegershs]

Regarding scp.exe/pscp.exe, I rather tend to abandon SCP completely in favor of SFTP, because:

• the OpenSSH authors state: "The scp protocol is outdated, inflexible and not readily fixed. We recommend the use of more modern protocols like sftp and rsync for file transfer instead." [Source].
• Go packages like github.com/pkg/sftp exist for secure file transfer that are build on top of Go's SSH implementation golang.org/x/crypto/ssh (already tested locally)

What do you think?