CESNET
Missing key algorithms by configuration Multiple public keys.
As shown in the figure, I have configured multiple encryption methods in netconf. However, when I verify it, I find that only two of them are supported.
<netconf-server xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-server">
<listen>
<endpoint>
<name>default-ssh</name>
<ssh>
<tcp-server-parameters>
<local-address>0.0.0.0</local-address>
<keepalives>
<idle-time>1</idle-time>
<max-probes>10</max-probes>
<probe-interval>5</probe-interval>
</keepalives>
</tcp-server-parameters>
<ssh-server-parameters>
<server-identity>
<host-key>
<name>default-key</name>
<public-key>
<keystore-reference>genkey</keystore-reference>
</public-key>
</host-key>
<host-key>
<name>secp384-key</name>
<public-key>
<keystore-reference>secp384</keystore-reference>
</public-key>
</host-key>
<host-key>
<name>secp256-key</name>
<public-key>
<keystore-reference>secp256</keystore-reference>
</public-key>
</host-key>
<host-key>
<name>secp521-key</name>
<public-key>
<keystore-reference>secp521</keystore-reference>
</public-key>
</host-key>
<!-- <host-key>
<name>x25519-key</name>
<public-key>
<keystore-reference>x25519</keystore-reference>
</public-key>
</host-key> -->
</server-identity>
<client-authentication>
<supported-authentication-methods>
<publickey/>
<passsword/>
<other>interactive</other>
</supported-authentication-methods>
<users/>
</client-authentication>
</ssh-server-parameters>
</ssh>
</endpoint>
<endpoint>
<name>default-ssh2</name>
<ssh>
<tcp-server-parameters>
<local-address>::</local-address>
<keepalives>
<idle-time>1</idle-time>
<max-probes>10</max-probes>
<probe-interval>5</probe-interval>
</keepalives>
</tcp-server-parameters>
<ssh-server-parameters>
<server-identity>
<host-key>
<name>default-key</name>
<public-key>
<keystore-reference>genkey</keystore-reference>
</public-key>
</host-key>
<host-key>
<name>secp384-key</name>
<public-key>
<keystore-reference>secp384</keystore-reference>
</public-key>
</host-key>
<host-key>
<name>secp256-key</name>
<public-key>
<keystore-reference>secp256</keystore-reference>
</public-key>
</host-key>
<host-key>
<name>secp521-key</name>
<public-key>
<keystore-reference>secp521</keystore-reference>
</public-key>
</host-key>
<!-- <host-key>
<name>x25519-key</name>
<public-key>
<keystore-reference>x25519</keystore-reference>
</public-key>
</host-key> -->
</server-identity>
<client-authentication>
<supported-authentication-methods>
<publickey/>
<passsword/>
</supported-authentication-methods>
</client-authentication>
</ssh-server-parameters>
</ssh>
</endpoint>
</listen>
</netconf-server>
There is another problem. When I try to add the public key and private key of X25519, the server will report an error. Is it a problem with the format I added?
<asymmetric-key>
<name>x25519</name>
<algorithm>x25519</algorithm>
<public-key>MCowBQYDK2VuAyEAv3emx3R4Bp/Ob8E2YIFs6lGye2KzejbXu/HMlqT19Qs=</public-key>
<private-key>MC4CAQAwBQYDK2VuBCIEIJgE+P5q9sAhyd7AbUlhOB8m2NM9kw9PTkwrg1aZPiRC</private-key>
</asymmetric-key>
Could you please help me check if this is a bug?
Could you please include your ietf-keystore content (without the private keys, if you are have deployed them, hope not) for me to see the actual keys that are referenced? Also, you seem to be using old revisions of the YANG modules (old libnetconf2 version) because I cannot find these nodes. But I guess the algorithm leaf was an identityref, whose values need their module prefix in case the identities are from a foreign module. Look into the RFC for specific examples of how to include them in an XML.
Sure. Currently, the public and private keys have not been deployed yet. I can send it to you for a look.
<asymmetric-key>
<name>secp384</name>
<algorithm>secp384r1</algorithm>
<public-key>MHYwEAYHKoZIzj0CAQYFK4EEACIDYgAE+H0OgQVKQ/stq0qUem7m6Enb2BEWZ8XJiXLUk7rmQuVAAAOX4+g46jpBV0hCtgtj4HXUJmQnTx/GKC35rfj4Ol2FKaZnkyY8mwK9UVeV6ZJQYK19McHhFcXja/bIgUrD</public-key>
<private-key>MIGkAgEBBDAHBUQ1Tz+OuAMAGpaGsm7hYRyz26zgB2dkrmeeAr93RKLXJxsArkciNYKOVB74Nt+gBwYFK4EEACKhZANiAAR1ZQGs0zdFVNlCfEXdeiHDTphlOn2B/R3nbX+M0X/LYGi4E8zSGZcjgYmPivrZkv1wz958NTP9pUecJFxGE3xdLr6Ho0MjE7Gt4pmV6LvK7lYY/1CDMZV+xtzBwwhqjiE=</private-key>
</asymmetric-key>
<asymmetric-key>
<name>secp256</name>
<algorithm>secp256r1</algorithm>
<public-key>MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEUNnV0WexOQfkg45Cnn/PNhNqI2DGGjEtBUmc+lUd1rbMc3VLn/wPvsCvabrOXQ4daFFL+gep/AhHZHvF1Mi3kw==</public-key>
<private-key>MHcCAQEEIANphBqVgGmqoNHZq7Rmpqa1ddAPNVCJmBgfK6mr7tkeoAoGCCqGSM49AwEHoUQDQgAEUNnV0WexOQfkg45Cnn/PNhNqI2DGGjEtBUmc+lUd1rbMc3VLn/wPvsCvabrOXQ4daFFL+gep/AhHZHvF1Mi3kw==</private-key>
</asymmetric-key>
<asymmetric-key>
<name>secp521</name>
<algorithm>secp521r1</algorithm>
<public-key>MIGbMBAGByqGSM49AgEGBSuBBAAjA4GGAAQA0jmyxfD+YMC+Tazec4oIfUjI/nci4Xwqa5SboqRJPwGfzMZviqFRGMhu+UrcqONuXSc0wXOYPW5NQpNfKH5t6OQBA64ehR6M56PIhiSrOQ5xZ3PE8ktmZlMu+XYGQe3U2zFXSXLv2ZGn1GgDtJMouH2TMQV9TM63tLPQOtzrJN3iFVQ=</public-key>
<private-key>MIHcAgEBBEIAdPQe0C6H895JvKL1Z1DET9sKlgiYptE0pJ5y57kYWqMhZ+qsHpKA0I7MP/5I8t9WF1JTsMH5AgBSJSBgex6lIKSgBwYFK4EEACOhgYkDgYYABADSObLF8P5gwL5NrN5zigh9SMj+dyLhfCprlJuipEk/AZ/Mxm+KoVEYyG75Styo425dJzTBc5g9bk1Ck18ofm3o5AEDrh6FHozno8iGJKs5DnFnc8TyS2ZmUy75dgZB7dTbMVdJcu/ZkafUaAO0kyi4fZMxBX1Mzre0s9A63Osk3eIVVA==</private-key>
</asymmetric-key>
<asymmetric-key>
<name>x25519</name>
<algorithm>x25519</algorithm>
<public-key>MCowBQYDK2VuAyEAv3emx3R4Bp/Ob8E2YIFs6lGye2KzejbXu/HMlqT19Qs=</public-key>
<private-key>MC4CAQAwBQYDK2VuBCIEIJgE+P5q9sAhyd7AbUlhOB8m2NM9kw9PTkwrg1aZPiRC</private-key>
</asymmetric-key>
So what libnetconf2/netopeer2 version are you using? It really seems like an old one so I may not be able to provide any support.
Netopeer2 V2.1.62 libnetconf V2.1.34 I don't think that is pretty old version?
It it now more than a year old, in our development schedule that is quite a lot, the used YANG modules were updated and the whole configuration works differently. So I cannot provide proper support and I do not understand why x25519 would be considered an invalid value, seems correct based on the used YANG modules. Also, in that version I do not think all these algorithms were actually supported so that may be the reason why they are not actually used by libssh. My suggestion is to update all the projects (libyang, sysrepo, libnetconf, netopeer2) to their latest release and try to configure it again.