Post-quantum safe kex algorythm?

[EugenMayer]

Using ssh2 via Azure pipelines and failing to connect to an ssh server that only has

KexAlgorithms sntrup761x25519-sha512@openssh.com

The version used is https://github.com/microsoft/azure-pipelines-tasks/blob/master/Tasks/CopyFilesOverSSHV0/package.json#L26

    "ssh2": "^1.15.0",
    "ssh2-sftp-client": "^12.0.1"

Is this expected, or does Microsoft need to update ssh2? I was not able to find any hints.

[mscdex]

OpenSSL doesn't support sntrup761, so it would need to be added to the bundled optional addon.

[EugenMayer]

Thank you for elaborating, so in short:

• there is currently no updated version of ssh2 that would support that and thus there is no way to create a PR to fix the azure pipeline
• libressl does support sntrup761 (cannot find any reference to that), but openssl does not? Assuming https://opensslntru.cr.yp.to/ would be a replacement for that?

Thank you for sharing some light into that area

[mscdex]

• there is currently no updated version of ssh2 that would support that

Correct.

• thus there is no way to create a PR to fix the azure pipeline

Not true. The more sane (and compatible) solution IMO is to allow at least one (strong) non-Post-quantum algorithm for key exchange on their servers. This is the first time I've ever seen someone only allow a post-quantum key exchange.

• libressl does support sntrup761 (cannot find any reference to that), but openssl does not?

AFAICT OpenSSL does not. Node.js uses OpenSSL, so that is our preferred option whether using the built-in crypto module or using node's re-exported OpenSSL symbols in ssh2's bundled optional addon. Other times we just have to supply our own implementation when neither of those will work. IIRC this latter option is how OpenSSH handles such things.

• Assuming https://opensslntru.cr.yp.to/ would be a replacement for that?

That kind of change would need to be proposed in the node.js repo for inclusion, since ssh2 just uses what node.js provides (either via JS or C++).