bug: `ssh.matchBlocks` with `dag.entryBefore` or `dag.entryAfter` ignore order when glob is in name(s)

[S0AndS0]

Are you following the right branch?

• My Nixpkgs and Home Manager versions are in sync

Is there an existing issue for this?

• I have searched the existing issues

Issue description

modules/programs/ssh.nix provides example/docs of;

      example = literalExpression ''
        {
          "john.example.com" = {
            hostname = "example.com";
            user = "john";
          };
          foo = lib.hm.dag.entryBefore ["john.example.com"] {
            hostname = "example.com";
            identityFile = "/home/john/.ssh/foo_rsa";
          };
        };
      '';

... but attempting to use lib.hm.dag.entryBefore, or the entryAfter, with globs results in ordering intent being ignored, ex.

  programs.ssh = {
    enable = true;

    enableDefaultConfig = false;
    matchBlocks = {
      "*" = {
        forwardAgent = false;
        serverAliveInterval = 0;
        serverAliveCountMax = 3;
        compression = false;
        addKeysToAgent = "no";
        hashKnownHosts = false;
        userKnownHostsFile = "~/.ssh/known_hosts";
        controlMaster = "no";
        controlPath = "~/.ssh/master-%r@%n:%p";
        controlPersist = "no";
      };

      "tor-*" = lib.hm.dag.entryAfter ["*"] {
        proxyCommand = "${pkgs.socat} STDIO SOCKS4A:127.0.0.1:%h:%p,socksport=9050";
        addressFamily = "inet";
        compression = true;
      };
    };
  };

Which results in configurations that are not correctly ordered, ex.

Host tor-*
  AddressFamily inet
  Compression yes
  ProxyCommand /nix/store/yix90k1p75kd7id215ljfbz2j1zqbcsh-socat-1.8.0.3 STDIO SOCKS4A:127.0.0.1:%h:%p,socksport=9050

Host *
  ForwardAgent no
  ServerAliveInterval 0
  ServerAliveCountMax 3
  Compression no
  AddKeysToAgent no
  HashKnownHosts no
  UserKnownHostsFile ~/.ssh/known_hosts
  ControlMaster no
  ControlPath ~/.ssh/master-%r@%n:%p
  ControlPersist no

I've also tried defining entryBefore on the top-level glob, and a combo of the two too;

   programs.ssh = {
     enable = true;
 
     enableDefaultConfig = false;
     matchBlocks = {
-      "*" = {
+      "*" = lib.hm.dag.entryBefore ["tor-*"] {
         # ...
       };
 
-      "tor-*" = lib.hm.dag.entryAfter ["*"] {
+      "tor-*" = {
         # ...
       };
     };
   };

... but no joy with that either.

Maintainer CC

@rycee

System information

- system: `"x86_64-linux"`
 - host os: `Linux 6.16.1, NixOS, 25.11 (Xantusia), 25.11.20250902.d0fc308`
 - multi-user?: `yes`
 - sandbox: `yes`
 - version: `nix-env (Nix) 2.28.4`
 - channels(root): `"home-manager-25.05.tar.gz, nixos-25.05, nixos-hardware"`
 - nixpkgs: `/nix/store/8vfhnwmmzqqzy97q9c5m4bzyaqqf63zy-source`

[khaneliman]

Attribute sets don't maintain order, we'd need the option to be a list of attributes to maintain order.

Sorry, just skimmed email and replied.

[aguirre-matteo]

This occurs because of #7655, since now the module ensures the Host * block is always at the bottom of the config. This shouldn't be a problem since any other block after Host * would never be reached. I think the example you pointed out just doesn't make any sense.

[S0AndS0]

This occurs because of #7655, since now the module ensures the Host * block is always at the bottom of the config. This shouldn't be a problem since any other block after Host * would never be reached. I think the example you pointed out just doesn't make any sense.

Thanks for pointing me at the changes!... I was following along with making recent warnings go away and thought I may be going a bit batty x-)

As for making better sense; order, last I checked is very important for configs that modify configs, here be a slimmer example of issue;

Host tor-*
  Compression yes
Host *
  Compression no

vs

Host *
  Compression no
Host tor-*
  Compression yes

... doing an ssh tor-some-host with the first one would result in no compression, where as in the second (ideal) case it'd result in yes compression.

[S0AndS0]

Attribute sets don't maintain order, we'd need the option to be a list of attributes to maintain order.

Uh, I thought that was what the lib.hm.dag.entryBefore ["<target>"] was for, and its counter part entryAfter, both of which seem to work when generic glob ("*") ain't in the mix

[aguirre-matteo]

Attribute sets don't maintain order, we'd need the option to be a list of attributes to maintain order.

Uh, I thought that was what the lib.hm.dag.entryBefore ["<target>"] was for, and its counter part entryAfter, both of which seem to work when generic glob ("*") ain't in the mix

Yeah, the option is actually a DAG, see my comment in your PR.

[aguirre-matteo]

This occurs because of #7655, since now the module ensures the Host * block is always at the bottom of the config. This shouldn't be a problem since any other block after Host * would never be reached. I think the example you pointed out just doesn't make any sense.

Thanks for pointing me at the changes!... I was following along with making recent warnings go away and thought I may be going a bit batty x-)

As for making better sense; order, last I checked is very important for configs that modify configs, here be a slimmer example of issue;

Host tor-*
Compression yes
Host *
Compression no

vs

Host *
Compression no
Host tor-*
Compression yes

... doing an ssh tor-some-host with the first one would result in no compression, where as in the second (ideal) case it'd result in yes compression.

Sorry but I don't get it, why would SSH use compression no in the first cfg, and compression yes in the second cfg? Or did you mean to say the opposite?

[S0AndS0]

This occurs because of #7655, since now the module ensures the Host * block is always at the bottom of the config. This shouldn't be a problem since any other block after Host * would never be reached. I think the example you pointed out just doesn't make any sense.

Thanks for pointing me at the changes!... I was following along with making recent warnings go away and thought I may be going a bit batty x-)
As for making better sense; order, last I checked is very important for configs that modify configs, here be a slimmer example of issue;
Host tor-*
Compression yes
Host *
Compression no
vs
Host *
Compression no
Host tor-*
Compression yes
... doing an ssh tor-some-host with the first one would result in no compression, where as in the second (ideal) case it'd result in yes compression.

Sorry but I don't get it, why would SSH use compression no in the first cfg, and compression yes in the second cfg? Or did you mean to say the opposite?

🤦 I just checked with ssh -G tor-host and seems I was wrong about how things are overridden!... err, at least for ssh -V resulting in OpenSSH_10.0p2, OpenSSL 3.5.2 5 Aug 2025

To clarify the intent is/was to have compression off by default, but selectively on for known slow connections, and it looks like having Host * at the end does this... darn strange because I could've sworn it was the other way 'round before.

[aguirre-matteo]

🤦 I just checked with ssh -G tor-host and seems I was wrong about how things are overridden!... err, at least for ssh -V resulting in OpenSSH_10.0p2, OpenSSL 3.5.2 5 Aug 2025

To clarify the intent is/was to have compression off by default, but selectively on for known slow connections, and it looks like having Host * at the end does this... darn strange because I could've sworn it was the other way 'round before.

Yeah, I understood a few moments before what the idea was. Anyways, IMO we should allow adding entries after Host * but we force the module to put that block at the end because of extraConfig. Ideally we should get rid of that option and allow users to order the blocks the way they want.

EDIT: Link to the full discussion.

[S0AndS0]

Yeah, I understood a few moments before what the idea was. Anyways, IMO we should allow adding entries after Host * but we force the module to put that block at the end because of extraConfig. Ideally we should get rid of that option and allow users to order the blocks the way they want.

EDIT: Link to the full discussion.

Heh, ah thanks for explaining that it is intended behavior!

Looks like the sortedMatchBlocks = lib.hm.dag.topoSort (lib.removeAttrs cfg.matchBlocks [ "*" ]) line is where it Host * starts getting the special treatment... is there a reason, like dag not ordering things as instructed for "*", or would it be okay for me to submit a PR that removes it and related extra logic?

[aguirre-matteo]

As long as extraConfig exists, we shouldn't remove the special treatment for the Host * block, since otherwise this could break existing configs, because the original module ensured that extraConfig was placed after Host *. The only reason that was done was to prevent breaking users' configurations.