VPN question (ssh)

Fraser Campbell fraser-Txk5XLRqZ6CsTnJN9+BGXg at public.gmane.org
Mon Dec 22 03:05:31 UTC 2003


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





More information about the Legacy mailing list