netconf device sync fromm get Protocol error

[sm000x]

Hi,

I have a strange issue and I cannot figure out what was wrong.

I have a netconf device but when I do sync-from I got error:
admin@ncs> request devices device zrdm60gcsmf01 sync-from
result false
info Failed to connect to device zrdm60gcsmf01: Protocol error
[ok][2024-02-18 13:33:20]
admin@ncs> exit

and the trace log size is 0:
-rw-rw-r--. 1 sm000x sm000x 0 Feb 18 13:33 netconf-zrdm60gcsmf01.trace

However, I am able to use
ssh -s sm000x@zrdm60gcsmf01-ip-addess -p 22 netconf

to invoke the netconf (Although it takes longer than usual time)

The device type is netconf:
admin@ncs> show configuration devices device zrdm60gcsmf01
address x.x.x.x;
port 22;
authgroup SMF;
device-type {
netconf {
ned-id smf-nc-1.0;
}
}
state {
admin-state unlocked;
}

I am able to do sync-from to other device with the same authgroup and ned-id:
dmin@ncs> request devices device z68bcsmf01 sync-from
result true
[ok][2024-02-18 13:49:42]

admin@ncs> show configuration devices device z68bcsmf01
address x.x.x.x;
port 22;
authgroup SMF;
device-type {
netconf {
ned-id smf-nc-1.0;
}
}
state {
admin-state unlocked;
}

Does anyone have same expierence?
What does "Protocol error" mean?

THX
sm000x

[ygorelik]

One of the reasons could be that SSH RSA algorithm on the device is not included to the NSO global settings. Hence the communication with the device fails. You can check the algorithm used by your device in the ~/.ssh/known_hosts file. In NSO check the global setting like this:

admin@ncs> show configuration devices global-settings ssh-algorithms public-key 

public-key [ ssh-ed25519 ecdsa-sha2-nistp256 ecdsa-sha2-nistp384 ecdsa-sha2-nistp521 rsa-sha2-512 rsa-sha2-256 ssh-rsa ssh-dss ];

Make sure the algorithm is listed. If not, modify the global settings by adding the missing algorithm.

[sm000x]

Hi, ygorelik:

Thank you for the suggestion.

I checked global setting:
admin@ncs> show configuration devices global-settings ssh-algorithms public-key
public-key [ ssh-ed25519 ecdsa-sha2-nistp256 ecdsa-sha2-nistp384 ecdsa-sha2-nistp521 rsa-sha2-512 rsa-sha2-256 ];

Then I added the missing algorithm:
admin@ncs% set devices global-settings ssh-algorithms public-key [ ssh-ed25519 ecdsa-sha2-nistp256 ecdsa-sha2-nistp384 ecdsa-sha2-nistp521 rsa-sha2-512 rsa-sha2-256 ssh-rsa ssh-dss ]
[ok][2024-02-20 08:31:02]
[edit]
admin@ncs% commit
Commit complete.

But it still fail:
admin@ncs> request devices device zrdm60gcsmf01 ssh fetch-host-keys
result updated
fingerprint {
algorithm ssh-ed25519
value 77:a5:d4:e5:d0:1c:ca:18:d4:e0:36:f4:d6:7b:b0:b1
}
fingerprint {
algorithm ecdsa-256
value a0:a9:c8:4c:37:37:de:a5:5d:fa:0a:ca:f7:70:71:df
}
fingerprint {
algorithm ssh-rsa
value 1f:bb:4a:95:93:9e:aa:46:f3:44:d4:6c:d1:ac:65:1d
}
[ok][2024-02-20 08:31:58]
admin@ncs> request devices device zrdm60gcsmf01 sync-from
result false
info Failed to connect to device zrdm60gcsmf01: Protocol error
[ok][2024-02-20 08:32:14]

THX
sm000x

[cohult]

