SSH Config parsing is very limited
Opened this issue · 10 comments
UPD 2025-06-09: now that we have support for external ssh binary, this one should be a lot less of an issue: just run nerdlog with --set 'transport=ssh-bin', and it'll use the external binary which will utiilze all your configs properly.
The only remaining thing is that, because Include is not supported as mentioned below, glob expansion on Nerdlog side might not work as you expect, but that one should be relatively easy to address.
I'll keep the original text below as it was:
Nerdlog uses https://github.com/kevinburke/ssh_config to parse ssh config, and that library unfortunately has some major limitations; the two biggest ones are:
Includeisn't supported: kevinburke/ssh_config#30Matchisn't supported: kevinburke/ssh_config#6
Hi,
I agree, it's too limited, when using jumphost and pkcs11 providers for SSH connection, it's impossible.
Hi,
I think this can be a great idea ; to be tried ...
And, how to handle the "sudo calls" for access certains logs files ?
I think this can be a great idea ; to be tried ...
If I'm lucky, I'll try to implement it on the weekend.
And, how to handle the "sudo calls" for access certains logs files ?
Do these docs help?
Yes, it work only with a "simple" client/server configuration with one file for client AND a server that allow password auth AND with direct ssh access (no jump).
I've tried with "lab" server with theses conditions and it seem, this tools is awesome and very usefull.
But in real life, this case doesn't exist anymore... if this tool is run from computer, but on a ansible controller, it can be different, in most case ssh access is direct and with pwd or pubkey. Yes, thats still dangerous.
I've tried to dump ssh_config (because splitted in multiple files) with a single proxyjump auth by pubkey file, to have in the same file (concat), the bastion and the destination server.
ssh -G bastion1 | tee ssh_pilot1 && ssh -G pilot1 | tee -a ssh_pilot1
nerdlog --lstreams-config logstreams.yaml --ssh-config ssh_pilot1 --lstreams pilot1
It seem work, but pilot1: attempt 1: using ssh-agent: dial tcp 192.168.175.191:22: i/o timeout
ssh agent is loaded with the keys used in the ssh_config dumped
... AND a server that allow password auth
Actually, password auth is not supported, auth has to be either via agent, or pubkeys.
Regarding the rest, yes you're right.
But in real life, this case doesn't exist anymore...
That is a strong statement though. It does exist e.g. in my case.
But I agree it's too simplistic and should be improved, to support more complex configurations.
It seem work, but pilot1: attempt 1: using ssh-agent: dial tcp 192.168.175.191:22: i/o timeout
ssh agent is loaded with the keys used in the ssh_config dumped
It's difficult to debug having this info. Clearly it fails to dial 192.168.175.191 on the port 22. I don't think it's a problem with Nerdlog tbh.
Anyway, I think the most sensible approach for you here is to just wait until external ssh is supported; it'll hopefully address all the connection issues that you're having. As mentioned before, I hope to get it done on the weekend.
I made a big mistake, i use lab VMs with poor sshd_config with multiple listen port and multiple matching rules depending port/user/group that totally make my results wrongs... and stranges others configs.
I'll kill them and redeploy them with the default sshd_config.
In this lab :
- client1, is 192.168.70.31/24
- bastion1, is 192.168.175.41 and client1 can access to 22/tcp
- pilot1, is the lab vm, 192.168.175.191 and accessible from bastion1, not from client1
I'll wait your next release with external ssh. During this time, i'll redploy a lab from scratch, this is necessary.
Hi @dginhoux , so using an external ssh binary is now supported in 1.10.0, could you try it out by upgrading Nerdlog, and running it with --set 'transport=ssh-bin'?
(It will hopefully be the default at some point, but for now playing it safe and waiting for some testing first)