Solved: Re: preshared ssh key authentication with built in ssh server

Sean Chandler · ‎06-25-2018

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>

<ssh>

</ssh>

<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>

Sean Chandler · ‎07-26-2019

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!

View solution in original post

adam.allen · ‎06-25-2018

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

Sean Chandler · ‎06-25-2018

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

adam.allen · ‎06-25-2018

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

Sean Chandler · ‎06-25-2018

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!

adam.allen · ‎06-26-2018

It was a fresh install of NCS 4.6.1

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

<ncs-ipc-access-check>

<enabled>false</enabled>

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

</ncs-ipc-access-check>

<load-path>

<dir>./packages</dir>

</load-path>

<dir>./scripts</dir>

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

</scripts>

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

<event-streams>

<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>

<name>ncs-events</name>

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

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

<builtin-replay-store>

<dir>./state</dir>

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

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

</builtin-replay-store>

</stream>

<name>device-notifications</name>

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

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

<builtin-replay-store>

<dir>./state</dir>

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

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

</builtin-replay-store>

</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>

<cdb>

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

<init-path>

</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>

<key1>0123456789abcdef</key1>

<key2>0123456789abcdef</key2>

<key3>0123456789abcdef</key3>

<initVector>0123456789abcdef</initVector>

</DES3CBC>

<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>

<file>

</file>

</syslog>

</ncs-log>

<developer-log>

<file>

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

</file>

</developer-log>

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

<audit-log>

<file>

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

</file>

</audit-log>

<netconf-log>

<file>

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

</file>

</netconf-log>

<snmp-log>

<file>

</file>

</snmp-log>

<webui-browser-log>

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

</webui-browser-log>

<webui-access-log>

</webui-access-log>

<xpath-trace-log>

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

</xpath-trace-log>

<error-log>

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

</error-log>

<progress-trace>

</progress-trace>

</logs>

<ssh>

</algorithms>

</ssh>

<aaa>

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

<pam>

<service>common-auth</service>

</pam>

<external-authentication>

<enabled>false</enabled>

</external-authentication>

<local-authentication>

</local-authentication>

</aaa>

<crypt-hash>

</crypt-hash>

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

</rollback>

<cli>

<ssh>

</ssh>

<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>

<tcp>

</tcp>

<ssl>

<enabled>false</enabled>

<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>

<php>

<enabled>false</enabled>

</php>

</cgi>

</webui>

<rest>

</rest>

</restconf>

<netconf-north-bound>

<ssh>

</ssh>

<tcp>

<enabled>false</enabled>

</tcp>

</transport>

</netconf-north-bound>

<large-scale>

<lsa>

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

a separate Cisco Smart License.

-->

<enabled>false</enabled>

</lsa>

</large-scale>

</ncs-config>

Sean Chandler · ‎06-26-2018

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

rogaglia · ‎06-26-2018

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

Sean Chandler · ‎06-26-2018

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.

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:

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.

Sean Chandler · ‎06-27-2018

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.

Jan Lindblad · ‎08-03-2018

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==

Sean Chandler · ‎07-26-2019

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!