git: Bad configuration option: gssapikexalgorithms (on Fedora)

[kfajdsl]

Describe the bug

On Fedora 35, the nixpkgs git fails trying to clone git repositories with SSH with the following error:

/etc/crypto-policies/back-ends/openssh.config: line 3: Bad configuration option: gssapikexalgorithms
/etc/crypto-policies/back-ends/openssh.config: terminating, 1 bad configuration options
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.

The config line in question (in /etc/crypto-policies/back-ends/openssh.config):

GSSAPIKexAlgorithms gss-curve25519-sha256-,gss-nistp256-sha256-,gss-group14-sha256-,gss-group16-sha512-

This is a Fedora default (I believe). When this line is commented out, git clone git@gitlab.com:my_org/my_repo.git works as expected. The git packaged in the Fedora repos works without the line commented out.

p.s.
I found this issue when trying to use vcstool from nix (inside nix develop). vcstool from the Fedora repos works fine. As a workaround, I've commented out vcstool from my nativeBuildInputs and am using my system vcstool.

p.p.s
Somewhat interesting behavior:
If git is in my flake.nix (which git returns a /nix/store path), my system vcstool also breaks. The nixpkgs vcstool doesn't work regardless.

Steps To Reproduce

Steps to reproduce the behavior:

1. Install nix on Fedora 35
2. nix-shell '<nixpkgs>' -p git
3. git clone git@gitlab.com/my_org/my_repo.git

Expected behavior

The repository is successfully cloned.

Notify maintainers

@primeos
@wmertens
@globin

Metadata

 - system: `"x86_64-linux"`
 - host os: `Linux 5.16.8-200.fc35.x86_64, Fedora Linux, 35 (Workstation Edition)`
 - multi-user?: `no`
 - sandbox: `yes`
 - version: `nix-env (Nix) 2.7.0pre20220127_558c4ee`
 - channels(sahan): `"nixgl, nixpkgs-22.05pre350399.a529f0c125a"`
 - nixpkgs: `/home/sahan/.nix-defexpr/channels/nixpkgs`

[Artturin]

i grepped the source of git and openssh but found nothing so i grepped the fedora openssh rpm and found that there's couple of patches that add GSSAPIKexAlgorithms (just search gssapi on the rpm page)

also searched the issues for GSSAPIKexAlgorithms #58132 (comment)

export GIT_SSH="/usr/bin/ssh" please try adding this line to your shell's rc and relogging and testing if it works

[wmertens]

The problem is probably that our openssh reads /etc for configuration. Maybe it shouldn't do that?

[primeos]

In Nixpkgs we have openssh and openssh_gssapi (amongst others). The default SSH package (openssh) doesn't support GSSAPI (IIRC and this issue seems to confirm it). IMO the problem is that the Nix package for Git hard-codes the SSH binary instead of discovering it via path. IMO we shouldn't do that (mainly as there are different SSH packages) but I do see the appeal under some circumstances (I haven't thought a lot about the advantages and drawbacks though). Not sure how others feel about that. An alternative could be to wrap the git binary and suffix (not prefix) $PATH (but that comes with other issues).

Currently we use https://github.com/NixOS/nixpkgs/blob/85d5d37f7c98c13b14a810377f16ecd692129979/pkgs/applications/version-management/git-and-tools/git/ssh-path.patch and

nixpkgs/pkgs/applications/version-management/git-and-tools/git/default.nix

Lines 60 to 63 in 85d5d37

	for x in connect.c git-gui/lib/remote_add.tcl ; do
	substituteInPlace "$x" \
	--subst-var-by ssh "${openssh}/bin/ssh"
	done

That part was added in 6579acd (cc @zimbatm).

@kfajdsl for your case one of the following workarounds should work:

• $GIT_SSH (git: Bad configuration option: gssapikexalgorithms (on Fedora) #160527 (comment))
• Modifying /etc/crypto-policies/back-ends/openssh.config (as you already discovered it)
• Using overlays or something like (git.override { openssh = openssh_gssapi; }) (not tested, likely contains some typos, etc.).

[yajo]

Using overlays or something like (git.override { openssh = openssh_gssapi; }) (not tested, likely contains some typos, etc.).

I tried this and it fails because the package is insecure. Any clues on how to fix that (I'm on a nix flake, so exported variables don't work):

> nix develop
error: Package ‘openssh-with-gssapi-8.4p1’ in /nix/store/n405zwzcpb3mjxb2ml484nq8vwrn2aph-source/pkgs/tools/networking/openssh/common.nix:164 is marked as insecure, refusing to evaluate.


       Known issues:
        - CVE-2021-28041
        - CVE-2021-41617

       You can install it anyway by allowing this package, using the
       following methods:

       a) To temporarily allow all insecure packages, you can use an environment
          variable for a single invocation of the nix tools:

            $ export NIXPKGS_ALLOW_INSECURE=1

        Note: For `nix shell`, `nix build`, `nix develop` or any other Nix 2.4+
        (Flake) command, `--impure` must be passed in order to read this
        environment variable.

       b) for `nixos-rebuild` you can add ‘openssh-with-gssapi-8.4p1’ to
          `nixpkgs.config.permittedInsecurePackages` in the configuration.nix,
          like so:

            {
              nixpkgs.config.permittedInsecurePackages = [
                "openssh-with-gssapi-8.4p1"
              ];
            }

       c) For `nix-env`, `nix-build`, `nix-shell` or any other Nix command you can add
          ‘openssh-with-gssapi-8.4p1’ to `permittedInsecurePackages` in
          ~/.config/nixpkgs/config.nix, like so:

            {
              permittedInsecurePackages = [
                "openssh-with-gssapi-8.4p1"
              ];
            }
(use '--show-trace' to show detailed location information)

[primeos]

#166334 partially solves this issue (except for gitFull). Let's close this issue then (unless there's something actionable left).

[NoraCodes]

I still have the problem when using Morph. Had to edit /etc/ssh/ssh_config.d/50-redhat.confto be able to deploy.

[matta]

FYI this issue still occurs for me when I use pkgs.gitFull on Fedora 35, but pkgs.git works okay. Baffling behavior for a novice user like me. :-)

Problem is, I do occasionally need git send-email so I think I need pkgs.gitFull if I'm going to use Nix's git. I worked around this by not using Nix's git, reluctantly.