does anyone know if is it possible to configure sshd to not respond to a completed tcp connection with its version?

i would prefer it if the ssh client was responsible for giving the server its ssh version, and keeping the server silent about its version.

to me, it seems more appropriate for the client to be the one to take the initiative here.
would the current implementation of ssh fail if this were done?

thanks

-RockCrusha

I'm not sure what the point of not broadcasting the Version would be. Afterall, all a hacker would have to do is write a partial client that attempted to start a connection with a bunch of different versions to see what it would allow and then they could figure out what you were running anyway. So long as you specify Protocol 2 and not Protocol 1,2 in your sshd_config file you should be ok security wise.

jtshaw-

reason i'm asking is partially for security and partially due to feasability considerations for a devel project idea WestAnnex is kicking around.

one loose requirement for the project is that the protocol should not depend on the server offering information, and therefore it's a fairly critical point. we can get around the problem if the protocol (like ssh) does depend on servers volunteering, but it's less desirable.

On the security note, chatty servers just roll over and give up the goods. From my perspective, fingerprinting server versions and whatnot shouldn't be that easy.

ssh protocol support is totally different. ssh itself will downgrade to comply with whatever's works, sure...but why do you need the sshd version number. Why does the server itself need to give that up without being asked, or even identify itself as an ssh server.

example. if i want to run ssh on port 443, i wouldn't like a simple netcat to give away what's really there. I'll acknowledge that with a little work (trying tools one after another, or simply pretending to be that tool) will eventually reveal the nature of the server listening on that port....but isn't that better than just giving it up? isn't that even more detectable? if i'm running a server on a different port...shouldn't desired clients already know what port its running on?

also consider how much time it would add to a hacker's attack if that process had to be followed for every host and every port.

philosophically, i'm not sure a server should be proactive in identifying itself. i believe they should simply act on what is given them by the client.

-RockCrusha

I see what your saying... I'm not sure that the ssh protocol really needs the broadcast either...

but can the version broadcast be disabled without breaking it?

i read several man pages...didn't see the option to disable (maybe i missed it?)

that's what i really want to know...

-RockCrusha

wanna change your vote?

/me is a jackass

I just editing sshd.c and recompiled my ssh server so it at least doesn't spit out the version number and ssh couldn't connect to it anymore.... I'm going to play with a bit but it seams that the client does expect to get the version information for some reason.

EDIT:
Ok, I have tried replying nothing, SSH-2.0, and SSH-2.0-OpenSSH as the version reply strings. Nothing and SSH-2.0 didn't work, but SSH-2.0-OpenSSH with no OpenSSH version number did work. The client won't continue on if the server is silient....

that sounds about right. someone sent me this link:

http://lists.freebsd.org/pipermail/f...ne/049930.html

can you change it so that the client identifies itself to the server first?

essentially that's what i want...servers not giving up unsolicited information. All the client would have to do is give the server a valid OpenSSH version formatted string to get the server's response.

-RockCrusha

It would take about two seconds to make that change.. the problem is you'd break compatibility with regular ssh clients and servers...

i see. That's great. in other words, a really simple patch could be made that would switch that up.

personally, if it functions the same, i think it should be changed permanently.

EDIT:
and actually, would the server necessarily break if all the clients immediately send version info upon a successful tcp handshake? i mean. would a legacy server bonk if it wound up receiving the client's info before it was able to send its own out? if that isn't the case, then all the clients would have to add the patch for compatibility reasons, but the legacy servers may still function normally if they're threaded to receive out of order.

regardless, having a more 'covert' ssh server/client like that is highly desirable. i know at least that i'd use it

-RockCrusha

well yes i think that would break it. The server is expecting you to send it the version you can use after it does. so it needs that info after it sends in order to know what versioning/encrypting to do. if you sent it your version before it sent its version to you and did not resend it i believe the server would take whatever info it received next as the version. and probably not accept the session. it all depends on how it's threaded and buffered i guess. but i'd be willing to bet that the sequence is important. try it is always the answer...or inspect the code. but i really think in order to get a silent server and a more chatty client you'd have to adjust both. and unless it was accepted into openssh devel or their protocol no one else will be able to connect. but maybe that's what you want in the first place.

bassdemon

yeah, it's no problem for me if unpatched ssh clients can't connect to my server.
i just want the option to have a silent server and a chatty client.

definitely worth looking into that patch.

-RockCrusha

I'll have that patch ready for you soon... I almost have it working, one message has a problem with the length because of something I changed... but it shouldn't be tough to track it down.

sweet man thanks!

that's awesome : )

-RockCrusha

Oddly I'm causing a problem way downstream of the version exchange with my code. Well, not WAY downstream, but not quite where I'd have expected a problem. I'm sure it is a simple fix, I'll try and get to it tonight and I'll post a link to my patch when I'm done.