cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1012
Views
10
Helpful
11
Replies
Highlighted
Cisco Employee

preshared ssh key authentication with built in ssh server

I've enabled the internal NSO ssh server on port 2024 and can login just fine.  What I'd like to do is use preshared SSH keys instead of password to authenticate that connection.  what configuration do i need to make this work?

admin connected from 127.0.0.1 using console on innopod-ncs

admin@ncs> show configuration aaa | display set

set aaa authentication users user nsouser uid 1000

set aaa authentication users user nsouser gid 1000

set aaa authentication users user nsouser password $6$dOwNDroEdN7i9KBA$1xtMPoqXF7TW9yi2VfqL3yTnUyNgrew1kPZECrYio4rLWtJMjmOqA3bcJZC4.etkrUo9RQn9FKtZejGI33TQK0

set aaa authentication users user nsouser ssh_keydir /home/nsouser/.ssh

set aaa authentication users user nsouser homedir /home/nsouser/

  <cli>

    <enabled>true</enabled>


    <!-- Use the builtin SSH server -->

    <ssh>

      <enabled>true</enabled>

      <ip>0.0.0.0</ip>

      <port>2024</port>

    </ssh>


    <prompt1>\u@ncs> </prompt1>

    <prompt2>\u@ncs% </prompt2>


    <c-prompt1>\u@ncs# </c-prompt1>

    <c-prompt2>\u@ncs(\m)# </c-prompt2>


    <restricted-file-access>true</restricted-file-access>

    <show-log-directory>${NCS_LOG_DIR}</show-log-directory>

    <show-commit-progress>true</show-commit-progress>

    <suppress-commit-message-context>maapi</suppress-commit-message-context>

    <suppress-commit-message-context>system</suppress-commit-message-context>

  </cli>

Everyone's tags (5)
1 ACCEPTED SOLUTION

Accepted Solutions
Cisco Employee

Re: preshared ssh key authentication with built in ssh server

Finally got around to retesting this.  Turns out if you generate a key with a comment containing spaces NSO will call it a bad key.

 

BAD: ssh-keygen -C ‘NSO SSH Key' -t rsa -f ./scripts/.ssh/id_rsa -N ''

 

vs

 

GOOD: ssh-keygen -C 'NSO-SSH-Key' -t rsa -f ./scripts/.ssh/id_rsa -N ''

 

SOLVED!

11 REPLIES 11
Beginner

Re: preshared ssh key authentication with built in ssh server

If you hadn't already looked, it's worth tailing auth.log - that gave me useful messages.

I don't have anything special in the configuration over and above what you have.

I noticed in the log file that NCS was looking for authorized_key2 rather than authorized_keys.

Adam

Cisco Employee

Re: preshared ssh key authentication with built in ssh server

Thanks for jumping in! Have you been able to get this working then? Which version? I’m on 4.5.3 I believe.

Just checked and I see the following:

25-Jun-2018::18:32:48.488 innopod-ncs ncs[21]: audit user: /0 login failed via cli from 172.17.42.1:59335 with ssh: Presented a bad key

Which isn’t super-duper helpful but it is something at least. Looked in the logs and didn’t find any complaints about authorized_keys variable. Was guessing that maybe the permissions were not quite right but don’t have anything to support that.

root@innopod-ncs:/var/log/ncs# ls -la /home/nsouser/.ssh/authorized_keys

-rw-rr 1 root root 381 Jun 25 18:32 /home/nsouser/.ssh/authorized_keys

root@innopod-ncs:/var/log/ncs# ls -la /home/nsouser/.ssh

total 8

drw

Beginner

Re: preshared ssh key authentication with built in ssh server

NCS 4.6.1 (a local install, with local authentication) - is what I tested

NCS 4.4.4 (a system install, with PAM authentication) it looks like it *should* work - except NCS has no permission to read into my home-directory to get the key (but the log is meaningful in the case ;-).

Adam

Cisco Employee

Re: preshared ssh key authentication with built in ssh server

So 4.6.1 at least was able to authenticate a user with preshared key alone, no password. Would you post the ncs.config?  I may just have something messed up there.

thanks!

Beginner

Re: preshared ssh key authentication with built in ssh server

It was a fresh install of NCS 4.6.1

<!-- -*- nxml -*- -->

<!-- Example configuration file for ncs. -->

