Linux - SoftwareThis forum is for Software issues.
Having a problem installing a new program? Want to know which application is best for the job? Post your question in this forum.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
I have the stock version (updated) of ssh/sshd installed on a centos 5.2 server, ssh 4.3p2. After upgrading to openssh-5.2p1 via an rpm package, and restarting sshd, the server reports sshd 5.2p1 (sshd -v and ssh -v). If I run nmap against this server, however, it reports OpenSSH 4.3. If I telnet in to this server on port 22, it comes back SSH-2.0-OpenSSH_4.3, matching what nmap is reporting.
When I do a similar upgrade of Apache (except via source), nmap correctly reports the new version of Apache, 2.2.11.
Thus, when my third party scans are performed, it appears that I have not upgraded ssh.
Must I first uninstall ssh, then install it, in order to get the correct header information returned (assuming this works)? Or is there an alternative?
The version is inside the file "version.h" inside the source package. Too change it you need to recompile openssh and reinstall it. A tips is too change it, though. It reduces the information that attackers can gather from your server. If they know which version you have, they can better check for security holes. Changing the response can confuse automated scripts and make a lot of difference security-wise.
A tips is too change it, though. It reduces the information that attackers can gather from your server. If they know which version you have, they can better check for security holes. Changing the response can confuse automated scripts and make a lot of difference security-wise.
I would strongly argue against changing it because that is what you'd call "security by obscurity" (which does not enhance security at all) and OpenSSH clients rely on the right version string being supplied by the daemon. Instead invest in hardening the machine and strenghtening auditing and access controls. See http://www.linuxquestions.org/questi...tempts-340366/ for a roundup wrt SSH.
My intention was not to alter the version reported from what it actual is, but correctly report it to scans. I ended up removing ssh 4.3 and re-compiling 5.2, now it reports correctly. Thanks.
My intention was not to alter the version reported from what it actual is, but correctly report it to scans. I ended up removing ssh 4.3 and re-compiling 5.2, now it reports correctly. Thanks.
My point was that you _should_ alter it to report something else, or to not report the version number at all.
I do not see the point in that argument. Why would you want people to know the version number of the software you run anyway? Just remove all the info and at least you'll get rid of the script kiddies. Of course better hackers will be able to figure stuff out anyway but that's not the point.
I cannot see a general case in which you actually need to announce the version of the software. Please, enlighten me.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.