search

CESNET / netopeer2

NETCONF toolset
BSD 3-Clause "New" or "Revised" License
301 stars 189 forks source link

Missing key algorithms by configuration Multiple public keys. #1654

Open fei15115 opened 4 days ago

fei15115 commented 4 days ago

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>

image

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>

image

Could you please help me check if this is a bug?

michalvasko commented 4 days ago

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.

fei15115 commented 4 days ago

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>
michalvasko commented 3 days ago

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.

fei15115 commented 3 days ago

Netopeer2 V2.1.62 libnetconf V2.1.34 I don't think that is pretty old version?

michalvasko commented 2 days ago

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.