NETCONF access-list

[wojciechlubas]

Hello everyone,

I would like to secure my router using Netconf with an access-list. Documentation says:

netconf-yang ssh {{ipv4 | ipv6 }access-list name access-list-name} | port port-number}

But on my router there is no such option:

router#netconf-yang ssh ?
port Starting (or only) Port number to listen on

router#netconf-yang ssh ipv4 access-list name test
                                        ^
% Invalid input detected at '^' marker.

Any ideas? Especially, that I am going to use NETCONF only in my Management vrf, and now is accessible via any public IP...

[Mark Elsen]

                                                 - Check these requirements :

         https://www.cisco.com/c/en/us/support/docs/storage-networking/management/200933-YANG-NETCONF-Configuration-Validation.html#anc2

 M.

[marinogr]

I have configured like configuration quide .

But the ACL is not working and does not show matches.

[jasonrob1]

Did you ever figure this out?  I'm having the same problem.

[marinogr]

Yes, the ACL is working but with connection reset and no ACL matching.

If you try you get:

From denied host:
D:\cmd>ssh xxxx@1.1.1.1 -p 830
kex_exchange_identification: read: Connection reset
Connection reset by 1.1.1.1 port 830

From the permitted host:
D:\cmd>ssh XXXX@1.1.1.1 -p 830
The authenticity of host '[1.1.1.1]:830 ([1.1.1.1]:830)' can't be established.
RSA key fingerprint is SHA256:xxxxxxxxxxxxxxxxxxxxxxxxxxx
This key is not known by any other names.
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added '[1.1.1.1]:830' (RSA) to the list of known hosts.
XXXX@1.1.1.1's password:

Also show tcp brief in not listed as port tcp 830, below reason why:

For the ‘show tcp brief all’ command, it’s expected that it will not show the port 830 as established/listen. With IOS-XE platforms, certain processes handle the communication. So, in order to check on the port, you can run below command instead:
9800-40-04# show platform software kernel TCP brief | inc 830
ncsshd 26710 22 LISTEN *:830
ncsshd 26710 25 LISTEN *:830

In above output, we do see that ‘ncsshd’ process, the main process of netconf, is listening on port 830.

[jasonrob1]

I actually reached the same conclusion after posted here.  This is very poor behavior in my opinion.  On the one hand it is great it is blocking the traffic however, you are still exposing a honey pot for anyone to see.  Definitely not ideal if you are using public IPs.  Wouldn't be so bad if you could bind the management plane to a single interface and/or vrf.  But in my case that is not an option.  Really the only thing to do here is not use netconf/restconf.