libnetconf UPDATE YANG data configuration

Configuration based on YANG data. Open 2 ssh channels on one
session. Pubkey,interactive,pw,none SSH authentication working. SSH
message callback not a callback anymore, handle SSH messages manually.
ietf-netconf-server and all models it imports added and a libnetconf2 own model
with augments. And finally only local-definition of keys supported. 2 tests.
NBC API changes.
diff --git a/modules/ietf-ssh-common@2022-07-18.yang b/modules/ietf-ssh-common@2022-07-18.yang
new file mode 100644
index 0000000..00f32f4
--- /dev/null
+++ b/modules/ietf-ssh-common@2022-07-18.yang
@@ -0,0 +1,257 @@
+module ietf-ssh-common {
+  yang-version 1.1;
+  namespace "urn:ietf:params:xml:ns:yang:ietf-ssh-common";
+  prefix sshcmn;
+
+  import iana-ssh-encryption-algs {
+    prefix sshea;
+    reference
+      "RFC EEEE: YANG Groupings for SSH Clients and SSH Servers";
+  }
+
+  import iana-ssh-key-exchange-algs {
+    prefix sshkea;
+    reference
+      "RFC EEEE: YANG Groupings for SSH Clients and SSH Servers";
+  }
+
+  import iana-ssh-mac-algs {
+    prefix sshma;
+    reference
+      "RFC EEEE: YANG Groupings for SSH Clients and SSH Servers";
+  }
+
+  import iana-ssh-public-key-algs {
+    prefix sshpka;
+    reference
+      "RFC EEEE: YANG Groupings for SSH Clients and SSH Servers";
+  }
+
+  import ietf-crypto-types {
+    prefix ct;
+    reference
+      "RFC AAAA: YANG Data Types and Groupings for Cryptography";
+  }
+
+  import ietf-keystore {
+    prefix ks;
+    reference
+      "RFC CCCC: A YANG Data Model for a Keystore";
+  }
+
+  organization
+    "IETF NETCONF (Network Configuration) Working Group";
+
+  contact
+    "WG Web:   https://datatracker.ietf.org/wg/netconf
+     WG List:  NETCONF WG list <mailto:netconf@ietf.org>
+     Author:   Kent Watsen <mailto:kent+ietf@watsen.net>
+     Author:   Gary Wu <mailto:garywu@cisco.com>";
+
+  description
+    "This module defines a common features and groupings for
+     Secure Shell (SSH).
+
+     Copyright (c) 2022 IETF Trust and the persons identified
+     as authors of the code. All rights reserved.
+
+     Redistribution and use in source and binary forms, with
+     or without modification, is permitted pursuant to, and
+     subject to the license terms contained in, the Revised
+     BSD License set forth in Section 4.c of the IETF Trust's
+     Legal Provisions Relating to IETF Documents
+     (https://trustee.ietf.org/license-info).
+
+     This version of this YANG module is part of RFC EEEE
+     (https://www.rfc-editor.org/info/rfcEEEE); see the RFC
+     itself for full legal notices.
+
+     The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL',
+     'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED',
+     'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document
+     are to be interpreted as described in BCP 14 (RFC 2119)
+     (RFC 8174) when, and only when, they appear in all
+     capitals, as shown here.";
+
+  revision 2022-07-18 {
+    description
+      "Initial version";
+    reference
+      "RFC EEEE: YANG Groupings for SSH Clients and SSH Servers";
+  }
+
+  // Features
+
+  feature ssh-x509-certs {
+    description
+      "X.509v3 certificates are supported for SSH.";
+    reference
+      "RFC 6187: X.509v3 Certificates for Secure Shell
+                 Authentication";
+  }
+
+  feature transport-params {
+    description
+      "SSH transport layer parameters are configurable.";
+  }
+
+  feature public-key-generation {
+    description
+      "Indicates that the server implements the
+       'generate-public-key' RPC.";
+  }
+
+  // Groupings
+
+  grouping transport-params-grouping {
+    description
+      "A reusable grouping for SSH transport parameters.";
+    reference
+      "RFC 4253: The Secure Shell (SSH) Transport Layer Protocol";
+    container host-key {
+      description
+        "Parameters regarding host key.";
+      leaf-list host-key-alg {
+        type identityref {
+          base sshpka:public-key-alg-base;
+        }
+        ordered-by user;
+        description
+          "Acceptable host key algorithms in order of descending
+           preference.  The configured host key algorithms should
+           be compatible with the algorithm used by the configured
+           private key.  Please see Section 5 of RFC EEEE for
+           valid combinations.
+
+           If this leaf-list is not configured (has zero elements)
+           the acceptable host key algorithms are implementation-
+           defined.";
+        reference
+          "RFC EEEE: YANG Groupings for SSH Clients and SSH Servers";
+      }
+    }
+    container key-exchange {
+      description
+        "Parameters regarding key exchange.";
+      leaf-list key-exchange-alg {
+        type identityref {
+          base sshkea:key-exchange-alg-base;
+        }
+        ordered-by user;
+        description
+          "Acceptable key exchange algorithms in order of descending
+           preference.
+
+           If this leaf-list is not configured (has zero elements)
+           the acceptable key exchange algorithms are implementation
+           defined.";
+      }
+    }
+    container encryption {
+      description
+        "Parameters regarding encryption.";
+      leaf-list encryption-alg {
+        type identityref {
+          base sshea:encryption-alg-base;
+        }
+        ordered-by user;
+        description
+          "Acceptable encryption algorithms in order of descending
+           preference.
+
+           If this leaf-list is not configured (has zero elements)
+           the acceptable encryption algorithms are implementation
+           defined.";
+      }
+    }
+    container mac {
+      description
+        "Parameters regarding message authentication code (MAC).";
+      leaf-list mac-alg {
+        type identityref {
+          base sshma:mac-alg-base;
+        }
+        ordered-by user;
+        description
+          "Acceptable MAC algorithms in order of descending
+           preference.
+
+           If this leaf-list is not configured (has zero elements)
+           the acceptable MAC algorithms are implementation-
+           defined.";
+      }
+    }
+  }
+
+  // Protocol-accessible Nodes
+
+  rpc generate-public-key {
+    if-feature "public-key-generation";
+    description
+      "Requests the device to generate an public key using
+       the specified key algorithm.";
+    input {
+      leaf algorithm {
+        type sshpka:public-key-algorithm-ref;
+        mandatory true;
+        description
+          "The algorithm to be used when generating the key.";
+      }
+      leaf bits {
+        type uint16;
+        description
+          "Specifies the number of bits in the key to create.
+           For RSA keys, the minimum size is 1024 bits and
+           the default is 3072 bits. Generally, 3072 bits is
+           considered sufficient. DSA keys must be exactly 1024
+           bits as specified by FIPS 186-2.  For ECDSA keys, the
+           'bits' value determines the key length by selecting
+           from one of three elliptic curve sizes: 256, 384 or
+           521 bits. Attempting to use bit lengths other than
+           these three values for ECDSA keys will fail. ECDSA-SK,
+           Ed25519 and Ed25519-SK keys have a fixed length and
+           the 'bits' value, if specified, will be ignored.";
+      }
+      choice private-key-encoding {
+        default cleartext;
+        description
+          "A choice amongst optional private key handling.";
+        case cleartext {
+          leaf cleartext {
+            type empty;
+            description
+              "Indicates that the private key is to be returned
+               as a cleartext value.";
+          }
+        }
+        case encrypt {
+          if-feature "ct:private-key-encryption";
+          container encrypt-with {
+            description
+               "Indicates that the key is to be encrypted using
+                the specified symmetric or asymmetric key.";
+            uses ks:encrypted-by-choice-grouping;
+          }
+        }
+        case hide {
+          if-feature "ct:hidden-keys";
+          leaf hide {
+            type empty;
+            description
+              "Indicates that the private key is to be hidden.
+
+               Unlike the 'cleartext' and 'encrypt' options, the
+               key returned is a placeholder for an internally
+               stored key.  See the 'Support for Built-in Keys'
+               section in RFC CCCC for information about hidden
+               keys.";
+          }
+        }
+      }
+    }
+    output {
+      uses ct:asymmetric-key-pair-grouping;
+    }
+  } // end generate-public-key
+
+}