Carefully consider the role of the "host key fingerprint." It is a random nonce that is generated by one host and securely sent to another so that the other side may recognize it ... or not. It is therefore intended to be both recognizable and recognized: connecting clients remember the fingerprints they've encountered (which you told them that "you recognize"), and warn you when they encounter for the first time any fingerprint that you do not.

I see no good reason why "the fingerprint (of the remote) should change with each reboot," because this simply defeats the purpose of the signature: if you can't anticipate what the next value of the signature will be, you can never use it for its intended purpose. (And, you're just filling-up your authorized_keys file, uselessly.)

Frankly, I'm not entirely sure that you read the cited article all the way to its conclusion, or that you fully understood it, if you did.

I sincerely and respectfully believe that your scheme is both mis-guided and unnecessary. Let me now explain why a single public key provides security (provided that you do not allow sshd to "fall back" to less-secure alternatives such as passwords).

Every public key that you generate, public though it may be, corresponds to something that only you possess: your private key. You can distribute your public key far and wide because it is only able to decrypt something that was encrypted using your (unknown to them) private key. Likewise, that public key can be used to encrypt messages that only you can decrypt.

So, our MITM, in possession of your public key, successfully decrypts his intercept and changes it. Now, he has a problem: he cannot re-encrypt the modified intercept in a way that the final party will be able to decrypt it. (Because he has not stolen your private key. Therefore, only you can do this.)

Public/Private keys are used as an un-forgeable form of identification that is employed during the per-conversation negotiation of an initial "session key" (through the Diffie-Hellman process referred to by the referenced web site). The public key is acceptable proof that any message which it is capable of decrypting must have come from you: that the other-side, no matter which one of "your" public keys he is using, must be negotiating a session-key with you.

Hi,

Let's put the blame on me, saying that I'm not explicit enough ;-)

The system I need to connect to is an rescue Linux, managed by the server provider.
Whenever the rescue system is rebooted, the host key fingerprint changes. This is the way they designed it. I have no control over that.
Once I do my business within the rescue system, I will boot my system. This system will not change the host key fingerprint with reboots.
But first, I really need to use the rescue system.

I have the possibility of securely uploading my public key, that then is available to the rescue OS.
I plan to upload two public keys:
- one that I will use to login myself,
- one that I will use to authenticate the host.

This second public key could be whatever file containing enough random data, but it so happens that I am only able to upload file in the form of SSH public key.

EDIT:
I want to use separate, fresh, unknown second public key just a safer approach. It'll be removed as soon as I get the job done, i.e. authenticate the host.
Probably the main (first) public key would be enough, but I'm lost, and can't recall if it's transmitted during the negotiation or not (the answer is probably somewhere over here ;-)), so I'm not sure if it's completely secret. And somebody might actually have my main public key.

Does it basically mean he is not able to send a message to the server, that the server would understand and interpret?
So it would mean he wasn't able to execute anything on the server?
Then that would be the answer I expect :-)

--
Best regards,
Andrzej Telszewski

I took another look, and I believe it's correct. However, there is a caveat that could be problematic for your use case, see below.

I would just like to put in a minor nitpick here, you don't decrypt anything with a public key. Public keys are for encrypting, or (in this case) verifying signatures. Private keys are for decrypting, or (in this case) generating signatures.

I admire your patience

Does this rescue system also allow password authentication? If it does, and the attacker can obtain the password (e.g., by brute force guessing) they would be able to setup a MITM situation with you connected to them by pubkey auth, and they connect to the server by password auth.

Did they really "design" it this way, because that would be very non-standard, or did they just screw up and unknowingly and accidentally have the server regenerate keys on reboot? Can you contact them and ask? You never know, they might say, "Hey, thanks for pointing out our screw-up, we'll fix it right away!" Problem solved.

Hi,

Yes, it allows password auth.
But I'm going to be there only for a few hours, so that should not be a problem.
Actually, I can change the password after login, for something stupid strong.
And no, I will not connect with password, I will connect using pubkey.

It's an Online.net's Dedibox server.
And yes, they designed it like that. I don't know what were their motives.
I contacted the technical assistance long time ago, suggested that they should at least make the host key fingerprint available on Web interface.
Unfortunately, nothing changed.
I was once confirming the fingerprint by asking the technical assistance, but it is lengthy and troublesome process.
And I don't know how were they obtaining the fingerprint themselves;-)

BTW, when the rescue OS boots, it downloads the public keys for root account from here.
This way the staff can access my server for assistance, when in rescue mode.


I hope you finally have the complete picture.
This whole mess is going to be temporary.
It will actually last long enough to login and cat authorized_keys.
So, do you think I can do it this way?

