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?

schroeder
  • 123,438
  • 55
  • 284
  • 319
user238349
  • 1
  • There are a bunch: https://security.stackexchange.com/questions/126779/verifying-ssh-fingerprint-of-a-public-server and https://security.stackexchange.com/questions/174476/what-can-cause-a-changed-ssh-fingerprint and these: https://security.stackexchange.com/questions/172242/what-does-ssh-fingerprint-help-to-prevent – schroeder Jul 14 '20 at 10:30
  • In short: the implication being that you need something to compare to – schroeder Jul 14 '20 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 Jul 14 '20 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 Jul 14 '20 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 Jul 14 '20 at 10:50
  • @mti2935 Thank you. Again, I know why this is done in principle. What I wanted to know and what I asked repeatedly and can't seem to get a simple answer for, is whether the authentication method (password vs. PK) makes any difference. I'll just go forward assuming it does not. – user238349 Jul 14 '20 at 11:02
  • If you use password authentication with the attacker's server, that's a problem. If you authenticate with the attacker's server using your password, then he now has your password, and he can now go ahead and authenticate with the real server using your password. It's like a phishing attack on the web, using a fake web site. On the other hand, if you used PK authentication with the attacker's server, the attacker doesn't have anything useful - he only has your public key, which after all, is ... public. – mti2935 Jul 14 '20 at 11:18

1 Answers1

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)

Manfred Kaiser
  • 1,236
  • 2
  • 4
  • 19