ssh config settings outside of a Host block show a warning and fail

[morbeo]

When directives are present that are outside of a Host block a warning is shown and the program exits with status code 1.
I have the following at the top of my ssh config file:

PermitLocalCommand yes
Include config.d/*

and some hosts

$ grep -c -w ^Host ~/.ssh/config
16

but I am getting the following warning unless I comment the first two settings

$ uvx --from sshclick sshc hosts
WARNING:root:Config info without Host definition on SSH-config line number 0

$ head -2 ~/.ssh/config
#PermitLocalCommand yes
#Include config.d/*

$ uvx --from sshclick sshc hosts
┌──────┬─────────┬────────┬────────────────┬────────────┐
│ name │ group   │ type   │ param:hostname │ param:user │
├──────┼─────────┼────────┼────────────────┼────────────┤
│ g    │ default │ normal │ ***            │ root       │
│ am   │ default │ normal │ ***            │ root       │
...

[karlot]

Hi,
In your case, here we have basically 2 different issues.

1. Handling of global keywords (PermitLocalCommand) without prior definition of Host xxxx

From what I understand, if this is defined like that, it is applied for all hosts that are defined below this line, unless of course more specific Host definition is matches by "pattern" or explicit name/fqdn, and that one specifically overrides the argument.

This can be also achieved same way by defining it like this at the top of the ssh config:

Host *
    PermitLocalCommand yes
...

This would result with same behavior and sshclick will be able to parse it normally, and also when viewing host details present all those "inherited" attributes when establishing connection.
This also seems to me as more "explicit" approach in my view

Regarding support for such "host-less" config attributes, since they are supported by current clients, I will consider how to integrate that into the features for next releases...

2. Include keyword

This one was on my radar from the beginning, and I still don't have good idea how to approach it...
It is really not a problem to follow "include" directives and slurp other config files.
Also the problem is not displaying it once it is all parsed and ready for printing or displaying in TUI mode...

For me problem is then how to optimally approach adding/editing configurations, and re-rendering configurations.
Which file should be updated, and under what rules. How to distinct what goes into what file... should it be based only on initial read? Should sshc or ssht interfaces be allowed to "move" hosts or groups between files?
I think all this is possible, but it would require a lot more code and time. :D

If you have any proposals how to approach it, I'm open for ideas and discussions.

[morbeo]

I already have a generalized Host * at the bottom of the file. I was keeping this preamble for Canonicalization rules which I no longer use. You are correct that PermitLocalCommand can be moved to Host *. I would rather keep the include on top though.

On the support of includes - you already have SSH_Config to parse files. I guess they need to be loaded in some tree or DAG and make the hosts and groups aware of their own source.

[karlot]

In terms of "includes" you are right, I fully support it being on top for clarity, as openssh clients (ssh, sftp, etc...) treats this keyword similary like C pre-processor... basically when this line is reached, it is during processing just replaced with content of linked files.

This makes pure ssh config very flexible in use, such as adding bunch of common Keyword/Args pairs to separate file, and then in main file use Include keyword to load common args to multiple Host definitions.

[yawor]

For me problem is then how to optimally approach adding/editing configurations, and re-rendering configurations.
Which file should be updated, and under what rules. How to distinct what goes into what file... should it be based only on initial read? Should sshc or ssht interfaces be allowed to "move" hosts or groups between files?
I think all this is possible, but it would require a lot more code and time. :D

You could just have a read only mode when Include is found while parsing the config file. In this mode user would just be able to read the configuration and launch connections, but would not be able to edit the configuration through the sshclick. This would be the quickest workaround so people can still use Include and sshclick together in some capacity.

[karlot]

For me problem is then how to optimally approach adding/editing configurations, and re-rendering configurations.
Which file should be updated, and under what rules. How to distinct what goes into what file... should it be based only on initial read? Should sshc or ssht interfaces be allowed to "move" hosts or groups between files?
I think all this is possible, but it would require a lot more code and time. :D

You could just have a read only mode when Include is found while parsing the config file. In this mode user would just be able to read the configuration and launch connections, but would not be able to edit the configuration through the sshclick. This would be the quickest workaround so people can still use Include and sshclick together in some capacity.

That's actually good approach for intermediate solution. I'll add that in next patch probably

[luocfprime]

Same issue here too.

Example with Orbstack:

 # Added by OrbStack: 'orb' SSH host for Linux machines
 # This only works if it's at the top of ssh_config (before any Host blocks).
 # This won't be added again if you remove it.
 Include ~/.orbstack/ssh/config

Running sshc hosts yields

❯ sshc hosts
WARNING:root:Config info without Host definition on SSH-config line number 3

[tkapias]

You could just have a read only mode when Include is found while parsing the config file. In this mode user would just be able to read the configuration and launch connections, but would not be able to edit the configuration through the sshclick. This would be the quickest workaround so people can still use Include and sshclick together in some capacity.

That's actually good approach for intermediate solution. I'll add that in next patch probably

I'd like to bring this idea up again, if you have the time.

Currently I use the main config only for defaults and a separate sshclick file in include.

Also, I use a bash alias for sshc and ssht with the sshclick config file in include.

But, a parse+read_only solution by default and an alias with a specific config file when you want to make updates would be nice as a more or less temporary solution.