Support for OpenSSH from buster-backports

[Erisa]

I am not sure when exactly it happened but at some point recently OpenSSH 8.4 was added to the buster-backports repository. See here: https://packages.debian.org/buster-backports/ssh and its dependencies.

My suggestion is for the documentation (Wiki?) and other related things (Like the apt repository) to mention and support the possibility of installing a supported version of SSH from backports instead of upgrading the entire system to Bullseye for one piece of software.

Of course upgrading to Bullseye is still a possibility and may be preferred for some users, but I feel most would prefer to use the backports package and they may not realise it exists without documentation here.

I am currently running Debian Buster in WSL2 with OpenSSH_8.4p1 Debian-2~bpo10+1 and the repository does not work with buster:

Click for apt repo failure details

``` erisa@Tuturu:~$ ssh -V OpenSSH_8.4p1 Debian-2~bpo10+1, OpenSSL 1.1.1d 10 Sep 2019 ``` ``` erisa@Tuturu:~$ sudo apt install windows-fido-bridge Reading package lists... Done Building dependency tree Reading state information... Done Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. The following information may help to resolve the situation: The following packages have unmet dependencies: windows-fido-bridge : Depends: windows-fido-bridge-skapiv5 but it is not going to be installed or windows-fido-bridge-skapiv7 but it is not going to be installed E: Unable to correct problems, you have held broken packages. ``` ``` erisa@Tuturu:~$ sudo apt install windows-fido-bridge windows-fido-bridge-skapiv5 windows-fido-bridge-skapiv7 Reading package lists... Done Building dependency tree Reading state information... Done Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. The following information may help to resolve the situation: The following packages have unmet dependencies: windows-fido-bridge-skapiv5 : Depends: openssh-client (< 1:8.4) but 1:8.4p1-2~bpo10+1 is to be installed Depends: libc6 (>= 2.30) but 2.28-10 is to be installed Depends: libgcc-s1 (>= 3.0) but it is not installable Depends: libstdc++6 (>= 9) but 8.3.0-6 is to be installed Conflicts: windows-fido-bridge-skapiv7 but 1.1.0 is to be installed windows-fido-bridge-skapiv7 : Depends: libc6 (>= 2.30) but 2.28-10 is to be installed Depends: libgcc-s1 (>= 3.0) but it is not installable Depends: libstdc++6 (>= 9) but 8.3.0-6 is to be installed Conflicts: windows-fido-bridge-skapiv5 but 1.1.0 is to be installed E: Unable to correct problems, you have held broken packages. ```

Installing from source appears to work okay, though under the default environment you have to specify the full SSH_SK_PROVIDER=/usr/local/lib/libwindowsfidobridge.so for it to function. Note that it is also required to specify -DSK_API_VERSION=7 to work with the OpenSSH 8.4 that backports supplies.

When I attempted, producing a package results in some.. strange things:

dpkg: error processing archive /home/erisa/windows-fido-bridge/build/windows-fido-bridge-skapiv7_1.1.0_amd64.deb (--unpack):
 parsing file '/var/lib/dpkg/tmp.ci/control' near line 4:
 field name 'windows-fido-bridge' must be followed by colon
dpkg: error processing archive /home/erisa/windows-fido-bridge/build/windows-fido-bridge_1.1.0_amd64.deb (--unpack):
 parsing file '/var/lib/dpkg/tmp.ci/control' near line 3:
 field name 'windows-fido-bridge' must be followed by colon
Errors were encountered while processing:
 /home/erisa/windows-fido-bridge/build/windows-fido-bridge-skapiv7_1.1.0_amd64.deb
 /home/erisa/windows-fido-bridge/build/windows-fido-bridge_1.1.0_amd64.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)

Unfortunately I don't know enough about the project or Debian packaging to begin to work this out myself, I hope my information helps in some way.

[mgbowen]

My suggestion is for the documentation (Wiki?) and other related things (Like the apt repository) to mention and support the possibility of installing a supported version of SSH from backports instead of upgrading the entire system to Bullseye for one piece of software.

Fully agree! Thanks for the heads up, I didn't realize OpenSSH was in buster-backports. I'll work on updating the wiki with instructions on how to use it and creating a separate distribution for buster-backports in apt.mgbowen.dev.

erisa@Tuturu:~$ sudo apt install windows-fido-bridge windows-fido-bridge-skapiv5 windows-fido-bridge-skapiv7
[...]
The following packages have unmet dependencies:
 windows-fido-bridge-skapiv5 : Depends: openssh-client (< 1:8.4) but 1:8.4p1-2~bpo10+1 is to be installed
                               Depends: libc6 (>= 2.30) but 2.28-10 is to be installed
                               Depends: libgcc-s1 (>= 3.0) but it is not installable
                               Depends: libstdc++6 (>= 9) but 8.3.0-6 is to be installed
                               Conflicts: windows-fido-bridge-skapiv7 but 1.1.0 is to be installed
 windows-fido-bridge-skapiv7 : Depends: libc6 (>= 2.30) but 2.28-10 is to be installed
                               Depends: libgcc-s1 (>= 3.0) but it is not installable
                               Depends: libstdc++6 (>= 9) but 8.3.0-6 is to be installed
                               Conflicts: windows-fido-bridge-skapiv5 but 1.1.0 is to be installed

