This patch allows one to change the software version and comment field(s) in the identification string. The ident strings is of the form "SSH-protoversion-softwareversion comments" as per draft-ietf-secsh-transport-11.txt. The identstring still conforms to the spec. But there could be a possibilty of some sompatability issues. But that should be up to the user/administrator They are of the form VersionString "My_Version_1.0" CommentString "test" in sshd_config
Created attachment 17 [details] Patch to sshd to allow a userdefinable identification string
The identity string is used for bug/feature compatibility. As the protocol spec is not an RFC yet, it may also be needed in future. Have a look at compat.c
i don't see why the version string should be changed. it's used for bug-detection. if we are bug free, then we can have a fixed version string.
The word is *if*. Secondly. I have had requests from some of my clients for the ability to change both the version and comment string(s). The version string for the sole purpose of hiding the version in the event of a security hole. Similarly to the way say bind or sendmail does. If other standards do why no openssh. As for the comment string this is not that all far fetched. I have the need to put information about an installation(i.e. internal version number, say for a companies internal package version. or for describing additional options.. gssapi?). In large environments it is hard to keep everything machine up to date. Let alone making a perfect installation. So one can have used openssh 3.0.2p1 but had multiple revisions of the package. And a quick way to audit said installation(s) would be to look at the comment field. And then use something like scanssh to gather the information.
why should we encourage people to run a broken version of openssh? why not edit version.h and include this information at compile time? if you have a revision of your modified sshd you will have to recompile anyway. changing version.h will possibly break compatibility.
>why should we encourage people to run a broken version of openssh? Why do you think it is broken?.. or is the compatibility handling just broken. > why not edit version.h and include this information at compile time? Why do you have to recompile?? That is where the term "runtime options" comes from. Fine. We disagree with the version string. But, the comment should be at least user configurable. >if you have a revision of your modified sshd you will have to recompile anyway. No... who says that you can't change just the config files and make a new package?
I agree that the "version" string would/could cause problems with compatability. So I will drop the "version" string. The comment is another matter. What are your thoughts on generalizing the compat stuff.. maybe making it runtime and not compile time?
i don't understand how moving compat.c would simplify the code or simplify handling. i prefer each version of openssh have a fixed and defined behaviour.
This patch adds obscurity at best, it doesn't help security at all. In fact, it encourages people not to upgrade their vulnerable servers. The attackers won't care about a faked version - they'll just try their exploits regardless (in fact weird protocol ident strings would make me more interested). On top of this, it ruins any chance of being able to interop should we find protocol bugs or if the wire spec changes again. Making the compat stuff runtime may be a good idea for other reasons, but not to support silly hacks like this.
after some discussion we decided that this wont happen.
Mass change of RESOLVED bugs to CLOSED