t***@quarendon.net
2017-05-02 10:30:01 UTC
The JSCH client produces an identification string of:
SSH-2.0-JSCH-<version>
According to the SSH transport layer protocol spec (RFC 4253):
"This identification string MUST be
SSH-protoversion-softwareversion SP comments CR LF
...
Both the 'protoversion' and 'softwareversion' strings MUST consist of
printable US-ASCII characters, with the exception of whitespace
characters and the minus sign (-).
"
So according the strict interpretation of RFC 4253, "JSCH-<version>" isn't a valid software_version string, and it should be "JSCH_<version>" (underscore instead of dash).
Clearly ssh daemons aren't in the habit of checking this!
This is probably already known, and it's a minor issue. It's also unclear how easy it would be to change (potentially causing incompatibilities).
Anyway, just thought I'd comment in case this is considered a bigger issue?
Thanks.
SSH-2.0-JSCH-<version>
According to the SSH transport layer protocol spec (RFC 4253):
"This identification string MUST be
SSH-protoversion-softwareversion SP comments CR LF
...
Both the 'protoversion' and 'softwareversion' strings MUST consist of
printable US-ASCII characters, with the exception of whitespace
characters and the minus sign (-).
"
So according the strict interpretation of RFC 4253, "JSCH-<version>" isn't a valid software_version string, and it should be "JSCH_<version>" (underscore instead of dash).
Clearly ssh daemons aren't in the habit of checking this!
This is probably already known, and it's a minor issue. It's also unclear how easy it would be to change (potentially causing incompatibilities).
Anyway, just thought I'd comment in case this is considered a bigger issue?
Thanks.