Subject: [netconf] update to ssh-server draft

From: Balázs Kovács <[email-masked]>
Date: Fri, 22 Nov 2019 13:56:35 +0000

Hi,

The new local configuration in ssh-server draft seem to have some not appropriate terminology. The public key of the users should be maybe not called host keys?

In RFC7317:

            +--rw user* [name]
               +--rw name        string
               +--rw password?   ianach:crypt-hash
               +--rw authorized-key* [name]
                  +--rw name         string
                  +--rw algorithm    string
                  +--rw key-data     binary

In ietf-ssh-server@2019-11-20:

       |  +-- supported-authentication-methods

       |  |  +-- publickey?   empty

       |  |  +-- passsword?   empty

       |  |  +-- hostbased?   empty

       |  |  +-- none?        empty

       |  |  +-- other*       string

       |  +-- users {client-auth-config-supported}?

       |  |  +-- user* [name]

       |  |     +-- name?        string

       |  |     +-- password?    ianach:crypt-hash

       |  |     +-- host-keys!

       |  |        +---u ts:local-or-truststore-host-keys-grouping

Maybe this latter better serves hostbased key authentication? Was that really the intention? Should it be possible to select between user authorized key and host based auth? So for example, if one selects publickey, then should it still configure a trusted host key?

/Balazs

---

From: Kent Watsen <[email-masked]>
Date: Fri, 22 Nov 2019 15:49:21 +0000

Hi Balazs,
 
> The new local configuration in ssh-server draft seem to have some not appropriate terminology. The public key of the users should be maybe not called host keys?

Correct.  Martin raised this point on the 13th too (subject: "client identification in ietf-netconf-server")

> Maybe this latter better serves hostbased key authentication? Was that really the intention? Should it be possible to select between user authorized key and host based auth? So for example, if one…

The intention was to support "publickey" based auth (not "hostbased").  As I was telling Martin, it's the same key format, but it's called "hostkey" for servers and has no special name for clients.  I was being overzealous with naming it "hostkey" here.  

That said, there should be a way to configure authenticating clients for *all* the methods, including "hostbased", which isn't supported in the model yet...

Could provide a diff that irons out these issues?

Thanks,
Kent