I know @haertig gave sensible reason against in Discovering remote SSH public keys: possible? thread, but:

• I need to trust sshd. If you can confirm me that sshd does not leak user's public keys by design, then I'm going to stick with this,
• it seems you have already confirmed MITM is not possible, but hell, ok, you have confirmed.

Can I connect now, please? :-)

--
Best regards,
Andrzej Telszewski

I think you're fine, assuming you find the risk of an attacker breaking the default password acceptable.

Hi,

The password is different every reboot and it's already quite complex.
I can make it even more complex just after login.
I don't think anyone will have the chance to break it.

--
Best regards,
Andrzej Telszewski

Ah, that sounds pretty safe then.

Well, that's actually backwards. The private key encrypts to produce a signature, and the public key decrypts it (and finds that it is able to do so). The important point is that it is able to do so: therefore, this (known) public key has to be derived from the (unknown) private key that must be in the possession of the corresponding party.

In everything SSH, you must make sure that it does not ... as it will do by default ... "ratchet down to the least-secure available authentication method: passwords."

If you can be assured of the physical integrity of the rescue machine ... if you can be confident that no one can log on to it directly and tamper with SSH keys ... then I believe that you can simply install one of your public keys onto it and thereby achieve the authentication requirements of your situation. If you know which key your ssh-agent negotiates, and if you know that this key exists only there, then you can be assured of the identity of the machine by virtue of the fact that you are able to log in to it using this key.

Only someone in possession of the corresponding private key can do such a thing. That means, "you." (And you must take steps to ensure that it does mean "you.")

An intruder who wanted to launch an MITM attack would have to steal your private key, since only this key can authenticate against that public key. If he is not in possession of your private key, he cannot generate traffic to "replay" to the real system. Alternatively, he would have to install a second key of his own.

For further proof, consider encrypting a copy of the ~/.ssh/authorized_keys file using GPG and a passphrase (or, much(!) better yet, a certificate) known/possessed only by you. Place this file on the rescue system. Upon connecting, compare the decrypted content to the existing file. You should be able to decrypt the file and its contents should exactly match. Now you know that you must be talking to the right system, and that no SSH keys have been substituted.

A known SHA1 signature of the encrypted file, combined with the fact that it is there, can be used as a "quick check."

- - -
Other strategies can be considered, if you know of a third-party secure machine that is known to be available to both your machine and the rescue. The rescue machine could be set up to establish a VPN tunnel (with client-to-client), using certificates, with a third-party server machine to which you also can connect. The rescue machine will accept incoming connections from no other network source. Now, you can connect to the same trusted third-party server and securely reach the rescue machine. This necessarily depends upon the rescue's ability to negotiate and automatically establish that connection, and upon the actual integrity of the third-party machine.

Please don't confuse signing with encryption (or verification with decryption).

https://en.wikibooks.org/wiki/Crypto...tal_signatures

Wow ... that's a seriously messed-up(!) WikiPedia page, and I hope that someday someone takes a closer look at it.

When we talk about SSH in this context, we're actually not talking about "message signing" at all, and I now realize that I erred by using this terminology. I actually used the wrong term.

What I meant to say has nothing whatsoever to do with "host signatures" and so on. Rather, it has to do (only) with "the connection, itself," and with the significance of your ability to successfully make that connection (at all) using a certificate.

Even though you can generate public keys and install them on whatever target-system you wish to be able to connect to "password free," only you will be able to use those keys to do so, because only you possess(!) the corresponding, secret(!), private key.

"And that" ... (ahem, koff koff) ... "is the key."

If you are able to place a public key onto the rescue system, then you, and you alone, will be able to connect to it using that key.

If you need to be paranoid, then the suggestion of separately encrypting the authorized-keys file (and maybe by noting and settling-for a sha1sum of that file or of the GPG-file or both) provides a further means of verification that the SSH connection that you have now established must be the one that you intended – because it could not be any other.

----
FYI:™ "Message signing" is an unrelated concept that consists of making a secure hash (SHA1) of the content of some message, then encrypting the hash-value with the sender's private key. The recipient decrypts the signature (finding, first of all, that he is able to do so at all ... thus confirming the sender's identity), then verifies the hash to confirm that the message has not been altered.

Mixing up message signing with "private key encryption" like this only kind of works for RSA because in toy implementations all of signature, verification, encryption, and decryption operations are just modular exponentiation. But with Elliptic Curve keys, for example, message signing does not use encryption.

I hereby graciously concede the point. Thank you for the clarification.

Hi,

Although the original question hasn't been answered, I received satisfactory answers.
Marking this one as solved.

Thanks!

--
Best regards,
Andrzej Telszewski

I thought you answered your original question in post#14.