<ncs-config xmlns="http://tail-f.com/yang/tailf-ncs-config">

  <!-- NCS can be configured to restrict access for incoming connections -->

  <!-- to the IPC listener sockets. The access check requires that -->

  <!-- connecting clients prove possession of a shared secret. -->

  <ncs-ipc-access-check>

    <enabled>false</enabled>

    <filename>${NCS_DIR}/etc/ncs/ipc_access</filename>

  </ncs-ipc-access-check>

  <!-- Where to look for .fxs and snmp .bin files to load -->

  <load-path>

    <dir>./packages</dir>

    <dir>${NCS_DIR}/etc/ncs</dir>

    <!-- To disable northbound snmp altogether -->

    <!-- comment out the path below -->

    <dir>${NCS_DIR}/etc/ncs/snmp</dir>

  </load-path>

  <!-- Plug and play scripting -->

  <scripts>

    <dir>./scripts</dir>

    <dir>${NCS_DIR}/scripts</dir>

  </scripts>

  <state-dir>./state</state-dir>

  <notifications>

    <event-streams>

      <!-- This is the builtin stream used by NCS to generate northbound -->

      <!-- notifications whenever the alarm table is changed. -->

      <!-- See tailf-ncs-alarms.yang -->

      <!-- If you are not interested in NCS northbound netconf notifications -->

      <!-- remove this item since it does consume some CPU -->

      <stream>

        <name>ncs-alarms</name>

        <description>NCS alarms according to tailf-ncs-alarms.yang</description>

        <replay-support>false</replay-support>

        <builtin-replay-store>

          <enabled>false</enabled>

          <dir>./state</dir>

          <max-size>S10M</max-size>

          <max-files>50</max-files>

        </builtin-replay-store>

      </stream>

      <!-- This is the builtin stream used by NCS to generate northbound -->

      <!-- notifications for internal events. -->

      <!-- See tailf-ncs-devices.yang -->

      <!-- Required for cluster mode. -->

      <stream>

        <name>ncs-events</name>

        <description>NCS event according to tailf-ncs-devices.yang</description>

        <replay-support>true</replay-support>

        <builtin-replay-store>

          <enabled>true</enabled>

          <dir>./state</dir>

          <max-size>S10M</max-size>

          <max-files>50</max-files>

        </builtin-replay-store>

      </stream>

      <!-- This is the builtin stream used by NCS to generate northbound -->

      <!-- notifications forwarded from devices. -->

      <!-- See tailf-event-forwarding.yang -->

      <stream>

        <name>device-notifications</name>

        <description>NCS events forwarded from devices</description>

        <replay-support>true</replay-support>

        <builtin-replay-store>

          <enabled>true</enabled>

          <dir>./state</dir>

          <max-size>S10M</max-size>

          <max-files>50</max-files>

        </builtin-replay-store>

      </stream>

      <!-- This is the builtin stream used by NCS to generate northbound -->

      <!-- notifications for plan state transitions. -->

      <!-- See tailf-ncs-plan.yang -->

      <stream>

        <name>service-state-changes</name>

        <description>Plan state transitions according to

        tailf-ncs-plan.yang</description>

        <replay-support>false</replay-support>

        <builtin-replay-store>

          <enabled>false</enabled>

          <dir>./state</dir>

          <max-size>S10M</max-size>

          <max-files>50</max-files>

        </builtin-replay-store>

      </stream>

    </event-streams>

  </notifications>

  <!-- Where the database (and init XML) files are kept -->

  <cdb>

    <db-dir>./ncs-cdb</db-dir>

    <!-- Always bring in the good system defaults -->

    <init-path>

      <dir>${NCS_DIR}/var/ncs/cdb</dir>

    </init-path>

  </cdb>

  <!--

      These keys are used to encrypt values of the types

      tailf:des3-cbc-encrypted-string and tailf:aes-cfb-128-encrypted-string.

      For a deployment install it is highly recommended to change

      these numbers to something random (done by NCS "system install")

  -->

  <encrypted-strings>

    <DES3CBC>

      <key1>0123456789abcdef</key1>

      <key2>0123456789abcdef</key2>

      <key3>0123456789abcdef</key3>

      <initVector>0123456789abcdef</initVector>

    </DES3CBC>

    <AESCFB128>

      <key>0123456789abcdef0123456789abcdef</key>

      <initVector>0123456789abcdef0123456789abcdef</initVector>

    </AESCFB128>

  </encrypted-strings>

  <logs>

    <syslog-config>

      <facility>daemon</facility>

      <udp>

        <enabled>false</enabled>

        <host>syslogsrv.example.com</host>

      </udp>

    </syslog-config>

    <ncs-log>

      <enabled>true</enabled>

      <file>

        <name>./logs/ncs.log</name>

        <enabled>true</enabled>

      </file>

      <syslog>

        <enabled>true</enabled>

      </syslog>

    </ncs-log>

    <developer-log>

      <enabled>true</enabled>

      <file>

        <name>./logs/devel.log</name>

        <enabled>true</enabled>

      </file>

    </developer-log>

    <developer-log-level>trace</developer-log-level>

    <audit-log>

      <enabled>true</enabled>

      <file>

        <name>./logs/audit.log</name>

        <enabled>true</enabled>

      </file>

    </audit-log>

    <netconf-log>

      <enabled>true</enabled>

      <file>

        <name>./logs/netconf.log</name>

        <enabled>true</enabled>

      </file>

    </netconf-log>

    <snmp-log>

      <enabled>true</enabled>

      <file>

        <name>./logs/snmp.log</name>

        <enabled>true</enabled>

      </file>

    </snmp-log>

    <webui-browser-log>

      <enabled>true</enabled>

      <filename>./logs/webui-browser.log</filename>

    </webui-browser-log>

    <webui-access-log>

      <enabled>true</enabled>

      <dir>./logs</dir>

    </webui-access-log>

    <!-- This log is disabled by default if ncs is installed using -->

    <!-- the 'system-install' flag. It consumes a lot of CPU power -->

    <!-- to have this log turned on, OTOH it is the best tool to -->

    <!-- debug must expressions in YANG models -->

    <xpath-trace-log>

      <enabled>true</enabled>

      <filename>./logs/xpath.trace</filename>

    </xpath-trace-log>

    <error-log>

      <enabled>true</enabled>

      <filename>./logs/ncserr.log</filename>

    </error-log>

    <progress-trace>

      <enabled>true</enabled>

      <dir>./logs</dir>

    </progress-trace>

  </logs>

  <ssh>

    <algorithms>

      <mac>hmac-sha1,hmac-sha2-256,hmac-sha2-512</mac>

      <encryption>aes128-ctr,aes192-ctr,aes256-ctr</encryption>

    </algorithms>

  </ssh>

  <aaa>

    <ssh-server-key-dir>${NCS_DIR}/etc/ncs/ssh</ssh-server-key-dir>

    <!-- Depending on OS - and also depending on user requirements -->

    <!-- the pam service value value must be tuned. -->

    <pam>

      <enabled>true</enabled>

      <service>common-auth</service>

    </pam>

    <external-authentication>

      <enabled>false</enabled>

      <executable>my-test-auth.sh</executable>

    </external-authentication>

    <local-authentication>

      <enabled>true</enabled>

    </local-authentication>

  </aaa>

  <!-- Hash algorithm used when setting leafs of type ianach:crypt-hash, -->

  <!-- e.g. /aaa/authentication/users/user/password -->

  <crypt-hash>

    <algorithm>sha-512</algorithm>

  </crypt-hash>

  <!-- Disable this for performance critical applications, enabling -->

  <!-- rollbacks means additional disk IO for each transaction -->

  <rollback>

    <enabled>true</enabled>

    <directory>./logs</directory>

    <history-size>500</history-size>

  </rollback>

  <cli>

    <enabled>true</enabled>

    <!-- Use the builtin SSH server -->

    <ssh>

      <enabled>true</enabled>

      <ip>0.0.0.0</ip>

      <port>2024</port>

    </ssh>

    <prompt1>\u@ncs> </prompt1>

    <prompt2>\u@ncs% </prompt2>

    <c-prompt1>\u@ncs# </c-prompt1>

    <c-prompt2>\u@ncs(\m)# </c-prompt2>

    <show-log-directory>./logs</show-log-directory>

    <show-commit-progress>true</show-commit-progress>

    <suppress-commit-message-context>maapi</suppress-commit-message-context>

    <suppress-commit-message-context>system</suppress-commit-message-context>

  </cli>

  <webui>

    <enabled>true</enabled>

    <transport>

      <tcp>

        <enabled>true</enabled>

        <ip>0.0.0.0</ip>

        <port>8080</port>

      </tcp>

      <ssl>

        <enabled>false</enabled>

        <ip>0.0.0.0</ip>

        <port>8888</port>

        <key-file>${NCS_DIR}/var/ncs/webui/cert/host.key</key-file>

        <cert-file>${NCS_DIR}/var/ncs/webui/cert/host.cert</cert-file>

      </ssl>

    </transport>

    <cgi>

      <enabled>true</enabled>

      <php>

        <enabled>false</enabled>

      </php>

    </cgi>

  </webui>

  <rest>

    <enabled>true</enabled>

  </rest>

  <restconf>

    <enabled>true</enabled>

  </restconf>

  <netconf-north-bound>

    <enabled>true</enabled>

    <transport>

      <ssh>

        <enabled>true</enabled>

        <ip>0.0.0.0</ip>

        <port>2022</port>

      </ssh>

      <tcp>

        <enabled>false</enabled>

        <ip>127.0.0.1</ip>

        <port>2023</port>

      </tcp>

    </transport>

  </netconf-north-bound>

  <!-- <ha> -->

  <!--   <enabled>true</enabled> -->

  <!-- </ha> -->

  <large-scale>

    <lsa>

      <!-- Enable Layered Service Architecture, LSA. This requires

           a separate Cisco Smart License.

      -->

      <enabled>false</enabled>

    </lsa>

  </large-scale>