That this command didn't work is expected. windows-fido-bridge-skapiv5 and windows-fido-bridge-skapiv7 conflict with each other because you can't install both at the same time. I set it up this way given you'll only ever have one (official) OpenSSH version installed via apt and a single installation of OpenSSH only supports a single sk-api version. Unfortunately, it's not possible for an OpenSSH SK middleware to support multiple sk-api versions in a single library.

My intention with the separate skapi packages was to allow for sudo apt install windows-fido-bridge to install the correct version windows-fido-bridge-skapi package automatically, but I think because you're trying to install the bullseye debs on a buster installation, it fails due to the issues that apt printed: among other newer libraries, the windows-fido-bridge library depends on libc6 >= 2.30, but buster only has 2.28, even with the buster-backports repo set up (you can at the top right of libc6's info page that buster-backports does not provide an updated version of libc6, which makes sense given AFAIK it's somewhat of a dangerous/intrusive upgrade). Building packages targeting buster-backports should resolve the issue.

That said, if the automatic selection fails, manually specifying the correct skapi package that goes with your OpenSSH version in addition to windows-fido-bridge itself should still work. For example, on a system with OpenSSH 8.4, this should work assuming the correct dependencies are available:

sudo apt install windows-fido-bridge windows-fido-bridge-skapiv7

But ideally I'd like to fix the auto selection if it's broken.

dpkg: error processing archive /home/erisa/windows-fido-bridge/build/windows-fido-bridge-skapiv7_1.1.0_amd64.deb (--unpack):
 parsing file '/var/lib/dpkg/tmp.ci/control' near line 4:
 field name 'windows-fido-bridge' must be followed by colon

In this case, this error happens when subsequent lines in a multi-line Description field aren't indented with a single space. From my own experimentation with CMake in buster vs. CMake in bullseye, it looks like something related to how the package description variable value is parsed changed between 3.13 (the version in buster) and 3.18 (the version in bullseye). A package built with CMake in bullseye produces the following (correct) Description field:

Description: an OpenSSH security key middleware for WSL (skapi version selection shim) 
 windows-fido-bridge is an OpenSSH security key middleware that allows you 
 to use a FIDO2/U2F security key (e.g. a YubiKey) to SSH into a remote server 
 from WSL.

A package built with CMake in buster produces the following (incorrect) Description field:

Description: an OpenSSH security key middleware for WSL (skapi version selection shim) 
windows-fido-bridge is an OpenSSH security key middleware that allows you 
to use a FIDO2/U2F security key (e.g. a YubiKey) to SSH into a remote server 
 from WSL.

Notice how only the final line is properly indented. If you're curious, you can show the contents of the control file of a deb file using dpkg-deb -I "$deb_file_path".

On your buster machine, could you try applying the following patch and running make package again?

diff --git a/CMakeLists.txt b/CMakeLists.txt
index 1792537..b45efe2 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -119,8 +119,8 @@ set(CPACK_DEBIAN_REAL_DEB_GROUP_PACKAGE_NAME "windows-fido-bridge-skapiv${SK_API

 set(CPACK_COMPONENT_REAL_DEB_GROUP_DESCRIPTION "\
 an OpenSSH security key middleware for WSL (for OpenSSH sk-api v${SK_API_VERSION}) \
-\nwindows-fido-bridge is an OpenSSH security key middleware that allows you \
-\nto use a FIDO2/U2F security key (e.g. a YubiKey) to SSH into a remote server \
+\n windows-fido-bridge is an OpenSSH security key middleware that allows you \
+\n to use a FIDO2/U2F security key (e.g. a YubiKey) to SSH into a remote server \
 \n from WSL.")

 # Only install in a deb
@@ -173,8 +173,8 @@ set(CPACK_DEBIAN_VERSION_SELECTION_SHIM_GROUP_PACKAGE_NAME "windows-fido-bridge"

 set(CPACK_COMPONENT_VERSION_SELECTION_SHIM_GROUP_DESCRIPTION "\
 an OpenSSH security key middleware for WSL (skapi version selection shim) \
-\nwindows-fido-bridge is an OpenSSH security key middleware that allows you \
-\nto use a FIDO2/U2F security key (e.g. a YubiKey) to SSH into a remote server \
+\n windows-fido-bridge is an OpenSSH security key middleware that allows you \
+\n to use a FIDO2/U2F security key (e.g. a YubiKey) to SSH into a remote server \
 \n from WSL.")

 # Only install in a deb

I'll also look into either making the description parsing consistent between CMake versions or, in the worst case, add a conditional to modify the description strings depending on the CMake version.

I'm usually busy during the week, but I'll see if I can find time; if not, I should be able to work on these issues over the weekend.

Unfortunately I don't know enough about the project or Debian packaging to begin to work this out myself, I hope my information helps in some way.

It was helpful, the detailed bug report is greatly appreciated!

[Erisa]

That all makes sense, thank you for the explanation! I can confirm applying that patch fixes make package and installing the debs on buster with ssh from backports.

I realise now that installing both sk packages wouldn't work, that's my mistake, I was experimenting with different things (Like pulling in the packages it said was missing), apparently i missed the part where it said "or". Should be good to go with new packages targeting buster from what I can see!

I'm usually busy during the week, but I'll see if I can find time; if not, I should be able to work on these issues over the weekend.

That's alright, there isn't any real rush!

[mgbowen]

I pushed a commit that should fix builds on CMake < 3.16, which also should make CMake in buster compile with no changes. Will work on getting buster-backports instructions into the wiki and builds into apt.mgbowen.dev.