Re: [Netconf] ietf-ssh-client@2018-06-04, issues with the grouping

[Balázs Kovács <[e-mail]>]

Hi Kent,

It is as you say, an app that can launch an interactive connection using previously configured client credentials, host authentication, and transport params.

My request or question would be if the current single grouping called ‘ssh-client-grouping’ could be split into two: one that only includes the ‘client-identity’ definition, and another which includes ‘server-auth’ and ‘transport-params’. I think this change would enable better flexibility for re-use in case of any SSH-based applications, and the only impact on the existing modules using ssh-client-grouping would be to use two groupings from now on instead of one.

Just to recap the use case, my intention would be to be able to mount a client identity into a list and into a container that is independent of the actual endpoint (for example, as defined in netconf-client /netconf-client/netconf-server/endpoints/endpoint) being used. Which identity is to be used is selected by interaction with the SSH client (e.g., via action parameter).

What do you think?

Br,
Balazs

From: Kent Watsen <[e-mail]>
Sent: Saturday, August 25, 2018 12:39 AM
To: Balázs Kovács <[e-mail]>; [e-mail]
Subject: Re: [Netconf] ietf-ssh-client@2018-06-04, issues with the grouping

Hi Balazs,

Why have configuration for an "interactive client" at all?   Is this an app that can launch an interactive connection using previously configured client credentials?  If so, then I think I understand the problem; the use case seems rather different than the use case that is currently being solved.

I understand the desire to have a YANG module to capture your config, and I understand the desire for that module to be able to make use of groupings defined in the ietf-ssh-client.

If the request is to expose a couple groupings, but otherwise leave the model unchanged, then I can see how that might be done.  But if the request is to change e.g., ssh-client-grouping, to support a decoupling of client credentials, then I don't see how to do that.

Kent // contributor


On 8/24/18, 10:14 AM, "Netconf on behalf of Balázs Kovács" <[e-mail]<mailto:[e-mail]> on behalf of [e-mail]<mailto:[e-mail]>> wrote:

Hi All,

I made an attempt to make use of the ietf-ssh-client@2018-06-04 module to configure an interactive ssh client, and I found some obstacles. The current ietf-ssh-client model has the following structure:

module: ietf-ssh-client
  +--rw client
     +--rw client-identity
     |  +--rw username?            string
     |  +--rw (auth-type)
     |     +--:(password)
     |     |  +--rw password?      string
     |     +--:(public-key)
     |     |  +--rw public-key
     |     +--:(certificate)
     |        +--rw certificate {sshcmn:ssh-x509-certs}?
     +--rw server-auth
     |  +--rw pinned-ssh-host-keys?   ta:pinned-host-keys-ref
     |  +--rw pinned-ca-certs?        ta:pinned-certificates-ref {sshcmn:ssh-x509-certs}?
     |  +--rw pinned-server-certs?    ta:pinned-certificates-ref {sshcmn:ssh-x509-certs}?
     +--rw transport-params {ssh-client-transport-params-config}?

In the netconf-client module, which I took as example it is mounted to the ‘ssh’ container and preceded by:

   module: ietf-netconf-client
     +--rw netconf-client
        +--rw initiate! {initiate}?
        |  +--rw netconf-server* [name]
        |     +--rw name                  string
        |     +--rw endpoints
        |     |  +--rw endpoint* [name]
        |     |     +--rw name         string
        |     |     +--rw (transport)
        |     |        +--:(ssh) {ssh-initiate}?
        |     |        |  +--rw ssh
        |     |        |     +--rw address?            inet:host
        |     |        |     +--rw port?               inet:port-number\

In the case of the interactive client, I want some limited parameters to be provided by the invoking user, which is at least the target user, target address, and target port, so  I would not need all the data nodes present in the netconf-client, but I need a subset of them, including the user credentials. The problem I face, is that for one target address, the user can select multiple target users, and for one target user, it should be able to select multiple target addresses. With the above model, if I want to set up a second client identity, I would basically need to create a complete endpoint with the same data in all the rest of the data nodes. Equally, if I want to set up a different endpoint, I need to copy all the possible client identities to be able to use them at other target addresses.

My thinking is that the endpoint related configuration (address, port, server-auth, transport-params) should be decoupled from client identities, so I can set them up and mount them independently.  However, I think this would effect the ssh-client grouping a bit heavily, basically breaking it up into two pieces. One that caters for the client identity, and another for the endpoint/server security.

One looking like this (temp name ‘ssh-client-client-identity-grouping’):


     grouping ssh-client-client-identity-grouping

       +-- client-identity

          +-- username?            string

          +-- (auth-type)

             +--:(password)

             |  +-- password?      string

             +--:(public-key)

             |  +-- public-key

             |     +---u ks:local-or-keystore-asymmetric-key-grouping

             +--:(certificate)

                +-- certificate {sshcmn:ssh-x509-certs}?

                   +---u ks:local-or-keystore-end-entity-certificate-grouping


And another (temp name ‘ssh-server-auth-transport-params-grouping’):





     grouping ssh-client-server-auth-transport-params-grouping

       +-- server-auth

       |  +-- pinned-ssh-host-keys?   ta:pinned-host-keys-ref

       |  +-- pinned-ca-certs?        ta:pinned-certificates-ref

       |  |       {sshcmn:ssh-x509-certs}?

       |  +-- pinned-server-certs?    ta:pinned-certificates-ref

       |          {sshcmn:ssh-x509-certs}?

       +-- transport-params {ssh-client-transport-params-config}?

          +---u sshcmn:transport-params-grouping



I also wonder if this would effect the similar module of tls-client. In TLS case, the client identity used is more bound to actual server and is rarely selectable by interaction, but splitting the current single grouping into two may probably not harm either.

Best Regards,
Balazs