</ncs-config>

Cisco Employee

Re: preshared ssh key authentication with built in ssh server

Thanks for that. My config matches now but no success. I still get the error:

26-Jun-2018::14:18:05.414 innopod-ncs ncs[21]: audit user: /0 login failed via cli from 172.17.42.1:59133 with ssh: Presented a bad key

No matter what config I’ve used (below). Even found a configuration ‘ssh-pubkey-authentication’ in the docs but that doesn’t appear to change the behavior. Something must be wrong either with the directory permissions or the file format or something but it is nothing I can find.

Pretty stuck here. Good news it is trying to authorized via preshared key but frustrating that there is no additional information to say why it is invalid :/

root@innopod-ncs:/home/nsouser# ll .ssh

total 16

drwx

Cisco Employee

Re: preshared ssh key authentication with built in ssh server

Hi,

Two ideas:

1- check if there is relevant info in the traces for the develop.log. To enable traces in your ncs.conf file:

/ncs-config/logs/developer-log-level (error | info | trace) [info]

2- add verbosity to your ssh client connection. Sometimes the problem is a missmatch between the algorithms and that is clear in the SSH exchanges.

Good luck!

Roque

Cisco Employee

Re: preshared ssh key authentication with built in ssh server

Thanks for the suggestions Roque!

