0

Assume I passed on my public key to a service provider for them to set up a "new" server and configure it for private key authentication (instead of root password).

Is the server fingerprint verification during my initial connection to the server still necessary and/or helpful against MITM or any other attack?

I realize that verifying the server's fingerprint initially when using password authentication is absolutely sensible. But I don't understand the SSH protocols well enough to see, if this still makes sense if I never use a password at all.

Wouldn't a successful first-time authentication with my key imply that the server has my public key and is, therefore, the right one? Or is there still a way to perform a MITM attack in such a scenario? Is there any qualitative difference between this scenario and a first-time authentication with a password?

Improve this question
7
  • There are a bunch: security.stackexchange.com/questions/126779/… and security.stackexchange.com/questions/174476/… and these: security.stackexchange.com/questions/172242/…
    – schroeder ♦
    Commented Jul 14, 2020 at 10:30
  • In short: the implication being that you need something to compare to
    – schroeder ♦
    Commented Jul 14, 2020 at 10:31
  • 1
    'Assume I passed on my public key to a service provider for them to set up a new server and configure it for private key authentication' - this enables the server to authenticate you. But, this does not help you authenticate the server. The first time you connect to the server, how do you know that you are connecting to the right server?
    – mti2935
    Commented Jul 14, 2020 at 10:32
  • @schroeder I have actually seen all of those. None of them answered my question. Maybe it is a stupid question. It boils down to: Is it different, if I use PK instead of a password? You are saying, no, there is no difference? And yes, I know this is for authenticating me, but it is conceivable that this has implications for the protocol. I just wanted to make sure, I understand it.
    – user238349
    Commented Jul 14, 2020 at 10:40
  • 1
    Yes, the fact that you have no way to authenticate the server on your first connection to the server has implications on the protocol. An attacker on the network can simply route your connection to his server instead of the real server. You'll have no way of knowing that it's not the real server, so you'll happily connect. It's like connecting to a web site without a valid SSL certificate.
    – mti2935
    Commented Jul 14, 2020 at 10:50

1 Answer 1

Reset to default
2

To transfer your public key to the server with "ssh-copy-id" you have to connect to the remote ssh server. If you establish the connection for the first time, the fingerprint must be verified.

This is the point, where you are most vulnerable, because the fingerprint is not known.

To mitigate this problem, the server admin should publish the fingerprint on a trusted source. This could be a website with https or as "sshfp-record" dns with dnssec.

If you can upload your public key through a web interface, your public key is already known, but you have the problem, that the server is not known to you.

A full mitm attack is not possible, but an attacker can intercept your connection and trick you in a fake shell. When you are entering passwords, the attacker can log them in plaintext and reuse them for authentication, if your server allows password authentication.

So, public key authentication does not protect you against ssh mitm attacks, if you don't check the fingerprint.

If you are interested in ssh mitm attacks and want to learn more about them, there are some tools available. https://github.com/ssh-mitm/ssh-mitm is able to intercept public key authentication. (I'm the author of this tool)

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .