How to validate host keys (i.e. how to access information about NIOSSHPublicKey)?

[TimNN]

SwiftNIO SSH commit hash: 5d95eba

Context:
I'm trying to implement a NIOSSHClientServerAuthenticationDelegate that actually verifies the host key.

The problem:
Except for debug printing, I have not found any way to access any information about the supplied NIOSSHPublicKey.

Is there currently a way to access information about a NIOSSHPublicKey? (Apologies if I missed something obvious, I'm fairly new to swift).

System Information

$ swift --version
Apple Swift version 5.3.2 (swiftlang-1200.0.45 clang-1200.0.32.28)
Target: x86_64-apple-darwin19.6.0

$ uname -a
Darwin tim-mac.local 19.6.0 Darwin Kernel Version 19.6.0: Mon Aug 31 22:12:52 PDT 2020; root:xnu-6153.141.2~1/RELEASE_X86_64 x86_64 i386 MacBookPro12,1 Darwin

[Lukasa]

What question about the key are you specifically trying to answer?

[Lukasa]

I ask because we're being very tentative with exposing up API on these types. We can definitely add more, but the first question is whether what we have will work. One thing you can do, for example, is load the key you expect to see into a NIOSSHPublicKey and then use the Equatable conformance to check if they're equal.

[TimNN]

What question about the key are you specifically trying to answer?

Whether it is a known / expected key.

One thing you can do, for example, is load the key you expect to see into a NIOSSHPublicKey and then use the Equatable conformance to check if they're equal.

I didn't think of that solution, but it would solve part of my problem, thanks!

Though I don't think this would allow me to implement a behavior similar to e.g. OpenSSH, where a public (host) key is accepted (and stored) when it is first encountered (because, as far I could tell, there is not API to serialize an NIOSSHPublicKey).

Or would it be recommended to use the Hashable conformance (with an appropriate Hasher) for this feature? Is the Hashable implementation guaranteed to be stable across versions / platforms?

because we're being very tentative with exposing up API on these types

That sounds like a very sensible approach :). What about exposing the opposite of init(openSSHPublicKey: String), i.e. a method to serialize the key back to an OpenSSH public key? That might be desirable in any case for interoperability.

[Lukasa]

Or would it be recommended to use the Hashable conformance (with an appropriate Hasher) for this feature? Is the Hashable implementation guaranteed to be stable across versions / platforms?

Nope, Hashable is not even stable across invocations from the same process.

For your specific solution, yes, we could add OpenSSH public key serialisation. That's likely to be the best solution, not least because the OpenSSH public key serialisation format is basically the same as the wire format.

[Lukasa]

Out of curiosity, is that a patch you'd be interested in adding?

[TimNN]

Out of curiosity, is that a patch you'd be interested in adding?

Yes, assuming that there's agreement that this is the way to go (i.e. the patch is likely to be accepted if it is of sufficient quality).

(Though I'll have to jump through some hoops to get the contribution approved - I'll see how that goes and will update this issue in a week at the latest).

[Lukasa]

Yes, I believe this is a reasonable API, and a sufficiently high quality patch would be merged. In general I'm in favour of patches that add minimal API surface, and so a simple inverse function would be fantastic. I suspect we want to handle this as an extension on String.

Let me know if the contribution boundaries get too high, I may be able to put you in touch with some Googlers who might be able to help.

[TimNN]

I may be able to put you in touch with some Googlers who might be able to help.

Thank you for the offer. Since there's been little progress on getting the contributions approved, I would like to take you up on it. You can find my personal email on my profile. My work email is <my GitHub username>@google.com.

[Lukasa]

I've reached out to some folks, they should be in touch.

[Junyi-99]

What about exposing the opposite of init(openSSHPublicKey: String), i.e. a method to serialize the key back to an OpenSSH public key? That might be desirable in any case for interoperability.

I'm currently working on developing a SSH tools for iOS, and I don't know how to get the exact information of the public key. But I think it is a good idea to serialize the bey back to a public key.

[Joannis]

@Military-Doctor the OpenSSH format for public & private keys is agnostic to the type of public key. So while the format could by representing a type known to CryptoKit & NIOSSH, this is not necessarily the case. A good example is RSA based keys, which NIOSSH does not (intend to) support.