No help with upped logging but here is my ssh -vvv result. Looked online quite a bit to see if there is an issue with public key mismatch or permissions or something like that but no help there. I decided to compare results using the same user/key and added this public key to the root user locally and grabbed the verbose messages there. Below are two runs, one to NSO and one to the local system so same client/user but different target. Appears that NSO straight up does not like my public key at all but no indication as to why. Looks like it tries DSA and ECDSA etc but I don’t have those. Guess I can generate them and try them next. Pretty sure RSA should work though.

  1. DIDN’T WORK

debug1: Authentications that can continue: publickey,password

debug3: start over, passed a different list publickey,password

debug3: preferred gssapi-keyex,gssapi-with-mic,publickey,keyboard-interactive,password

debug3: authmethod_lookup publickey

debug3: remaining preferred: keyboard-interactive,password

debug3: authmethod_is_enabled publickey

debug1: Next authentication method: publickey

debug1: Trying private key: /home/localadmin/.ssh/id_rsa

debug1: key_parse_private2: missing begin marker

debug1: read PEM private key done: type RSA

debug3: sign_and_send_pubkey: RSA 70:a9:98:d2:93:22:01:76:23:8f:de:30:91:2d:74:ce

debug2: we sent a publickey packet, wait for reply

debug1: Authentications that can continue: publickey,password

debug1: Trying private key: /home/localadmin/.ssh/id_dsa

debug3: no such identity: /home/localadmin/.ssh/id_dsa: No such file or directory

debug1: Trying private key: /home/localadmin/.ssh/id_ecdsa

debug3: no such identity: /home/localadmin/.ssh/id_ecdsa: No such file or directory

debug1: Trying private key: /home/localadmin/.ssh/id_ed25519

debug3: no such identity: /home/localadmin/.ssh/id_ed25519: No such file or directory

debug2: we did not send a packet, disable method

debug3: authmethod_lookup password

debug3: remaining preferred: ,password

debug3: authmethod_is_enabled password

debug1: Next authentication method: password

nsouser@0.0.0.0's password:

  1. WORKED TO LOCAL SYSTEM

debug1: Authentications that can continue: publickey,password

debug3: start over, passed a different list publickey,password

debug3: preferred gssapi-keyex,gssapi-with-mic,publickey,keyboard-interactive,password

