(I'll forward your message to a couple of lists where it might be of interest; the original message is at end.) I think you are right in your analysis. There is indeed a problem with RSA authentication. Basically what this means is that if you log into a corrupt host, that host can at the same time log into another host with your account (by fooling you to answer to the request) provided that you use the same RSA identity for both hosts. A workaround is to use a different identity for each host you use. The default identity can be specified on a per-host basis in the configuration file, or by -i options. And, yes, I think the same problem might occur with client host authentication. Though, there you would still have to do IP-spoofing, DNS spoofing or similar to get through (breaking RSA based host client effectively reduces RhostsRSAAuthentication to conventional .rhosts authentication). The protocol will need to be changed somewhat because of this. I'll think about it tomorrow and let you say you opinion about it. Thanks! Tatu Ylonen <ylo@cs.hut.fi> Date: Thu, 13 Jul 1995 13:08:15 -0700 From: David Mazieres <mazieres@pa.dec.com> To: ssh-bugs@cs.hut.fi Cc: rtm@eecs.harvard.edu, dm@eecs.harvard.edu, tbl@eecs.harvard.edu Subject: Ssh security hole? I believe there is a serious problem with the RSA authentication scheeme used in ssh, but then again I could be misreading the proposed RFC. Is the following really the case? As I understand the protocol, here is what happens during SSH_AUTH_RSA authentication. Suppose the holder of SKu, is allowed access to account U on machine B (which holds SKb). Both PKu and PKb are widely known. In addition, machine B has a session key, PKs, which changes every hour. When U on machine A wants to log into machine B, here's what I think happens based on my reading of the RFC: A -> B: A B -> A: (PKb, PKs, COOKIE) [A flags an error if PKb is not the stored value.] A -> B: (COOKIE, {{Kab}_PKs}_PKb) A -> B: {U}_Kab A -> B: {PKu}_Kab [B aborts if SKu is not allowed access to account U.] B -> A: {{N}_PKu}_Kab A -> B: {{N}_MD5}_Kab (*) [B aborts if the MD5 hash is invalid.] B -> A: access to acount U with all data encrypted by Kab. The problem is, suppose U actually wanted to log into machine C, which was maintained by an untrusted person. The person maintaining C could initiate a connection to B the minute U tried to log into C. When given a challenge {{N}_PKu}_Kbc, C could simply give this to A as the challenge to respond to, and then forward the response to B. To fix the problem, A must at the very least include B in the response line marked (*). I have reason to believe (after having just seen a lecture on authentication), that you might even need to include more. A safe bet might be (but then again I am no expert): A -> B: {(N, A, B, Kab)}_MD5 I think similar problems arise for the other authentication methods. Other than that, though, I am really impressed by by ssh. It's easy to install and easy to use. In fact, it is even more convenient to use than standard rsh, because the X forwarding happens automatically. Thanks for such a great package! David