Hi, 
One possible reason can be that the device SSH server has keyboard-interactive authentication enabled, tries keyboard-interactive authentication before trying public-key authentication, and behaves non-standard for the keyboard-interactive authentication.

The OpenSSH client may timeout the keyboard-interactive authentication and try the next authentication method, public-key authentication, while the NSO SSH client reports a protocol error.

If the keyboard-interactive authentication type is enabled for the device SSH server, try disabling it. 

Also, try adding a "-v" or "-vv" when testing with the OpenSSH "ssh" client to debug why the device "takes longer than usual" to invoke NETCONF.

Regards

[ygorelik]

It is great that 'ssh fetch-host-keys' worked! That shows SSH communication is working. Some netconf devices require to do 'connect' before the 'sync-from'. I have seen this behavior while working on device-onboarding package. Please try this before going into further investigations.

[sm000x]

Hi, ygorelik:

It is interesting, even the connect gets the same error:

admin@ncs> request devices device zrdm60gcsmf01 connect
result false
info Failed to connect to device zrdm60gcsmf01: Protocol error
[ok][2024-02-20 12:26:18]
admin@ncs> request devices device zrdm60gcsmf01 disconnect
[ok][2024-02-20 12:26:26]
admin@ncs> request devices device zrdm60gcsmf01 connect
result false
info Failed to connect to device zrdm60gcsmf01: Protocol error
[ok][2024-02-20 12:26:40]

THX
sm000x

[cohult]

---

@ygorelik wrote:

It is great that 'ssh fetch-host-keys' worked! That shows SSH communication is working.

---

The SSH authentication is likely failing as I wrote above. @sm000x, have you ready my post?

[sm000x]

Hi, cohult:

Sorry. I gave you wrong trace (the device is wrong), here is the trace of the device in question:

[sm000x@mtnjdslncs06 ~]$ ssh -v [email protected]
OpenSSH_7.4p1, OpenSSL 1.0.2k-fips 26 Jan 2017
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 58: Applying options for *
debug1: Connecting to 166.193.178.44 [166.193.178.44] port 22.
debug1: Connection established.
debug1: key_load_public: No such file or directory
debug1: identity file /home/sm000x/.ssh/id_rsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/sm000x/.ssh/id_rsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/sm000x/.ssh/id_dsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/sm000x/.ssh/id_dsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/sm000x/.ssh/id_ecdsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/sm000x/.ssh/id_ecdsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/sm000x/.ssh/id_ed25519 type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/sm000x/.ssh/id_ed25519-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_7.4
debug1: Remote protocol version 2.0, remote software version OpenSSH_8.8
debug1: match: OpenSSH_8.8 pat OpenSSH* compat 0x04000000
debug1: Authenticating to 166.193.178.44:22 as 'sm000x'
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: [email protected]
debug1: kex: host key algorithm: ecdsa-sha2-nistp256
debug1: kex: server->client cipher: aes128-ctr MAC: hmac-sha2-256 compression: none
debug1: kex: client->server cipher: aes128-ctr MAC: hmac-sha2-256 compression: none
debug1: kex: [email protected] need=32 dh_need=32
debug1: kex: [email protected] need=32 dh_need=32
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ecdsa-sha2-nistp256 SHA256:sy46Glg7HYidUHaTb0DJYiIhTTuS8ahT4gO9ewo6oKI
debug1: Host '166.193.178.44' is known and matches the ECDSA host key.
debug1: Found key in /home/sm000x/.ssh/known_hosts:2
debug1: rekey after 4294967296 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: rekey after 4294967296 blocks
debug1: SSH2_MSG_EXT_INFO received
debug1: kex_input_ext_info: server-sig-algs=
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,keyboard-interactive
debug1: Next authentication method: publickey
debug1: Trying private key: /home/sm000x/.ssh/id_rsa
debug1: Trying private key: /home/sm000x/.ssh/id_dsa
debug1: Trying private key: /home/sm000x/.ssh/id_ecdsa
debug1: Trying private key: /home/sm000x/.ssh/id_ed25519
debug1: Next authentication method: keyboard-interactive
Password:

But

admin@ncs> request devices device zrdm60gcsmf01 connect | details debug
2024-02-21T08:55:38.735 device zrdm60gcsmf01: connect...
2024-02-21T08:55:38.736 device zrdm60gcsmf01: SSH connecting to admin@zrdm60gcsmf01
2024-02-21T08:55:45.278 device zrdm60gcsmf01: connect: error (6.543 s)
result false
info Failed to connect to device zrdm60gcsmf01: Protocol error
[ok][2024-02-21 08:55:45]
admin@ncs>

THX
sm000x

[cohult]

Hi @sm000x,

You cut out the interesting part. What comes after "debug1: Next authentication method: keyboard-interactive\n Password:" is likely what is breaking the standard (RFC 4256)

The OpenSSH client is an open-source project that tolerates non-compliant messages and waits until the expected message is eventually received. NSO expects a compliant message, and the protocol error occurs when a non-compliant message is received.

If the device is from vendor H, you can log in to the SSH server CLI and run the undo SSH server authentication-type keyboard-interactive enable command to disable "keyboard-interactive" authentication.
Since you do not use "publickey" authentication, you likely need to enable "password" authentication on the device.

[sm000x]

Hi, cohult:

Sorry that I cut out the important part, here is the post again.

[sm000x@mtnjdslncs06 ~]$ ssh -vv [email protected]
OpenSSH_7.4p1, OpenSSL 1.0.2k-fips 26 Jan 2017
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 58: Applying options for *
debug2: resolving "166.193.178.44" port 22
debug2: ssh_connect_direct: needpriv 0
debug1: Connecting to 166.193.178.44 [166.193.178.44] port 22.
debug1: Connection established.
debug1: key_load_public: No such file or directory
debug1: identity file /home/sm000x/.ssh/id_rsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/sm000x/.ssh/id_rsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/sm000x/.ssh/id_dsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/sm000x/.ssh/id_dsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/sm000x/.ssh/id_ecdsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/sm000x/.ssh/id_ecdsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/sm000x/.ssh/id_ed25519 type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/sm000x/.ssh/id_ed25519-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_7.4
debug1: Remote protocol version 2.0, remote software version OpenSSH_8.8
debug1: match: OpenSSH_8.8 pat OpenSSH* compat 0x04000000
debug2: fd 3 setting O_NONBLOCK
debug1: Authenticating to 166.193.178.44:22 as 'sm000x'
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug2: local client KEXINIT proposal
debug2: KEX algorithms: curve25519-sha256,[email protected],ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha256,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1,ext-info-c
debug2: host key algorithms: [email protected],[email protected],[email protected],ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,[email protected],[email protected],[email protected],ssh-ed25519,rsa-sha2-512,rsa-sha2-256,ssh-rsa,ssh-dss
debug2: ciphers ctos: [email protected],aes128-ctr,aes192-ctr,aes256-ctr,[email protected],[email protected],aes128-cbc,aes192-cbc,aes256-cbc
debug2: ciphers stoc: [email protected],aes128-ctr,aes192-ctr,aes256-ctr,[email protected],[email protected],aes128-cbc,aes192-cbc,aes256-cbc
debug2: MACs ctos: [email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: MACs stoc: [email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: compression ctos: none,[email protected],zlib
debug2: compression stoc: none,[email protected],zlib
debug2: languages ctos:
debug2: languages stoc:
debug2: first_kex_follows 0
debug2: reserved 0
debug2: peer server KEXINIT proposal
debug2: KEX algorithms: [email protected],diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha1
debug2: host key algorithms: ssh-ed25519,ecdsa-sha2-nistp256,ssh-rsa
debug2: ciphers ctos: aes256-ctr,aes192-ctr,aes128-ctr
debug2: ciphers stoc: aes256-ctr,aes192-ctr,aes128-ctr
debug2: MACs ctos: hmac-sha2-512,hmac-sha2-256
debug2: MACs stoc: hmac-sha2-512,hmac-sha2-256
debug2: compression ctos: none,[email protected]
debug2: compression stoc: none,[email protected]
debug2: languages ctos:
debug2: languages stoc:
debug2: first_kex_follows 0
debug2: reserved 0
debug1: kex: algorithm: [email protected]
debug1: kex: host key algorithm: ecdsa-sha2-nistp256
debug1: kex: server->client cipher: aes128-ctr MAC: hmac-sha2-256 compression: none
debug1: kex: client->server cipher: aes128-ctr MAC: hmac-sha2-256 compression: none
debug1: kex: [email protected] need=32 dh_need=32
debug1: kex: [email protected] need=32 dh_need=32
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ecdsa-sha2-nistp256 SHA256:sy46Glg7HYidUHaTb0DJYiIhTTuS8ahT4gO9ewo6oKI
debug1: Host '166.193.178.44' is known and matches the ECDSA host key.
debug1: Found key in /home/sm000x/.ssh/known_hosts:2
debug2: set_newkeys: mode 1
debug1: rekey after 4294967296 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug2: set_newkeys: mode 0
debug1: rekey after 4294967296 blocks
debug2: key: /home/sm000x/.ssh/id_rsa ((nil))
debug2: key: /home/sm000x/.ssh/id_dsa ((nil))
debug2: key: /home/sm000x/.ssh/id_ecdsa ((nil))
debug2: key: /home/sm000x/.ssh/id_ed25519 ((nil))
debug1: SSH2_MSG_EXT_INFO received
debug1: kex_input_ext_info: server-sig-algs=
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,keyboard-interactive
debug1: Next authentication method: publickey
debug1: Trying private key: /home/sm000x/.ssh/id_rsa
debug1: Trying private key: /home/sm000x/.ssh/id_dsa
debug1: Trying private key: /home/sm000x/.ssh/id_ecdsa
debug1: Trying private key: /home/sm000x/.ssh/id_ed25519
debug2: we did not send a packet, disable method
debug1: Next authentication method: keyboard-interactive
debug2: userauth_kbdint
debug2: we sent a keyboard-interactive packet, wait for reply
debug2: input_userauth_info_req
debug2: input_userauth_info_req: num_prompts 1
Password:
debug2: input_userauth_info_req
debug2: input_userauth_info_req: num_prompts 0

You are in Privilege Class (FULLACCESS)
debug1: Authentication succeeded (keyboard-interactive).
Authenticated to 166.193.178.44 ([166.193.178.44]:22).
debug1: channel 0: new [client-session]
debug2: channel 0: send open
debug1: Requesting [email protected]
debug1: Entering interactive session.
debug1: pledge: network
debug1: client_input_global_request: rtype [email protected] want_reply 0
debug2: callback start
debug2: fd 3 setting TCP_NODELAY
debug2: client_session2_setup: id 0
debug2: channel 0: request pty-req confirm 1
debug1: Sending environment.
debug1: Sending env LANG = en_US.UTF-8
debug2: channel 0: request env confirm 0
debug2: channel 0: request shell confirm 1
debug2: callback done
debug2: channel 0: open confirm rwindow 0 rmax 32768
debug2: channel_input_status_confirm: type 99 id 0
debug2: PTY allocation request accepted on channel 0
debug2: channel 0: rcvd adjust 2097152
debug2: channel_input_status_confirm: type 99 id 0
debug2: shell request accepted on channel 0

You are in Privilege Class (FULLACCESS)
Last login: Wed Feb 21 13:54:58 UTC 2024 from 192.168.218.64 on ssh

User sm000x last logged in 2024-02-20T13:45:54.816261+00:00, to pod-cfgmgr-865fbc4c55-c7qw2, from 192.168.35.128 using cli-ssh
sm000x connected from 192.168.220.128 using ssh on zrdm60gcsmf01
sm000x@zrdm60gcsmf01 05:20:39#

THX
sm000x

[cohult]

Hi @sm000x,

---

@sm000x wrote:
Sorry that I cut out the important part, here is the post again.
[sm000x@mtnjdslncs06 ~]$ ssh -vv [email protected]

---

You are showing the debug info for when you are connecting to a CLI? You cannot connect to a CLI using a NETCONF NED.
I was expecting the OpenSSH client debug output when connecting to the NETCONF subsystem. Something like:

ssh -vv -s [email protected] netconf

[sm000x]

Hi, cohult:

Terrible sorry. Here is the new:

[root@mtnjdslncs06 ~]# ssh -vv -s [email protected] -p 22 netconf
OpenSSH_7.4p1, OpenSSL 1.0.2k-fips 26 Jan 2017
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 58: Applying options for *
debug2: resolving "166.193.178.44" port 22
debug2: ssh_connect_direct: needpriv 0
debug1: Connecting to 166.193.178.44 [166.193.178.44] port 22.
debug1: Connection established.
debug1: permanently_set_uid: 0/0
debug1: key_load_public: No such file or directory
debug1: identity file /root/.ssh/id_rsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /root/.ssh/id_rsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /root/.ssh/id_dsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /root/.ssh/id_dsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /root/.ssh/id_ecdsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /root/.ssh/id_ecdsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /root/.ssh/id_ed25519 type -1
debug1: key_load_public: No such file or directory
debug1: identity file /root/.ssh/id_ed25519-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_7.4
debug1: Remote protocol version 2.0, remote software version OpenSSH_8.8
debug1: match: OpenSSH_8.8 pat OpenSSH* compat 0x04000000
debug2: fd 3 setting O_NONBLOCK
debug1: Authenticating to 166.193.178.44:22 as 'sm000x'
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug2: local client KEXINIT proposal
debug2: KEX algorithms: curve25519-sha256,[email protected],ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha256,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1,ext-info-c
debug2: host key algorithms: [email protected],[email protected],[email protected],[email protected],[email protected],[email protected],ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-ed25519,rsa-sha2-512,rsa-sha2-256,ssh-rsa,ssh-dss
debug2: ciphers ctos: [email protected],aes128-ctr,aes192-ctr,aes256-ctr,[email protected],[email protected],aes128-cbc,aes192-cbc,aes256-cbc
debug2: ciphers stoc: [email protected],aes128-ctr,aes192-ctr,aes256-ctr,[email protected],[email protected],aes128-cbc,aes192-cbc,aes256-cbc
debug2: MACs ctos: [email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: MACs stoc: [email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: compression ctos: none,[email protected],zlib
debug2: compression stoc: none,[email protected],zlib
debug2: languages ctos:
debug2: languages stoc:
debug2: first_kex_follows 0
debug2: reserved 0
debug2: peer server KEXINIT proposal
debug2: KEX algorithms: [email protected],diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha1
debug2: host key algorithms: ssh-ed25519,ecdsa-sha2-nistp256,ssh-rsa
debug2: ciphers ctos: aes256-ctr,aes192-ctr,aes128-ctr
debug2: ciphers stoc: aes256-ctr,aes192-ctr,aes128-ctr
debug2: MACs ctos: hmac-sha2-512,hmac-sha2-256
debug2: MACs stoc: hmac-sha2-512,hmac-sha2-256
debug2: compression ctos: none,[email protected]
debug2: compression stoc: none,[email protected]
debug2: languages ctos:
debug2: languages stoc:
debug2: first_kex_follows 0
debug2: reserved 0
debug1: kex: algorithm: [email protected]
debug1: kex: host key algorithm: ecdsa-sha2-nistp256
debug1: kex: server->client cipher: aes128-ctr MAC: hmac-sha2-256 compression: none
debug1: kex: client->server cipher: aes128-ctr MAC: hmac-sha2-256 compression: none
debug1: kex: [email protected] need=32 dh_need=32
debug1: kex: [email protected] need=32 dh_need=32
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ecdsa-sha2-nistp256 SHA256:sy46Glg7HYidUHaTb0DJYiIhTTuS8ahT4gO9ewo6oKI
The authenticity of host '166.193.178.44 (166.193.178.44)' can't be established.
ECDSA key fingerprint is SHA256:sy46Glg7HYidUHaTb0DJYiIhTTuS8ahT4gO9ewo6oKI.
ECDSA key fingerprint is MD5:a0:a9:c8:4c:37:37:de:a5:5d:fa:0a:ca:f7:70:71:df.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '166.193.178.44' (ECDSA) to the list of known hosts.
debug2: set_newkeys: mode 1
debug1: rekey after 4294967296 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug2: set_newkeys: mode 0
debug1: rekey after 4294967296 blocks
debug2: key: /root/.ssh/id_rsa ((nil))
debug2: key: /root/.ssh/id_dsa ((nil))
debug2: key: /root/.ssh/id_ecdsa ((nil))
debug2: key: /root/.ssh/id_ed25519 ((nil))
debug1: SSH2_MSG_EXT_INFO received
debug1: kex_input_ext_info: server-sig-algs=
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,keyboard-interactive
debug1: Next authentication method: publickey
debug1: Trying private key: /root/.ssh/id_rsa
debug1: Trying private key: /root/.ssh/id_dsa
debug1: Trying private key: /root/.ssh/id_ecdsa
debug1: Trying private key: /root/.ssh/id_ed25519
debug2: we did not send a packet, disable method
debug1: Next authentication method: keyboard-interactive
debug2: userauth_kbdint
debug2: we sent a keyboard-interactive packet, wait for reply
debug2: input_userauth_info_req
debug2: input_userauth_info_req: num_prompts 1
Password:
debug2: input_userauth_info_req
debug2: input_userauth_info_req: num_prompts 0

You are in Privilege Class (FULLACCESS)
debug1: Authentication succeeded (keyboard-interactive).
Authenticated to 166.193.178.44 ([166.193.178.44]:22).
debug1: channel 0: new [client-session]
debug2: channel 0: send open
debug1: Requesting [email protected]
debug1: Entering interactive session.
debug1: pledge: network
debug1: client_input_global_request: rtype [email protected] want_reply 0
debug2: callback start
debug2: fd 3 setting TCP_NODELAY
debug2: client_session2_setup: id 0
debug1: Sending environment.
debug1: Sending env LANG = en_US.UTF-8
debug2: channel 0: request env confirm 0
debug1: Sending subsystem: netconf
debug2: channel 0: request subsystem confirm 1
debug2: callback done
debug2: channel 0: open confirm rwindow 0 rmax 32768
debug2: channel 0: rcvd adjust 2097152
debug2: channel_input_status_confirm: type 99 id 0
debug2: subsystem request accepted on channel 0



urn:ietf:params:netconf:base:1.0
urn:ietf:params:netconf:base:1.1
urn:ietf:params:netconf:capability:confirmed-commit:1.1
urn:ietf:params:netconf:capability:confirmed-commit:1.0
urn:ietf:params:netconf:capability:writable-running:1.0
urn:ietf:params:netconf:capability:candidate:1.0
urn:ietf:params:netconf:capability:rollback-on-error:1.0
urn:ietf:params:netconf:capability:url:1.0?scheme=ftp,sftp,file
urn:ietf:params:netconf:capability:validate:1.0
urn:ietf:params:netconf:capability:validate:1.1
urn:ietf:params:netconf:capability:xpath:1.0
urn:ietf:params:netconf:capability:notification:1.0
urn:ietf:params:netconf:capability:partial-lock:1.0
urn:ietf:params:netconf:capability:with-defaults:1.0?basic-mode=report-all
urn:ietf:params:netconf:capability:with-operational-defaults:1.0?basic-mode=report-all
urn:ietf:params:netconf:capability:yang-library:1.0?revision=2019-01-04&module-set-id=baf58cc11ed263ae2fd7b649aa12fe1a
urn:ietf:params:netconf:capability:yang-library:1.1?revision=2019-01-04&content-id=baf58cc11ed263ae2fd7b649aa12fe1a
http://tail-f.com/ns/netconf/actions/1.0
http://affirmednetworks.com/ns/yang/affirmed?module=affirmed
http://affirmednetworks.com/ns/yang/bgpmgr?module=bgpmgr&revision=2019-05-25
http://affirmednetworks.com/ns/yang/cna-cfgmgr?module=cna-cfgmgr&revision=2018-07-24
http://affirmednetworks.com/ns/yang/cna-chfagent?module=cna-chfagent&revision=2022-11-22
http://affirmednetworks.com/ns/yang/cna-event-exposure?module=cna-event-exposure&revision=2022-03-14
http://affirmednetworks.com/ns/yang/cna-gtpcagent?module=cna-gtpcagent&revision=2019-11-06
http://affirmednetworks.com/ns/yang/cna-interface-mgr?module=cna-interface-mgr&revision=2019-04-05
http://affirmednetworks.com/ns/yang/cna-li-x1?module=cna-li-x1&revision=2022-12-06
http://affirmednetworks.com/ns/yang/cna-li-x2?module=cna-li-x2
http://affirmednetworks.com/ns/yang/cna-pfcp?module=cna-pfcp&revision=2022-01-31
http://affirmednetworks.com/ns/yang/cna-pfcp-cp?module=cna-pfcp-cp&revision=2022-03-21
http://affirmednetworks.com/ns/yang/cna-radiusagent?module=cna-radiusagent&revision=2023-07-03
http://affirmednetworks.com/ns/yang/cna-routing?module=cna-routing&revision=2021-10-06
http://affirmednetworks.com/ns/yang/cna-smf?module=cna-smf&revision=2023-08-09
http://affirmednetworks.com/ns/yang/cna-smfmonitor?module=cna-smfmonitor&revision=2019-11-01
http://affirmednetworks.com/ns/yang/cna/cna-nrf-agent?module=cna-nrf-agent&revision=2021-11-15
http://affirmednetworks.com/ns/yang/cna/cna-sub_analyzer?module=cna-sub_analyzer&revision=2023-03-07
http://affirmednetworks.com/ns/yang/dataplane-agent?module=dataplane-agent&revision=2019-05-25
http://affirmednetworks.com/ns/yang/lb-ppe?module=lb-ppe&revision=2023-04-05
http://affirmednetworks.com/ns/yang/ribmgr?module=ribmgr&revision=2019-05-25
http://tail-f.com/ns/common/query?module=tailf-common-query&revision=2017-12-15
http://tail-f.com/ns/confd-progress?module=tailf-confd-progress&revision=2020-06-29
http://tail-f.com/ns/ietf-subscribed-notifications-deviation?module=ietf-subscribed-notifications-deviation&revision=2020-06-25
http://tail-f.com/ns/ietf-yang-push-deviation?module=ietf-yang-push-deviation
http://tail-f.com/ns/kicker?module=tailf-kicker&revision=2020-11-26
http://tail-f.com/ns/netconf/query?module=tailf-netconf-query&revision=2017-01-06
http://tail-f.com/yang/acm?module=tailf-acm&revision=2013-03-07
http://tail-f.com/yang/common?module=tailf-common&revision=2022-09-29
http://tail-f.com/yang/common-monitoring?module=tailf-common-monitoring&revision=2022-09-29
http://tail-f.com/yang/common-monitoring2?module=tailf-common-monitoring2&revision=2022-09-29
http://tail-f.com/yang/confd-monitoring?module=tailf-confd-monitoring&revision=2022-09-29
http://tail-f.com/yang/confd-monitoring2?module=tailf-confd-monitoring2&revision=2022-10-03
http://tail-f.com/yang/last-login?module=tailf-last-login&revision=2019-11-21
http://tail-f.com/yang/netconf-monitoring?module=tailf-netconf-monitoring&revision=2022-04-12
http://tail-f.com/yang/xsd-types?module=tailf-xsd-types&revision=2017-11-20
urn:ietf:params:xml:ns:netconf:base:1.0?module=ietf-netconf&revision=2011-06-01&features=writable-running,confirmed-commit,candidate,rollback-on-error,validate,xpath,url
urn:ietf:params:xml:ns:netconf:partial-lock:1.0?module=ietf-netconf-partial-lock&revision=2009-10-19
urn:ietf:params:xml:ns:yang:iana-crypt-hash?module=iana-crypt-hash&revision=2014-08-06&features=crypt-hash-sha-512,crypt-hash-sha-256,crypt-hash-md5
urn:ietf:params:xml:ns:yang:ietf-inet-types?module=ietf-inet-types&revision=2013-07-15
urn:ietf:params:xml:ns:yang:ietf-netconf-acm?module=ietf-netconf-acm&revision=2018-02-14
urn:ietf:params:xml:ns:yang:ietf-netconf-monitoring?module=ietf-netconf-monitoring&revision=2010-10-04
urn:ietf:params:xml:ns:yang:ietf-netconf-notifications?module=ietf-netconf-notifications&revision=2012-02-06
urn:ietf:params:xml:ns:yang:ietf-netconf-with-defaults?module=ietf-netconf-with-defaults&revision=2011-06-01
urn:ietf:params:xml:ns:yang:ietf-restconf-monitoring?module=ietf-restconf-monitoring&revision=2017-01-26
urn:ietf:params:xml:ns:yang:ietf-x509-cert-to-name?module=ietf-x509-cert-to-name&revision=2014-12-10
urn:ietf:params:xml:ns:yang:ietf-yang-metadata?module=ietf-yang-metadata&revision=2016-08-05
urn:ietf:params:xml:ns:yang:ietf-yang-types?module=ietf-yang-types&revision=2013-07-15

17819]]>]]>

