On December 21, 2003 06:28 pm, Justin Zygmont wrote:

it had a lot to do with the original type of question. I was trying dsniff lately, which is probably my favourite packet sniffer, and I see that it uses a man in the middle technique and does infact support ssh version 1. I'm suprised no one has tried to add more code of their own to compromize ssh 3.x. I don't see how that can be stopped unless they use kerberos maybe, I always thought man in the middle was probably the best interception technique.

AFAIK, man in the middle attacks against ssh work only if the end-user is behaving badly. Part of the ssh protocol (1 or 2) involves authenticating the server. The server has a private key readable only by root, it has a public key that a user caches in ~/.ssh/known_hosts (or for all users in /etc/ssh/known_hosts). I'm no expert on public-key crtypography but I believe (roughly speaking) it works like this: - client and server agree on a string to encrypt - server encrypts string using private key and sends result to client - client checks encrypted string against the public key in it's cache ... despite not knowing the server's private key, the client can definitively know whether the string was encrypted using the correct private key That is a very rough description and I'd like to be corrected if wrong. Regardless of my description, client has ability to know definitively that it's talking to a server that has the private key that is expected. So there are a few ways that security can be compromised: - server gets broken into and someone steals private key to use in man-in-the-middle attack (they need root access to steal your key so you have big problems here quite apart from ssh) - the end user doesn't verify the key properly - the end user ignores warnings of changed keys Second point is that if you want to ensure security then you must securely populate your known hosts file. ssh'ing to a server and having the client add the public key to your known_hosts is not secure ... you can't be sure that there isn't a "man in the middle". Third point is regarding users that ignore messages like ... @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ If the machine hasn't been reinstalled then you really need to question why it's key has changed and not trust the server until you find out why and verify the new key. -- Fraser Campbell <fraser-Txk5XLRqZ6CsTnJN9+BGXg at public.gmane.org> http://www.wehave.net/ Georgetown, Ontario, Canada Debian GNU/Linux -- The Toronto Linux Users Group. Meetings: http://tlug.ss.org TLUG requests: Linux topics, No HTML, wrap text below 80 columns How to UNSUBSCRIBE: http://tlug.ss.org/subscribe.shtml