Re: An additional-auth mechanism for SSH to protect against scanning/probing attacks

Mouse <[email protected]> writes:

>>And definitely not in the optional subsequent lines of data which causes
>>some implementations to choke when they see them.
>
>That sounds to me like a reason to use them, not a reason to avoid them.  I
>thought the point of this was to break attacks from disapproved clients.  If
>you use something that breaks disapproved clients before they even _look_ at
>the challenge, isn't that even better?

Hmm, good point there (oh, and they precede the SSH ID, they don't follow it
as I originally said).  Something tells me this just shouldn't be the way to
do it, but is it a good point :-).

Actually I've just checked the RFC since I wasn't sure the client could send
additional lines and while it doesn't say it can't, it also doesn't say it
can, only the server is mentioned:

   The server MAY send other lines of data before sending the version
   string.

Also the text has been there unchanged since 1997 and talks about it being
there to support TCP wrappers which sorta screams "historial baggage", so
probably best not to do it this way, although now I'm tempted to see what
happens if I respond to connect attempts on port 22 with:

220 $servername ESMTP Chuckmail bent over and ready
+OK POP3 server ready <abcd@$servername>
OK IMAP/POP3 ready $servername
220 FTP Server $servername ready
SSH-2.0-$server-$version

Anyone ever tried this?

Peter.