THX
sm000x

[cohult]

The "authgroup SMF" configuration in NSO, is that authgroup configured to use public-key authentication or password authentication?

In NSO:

admin@ncs> show configuration devices authgroups group SMF

[sm000x]

Hi, cohult:

admin@ncs> show configuration devices authgroups group SMF
umap admin {
remote-name m97292;
remote-password $9$6eX7f+EhCadYo9i+gxo67EXbB/sbYDsaf1JXvGlgWuM=;
}
[ok][2024-02-21 13:38:35]
admin@ncs>

THX
sm000x

[cohult]

It is likely the banner that follows the password that is the cause of the protocol error. It seems like OpenSSH ignores the non-standard messages until the expected packet/message is received, but NSO follows the standard strictly and does not expect it.

You are in Privilege Class (FULLACCESS)

Also, it does not make sense to have a banner for a machine-to-machine interface like NETCONF. For a human-to-machine CLI interface, yes.
If you set verbosity three, "ssh -vvv -s [email protected] -p 22 netconf", you will likely see something like:

Password:
debug3: send packet: type 61
debug3: receive packet: type 53
debug3: input_userauth_banner

You are in Privilege Class (FULLACCESS)

Where the NSO NETCONF over SSH client implementation does not expect a type 53 input_user_auth packet with a "You are in Privilege Class (FULLACCESS)" banner instead of a type 52 authentication succeeded.

I believe your options with this device are, for example:

• Configure the device to replace the keyboard-interactive authentication method with the password (or public-key) authentication method. The other device you mentioned works and seems to successfully use the password authentication method.
  
• Configure the device to not send a banner.
• Ask your NSO contact for a custom NETCONF NED that can handle the unexpected authentication.