debug3: authmethod_lookup publickey

debug3: remaining preferred: keyboard-interactive,password

debug3: authmethod_is_enabled publickey

debug1: Next authentication method: publickey

debug1: Trying private key: /home/localadmin/.ssh/id_rsa

debug1: key_parse_private2: missing begin marker

debug1: read PEM private key done: type RSA

debug3: sign_and_send_pubkey: RSA 70:a9:98:d2:93:22:01:76:23:8f:de:30:91:2d:74:ce

debug2: we sent a publickey packet, wait for reply

debug1: Authentication succeeded (publickey).

Authenticated to 127.0.0.1 (:22).

debug1: channel 0: new

debug3: ssh_session2_open: channel_new: 0

debug2: channel 0: send open

debug1: Requesting no-more-sessions@openssh.com

debug1: Entering interactive session.

Cisco Employee

Re: preshared ssh key authentication with built in ssh server

Upgraded to 4.6.1 and have the exact same issue: Presented a bad key.

There is some basic issue where the service either doesnt find the key in the right place or thinks it is invalid.

Cisco Employee

Re: preshared ssh key authentication with built in ssh server

Checked the sources, and the message "Presented a bad key". Apparently this message is printed if the server was able to load up all the ssh keys for this user (there could be more than one, potentially), and decode the received key from the client. Finally, that decoded key is not one of the ssh keys for this user. So it basically means wrong key (sort of like a bad password). It seems the public key in authenticated_users doesn't match the private key you're giving in the ssh client. There are other error messages for other situations, e.g. when the key can't be read, it's the wrong format etc.

 

Tried this myself now, and for me it worked immediately. Here's what I did:
$ ssh admin@localhost -p 2024
Warning: Permanently added '[localhost]:2024' (RSA) to the list of known hosts.
admin@localhost's password:

admin connected from 127.0.0.1 using ssh on JLINDBLA-M-W0J2
admin@JLINDBLA-M-W0J2> con
 
This was with a password. Then configured the ssh_dir for the admin user:
 
admin@JLINDBLA-M-W0J2% set aaa authentication users user admin ssh_keydir /tmp/zz homedir /tmp/zz
[ok][2018-08-03 16:44:35]

[edit]
admin@JLINDBLA-M-W0J2% comm
Commit complete.
 
Then went to create some keys in that dir.
 
$ mkdir zz
$ chmod 755 zz
$ cd zz
$ ssh-keygen -t rsa -b 1024 -f tst
Generating public/private rsa key pair.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in tst.
Your public key has been saved in tst.pub.
The key fingerprint is:
SHA256:+7AxoHZJ0M6ExEmSmaTGUimAKEWTOrTr21OVX1ksFeM jlindbla@JLINDBLA-M-W0J2
The key's randomart image is:
+---[RSA 1024]----+
|=+BOo.      o+.  |
|*+*+oo     ..o.  |
|==. o o .   +E   |
|=.   = o   o     |
| ..   * S .      |
| .   + o o       |
|.   + o =        |
| ..o .   *       |
| ....   . .      |
+----[SHA256]-----+
$ cp tst.pub authorized_keys
$ cp tst.pub authorized_keys2
$ ssh -i /tmp/zz/tst admin@localhost -p 2024
Warning: Permanently added '[localhost]:2024' (RSA) to the list of known hosts.

admin connected from 127.0.0.1 using ssh on JLINDBLA-M-W0J2
admin@JLINDBLA-M-W0J2>
 
No password second time. (Not sure if it's authorized_keys or authorized_keys2, so copied to both here).
 
$ cat authorized_keys
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAAAgQCgn4X9pHEM9Bp9c/4Sb8Ygs0yfOEDcKIDICu9ZtYv/1X2vMF0wCpUFrSUWQbMOtFCWDZKaJw2KHe0Y2LnZDr5eVh96IMLCEKalZpx478L5pkescrTkRXz77rmATB7ym9OdAvQA1/vQrx83bAOpZvLDZA4K9d9N2I0Cl+/MlLheNQ==
Cisco Employee

Re: preshared ssh key authentication with built in ssh server

Finally got around to retesting this.  Turns out if you generate a key with a comment containing spaces NSO will call it a bad key.

 

BAD: ssh-keygen -C ‘NSO SSH Key' -t rsa -f ./scripts/.ssh/id_rsa -N ''

 

vs

 

GOOD: ssh-keygen -C 'NSO-SSH-Key' -t rsa -f ./scripts/.ssh/id_rsa -N ''

 

SOLVED!