Closed apetresc closed 5 years ago
SSH is not resilient to MITM attacks. mitmproxy is an example of a tool that claims to be able to intercept such a connection. Of course, if you don't trust the server you're copying your key to, you shouldn't do it in the first place. SSH should also warn you about potential MITM attacks if the fingerprint changes from when you first connected to the server.
Regarding the rest of your question, you may find Is there any risk from attempting ssh authentication to a rogue server? interesting. Depending on your threat model, simply authenticating with a rogue server shouldn't pose any risk. You should probably open a PR to clarify the language.
I've read many debates on the public key. Yes, it is public, but that doesn't mean you want anyone to have it. Public or not, everything should be need-to-know, right?
I have gotten other comments on that line though. Maybe I should remove it?
I got other feedback on that one line. I changed it. Hopefully its more clear now.
In the section on adding your public key to the server's
~/.ssh/authorized_keys
file, you write:I find this a very confusing warning to give. The entire purpose of SSH (which is presumably the protocol
ssh-copy-id
uses) is to be resilient to MITM attacks; if for some reason you don't trust the network and/or client enough to be able to transfer something overscp
, why would it make any difference whether you were authenticating via password or private key in the first place?And secondly, even if you were being sniffed, the only thing you're uploading is a public key. That shouldn't be considered private in the first place.
Basically, that clause seems to just confuse the issue of how SSH works and what
authorized_keys
does. Am I missing something?