Solaris

Out of curiosity, did they tell you why you need to do this?
In my experience with audits (which is 2 audits in all my years doing this), when something has been recommended, the onus has been put on the auditors to tell us why it is needed, how can we accomplish it, and what guarantee they can give us that it will not break anything in our system.

Anyway, for easy fixes that don't require recompiling or messing around with the sshd binary, you could:
- Block telnet to port 22.
- Change the port sshd listens on.
- Comment telnet out of inet.conf and HUP inetd

A general comment: this is one of those things that I cannot understand about these "security experts". They want SAs to mess around with ssh, but they don't mind that telnet is running. If I'm a hacker, and I'm already inside your network, why would I want to mess around with the encrypted stuff when I have clear text flowing through the wire?

Isn't it obvious? One of the matrix movies had a character using an ssh exploit to hack some power station. Suddenly ssh is the prime target for all auditors Yay.

But seriously, most audits should result in either complience or a reason why not to. I'd say system stability when compared to the releivly low increase in risk by displaying that information is a pretty good reason.

yeah I intend to change the port to something else, let those "experts" sniff it out and when they do I'll change it again. Blocking telnet to port 22 won't help much, those guys are using netcat tools.

anyway thanx for the suggestions.

Some of the exploits out there are targeting specific versions of ssh. This is why I think it is important to hide services' version.

ok...
there aren't that many versions of ssh out there. So there are some exploits that work on some and not on others...
ok...

Question 1: if you have an ssh version that is vulnerable to a particular exploit, how do you make it more secure?
a) hide the name
b) patch/upgrade ssh to remove the vulnerability

Question 2 : If I'm a hacker, and I see a) renamed version - my exploit for that version is not working- or b) a name that makes no sense, what's the first thing that comes into my mind? "Hey, they have a vulnerability they are trying to hide but haven't patched yet!!"

Question 3: wouldn't it make more sense to either stop telnet or deny telnet to the ssh port, rather than advertise to everyone that you have a vulnerability that you have not addressed properly by attempting to disguise it?

Question 4: again, if I'm a hacker, and I'm in your network, if I know telnet is enabled, why would I want to mess with the encrypted stuff when you are sending plain ascii packets across the network?

To answer question 3) en 4).

Someone from the outside is using telnet, and clearly you can't disable telnet on his/her machine.

Furthermore, initially SSH will see no difference between a real ssh connecting or a telnet session on port 22.

To come up with the most simple answer.

If according to the auditors the SSH version should be made hidden, why they dont tell you how to do it if they consider it possible?