Feature request: new parser sshd -T #282
Comments
|
Hey thanks for the suggestion and analysis! I'm working on /proc files for the next release but I'll take a look at this, too. |
|
Thanks! One other thought, support for ssh -Q ciphers
3des-cbc
aes128-cbc
aes192-cbc
aes256-cbc
aes128-ctr
aes192-ctr
aes256-ctr
aes128-gcm@openssh.com
aes256-gcm@openssh.com
chacha20-poly1305@openssh.comAnd compare it with the enabled ciphers using However perhaps a special parser isn't needed when the output is a simple list of items, one per line, is there a already a suitable parser for output like this? |
|
Yeah I prob wouldn’t write a parser for a list of items. K/v pairs at the minimum. |
|
Perhaps treating all the results as key / value pairs, seperated at the first space, with one exception for hostkey1: /etc/ssh/ssh_host_ecdsa_key
hostkey2: /etc/ssh/ssh_host_ed25519_key
hostkey3: /etc/ssh/ssh_host_rsa_keyWould probably be the easiest and perhaps the most sensible thing to do, leave other tools to seperate values into lists and decide if something could be a boolean or a string. |
|
I've just discovered the banner:
comments: null
protocol:
- 2
- 0
raw: SSH-2.0-babeld-81baa361
software: babeld-81baa361
compression:
- none
- zlib@openssh.com
- zlib
enc:
- chacha20-poly1305@openssh.com
- aes256-gcm@openssh.com
- aes128-gcm@openssh.com
- aes256-ctr
- aes192-ctr
- aes128-ctr
fingerprints:
- hash: +DiY3wvvV6TuJJhbpZisF/zLDA0zPMSvHdkr4UvCOqU
hash_alg: SHA256
hostkey: ssh-ed25519
- hash: 65:96:2d:fc:e8:d5:a9:11:64:0c:0f:ea:00:6e:5b:bd
hash_alg: MD5
hostkey: ssh-ed25519
- hash: nThbg6kXUpJWGl7E1IGOCspRomTxdCARLviKw6E5SY8
hash_alg: SHA256
hostkey: ssh-rsa
- hash: 16:27:ac:a5:76:28:2d:36:63:1b:56:4d:eb:df:a6:48
hash_alg: MD5
hostkey: ssh-rsa
kex:
- algorithm: curve25519-sha256
- algorithm: curve25519-sha256@libssh.org
- algorithm: ecdh-sha2-nistp256
- algorithm: ecdh-sha2-nistp384
- algorithm: ecdh-sha2-nistp521
- algorithm: diffie-hellman-group-exchange-sha256
keysize: 2048
key:
- algorithm: ssh-ed25519
- algorithm: ecdsa-sha2-nistp256
- algorithm: rsa-sha2-512
keysize: 2048
- algorithm: rsa-sha2-256
keysize: 2048
- algorithm: ssh-rsa
keysize: 2048
mac:
- hmac-sha2-512-etm@openssh.com
- hmac-sha2-256-etm@openssh.com
- hmac-sha2-512
- hmac-sha2-256
target: github.comIt can also be run against |
|
Hi Chris! Does it look like we can close this parser request out? |
|
If the Key/Value file parser had support for splitting on the first whitespace character in addition to sshd -T | grep -e "^hostkey "
hostkey /etc/ssh/ssh_host_rsa_key
hostkey /etc/ssh/ssh_host_ecdsa_key
hostkey /etc/ssh/ssh_host_ed25519_keyCould perhaps result in: {
"hostkey1": "/etc/ssh/ssh_host_rsa_key",
"hostkey2": "/etc/ssh/ssh_host_ecdsa_key",
"hostkey3": "/etc/ssh/ssh_host_ed25519_key"
}Then I'd agree that there wouldn't be much point in a special parser. |
|
I just wasn't sure if the Depending on how common that type of file output is I could make a parser called Could even make it more fancy - like when using the --raw option (or vice versa) it could do this: Just spitballing here - not sure if this type of space-delimited output is common enough for its own parser. |
|
The JSON output from In terms of a new |
|
Hi @chriscroome - I have an initial version of the https://github.com/kellyjonbrazil/jc/blob/dev/jc/parsers/sshd_conf.py Here's what it looks like so far: Let me know what you think! |
|
I don't think this version will support sshd_config files that include |
|
This is an example of a Match block from / However I can't remember where I found some examples of the syntax to use when running |
|
No, no luck yet. It should be easy enough to ignore lines that start with |
|
There shouldn't be an issue with Match, with the example block above, if the And the results looks the same as simply for |
|
Yeah, I think that makes sense for From what I've read, you are supposed to put |
|
Ok, I added the logic to ignore the |
|
Sounds good, FWIW my plan is to generate |
|
Can there be multiple |
|
I think I figured out the https://github.com/kellyjonbrazil/jc/blob/dev/jc/parsers/sshd_conf.py |
|
Released in |
This is probably one for the far back-burner or bin @kellyjonbrazil 😄 !
The configuration of an OpenSSH server can be printed using
sshd -T, for example:For a raw JSON version splitting on the first space on each line would be mostly fine, perhaps the Key/Value file parser could have support for splitting on the first space per line added? However that wouldn't work for
HostKeyas only the last value would be left.A dedicated
sshd_configparser could do things like split values at commas and / or spaces into lists, however it isn't quite that simple...For example for Ciphers, HostbasedAcceptedAlgorithms and KexAlgorithms:
Perhaps this could look something this?
Another complication are things like AuthenticationMethods:
None of this initial ideas are great:
Also since YAML / JSON doesn't support ordered lists and the order is critical that could be an issue and I'm not sure that a variable having multiple potential types is a good idea.
In addition the
sshd_configfile uses camel case butsshd -Thas lower case variable names,I don't know if a mapping for this would be a good thing and / or a necessary option?, this isn't something to worry about since the man page forsshd_configstates:Another potential gotcha is that some variables take simply
yes/noas values, like AllowAgentForwarding, so this would perhaps make sense as a boolean rather than a string, however AllowTcpForwarding allowsall,local,no,remoteoryesso this could be a boolean or a string depending on the value, however my preference would probably be for it always to be a string since Ansible role validation only support variables being of one type.To make matters worse there is the Match block, for example in
/etc/ssh/sshd_configyou could have:However allthough you can get the resulting configuration for a user using
sshd -T -C user=foothe results are still in the same flat format and theMatchdirective is never printed.Perhaps a JC
sshd_configparser isn't a practical suggestion... in any case the full list of configuration options are here.The text was updated successfully, but these errors were encountered: