KeyPairs is not reflected to OpenStack

orkun34 commented 7 years ago

Hello,

Whenever I launch NSD with keypairs , it's not reflected to OpenStack side although it's shown in JSON file.

NSR JSON

VNFC Instance from OpenBaton

Same instance from OpenStack

I couldn't see any log that related about this.

Thanks in advance

gc4rella commented 7 years ago

The keypair mechanism provided via Open Baton does not make use of the OpenStack one, therefore you should not see it in OpenStack. The keypair is sent to the VNFM, and the VNFM decides what to do with that. In the case of the generic VNFM, the keypair is copied inside each VM automatically.

ashish235 commented 7 years ago

But there is something funny happening here. Let me give you an example.

from Openbaton, I generated a key - say "ashish-openbaton" and included it during launching the NSD.

The VNF is now running, I can see this in my cloud-init logs.

But when I try to ssh using that key, I can't.

On my openstack, I see some different key being used, which I had generated from Openstack. Key Name: ashish-ssh Image Name: oracle-working_backup_database

And the funny thing is, I can actually use this key to ssh into the VNF.

Regards, Ashish

gc4rella commented 7 years ago

@ashish235 you need to provide more information in order to understand why your keypair is not passed into the VNF by the generic-vnfm. Typically, the generic-vnfm uses cloud-init to inject the keypair in the VM where the VNF is runnnig. So, cloud-init logs should provide some more hints about what's not working.

lorenzotomasini commented 7 years ago

@ashish235 I can also confirm that this feature is working with any image with cloud init (ubuntu or centos) i am using it pretty often. Do you have any further comments or we can close the issue?

ashish235 commented 7 years ago

@lorenzotomasini &, I 'm still having this issue. I 'm using the official centos7 image for openstack, which has cloud-init it int. But the image I onboarded from Openbaton was an instance snapshot and the snapshot had a different key, which I 'm able to use with the new onboarded image. So snapshot images might have the issue. I didn't try it with the base image yet.
@gc4rella , I have pasted my cloud-init logs in my earlier comment. Do you need any additional information?

lorenzotomasini commented 7 years ago

which version of NFVO? can you post all cloud init logs in a gist link?

ashish235 commented 7 years ago

@lorenzotomasini, here's the gist link: https://gist.github.com/ashish235/f798359361bfc68840d63e737933eb1a

Some info - Key created and injected from my openbaton is "ashish-baton". Key file generated is "ashish-baton.pem" After using the key from my ssh client, I get the error in Secure logs.

Jul 24 05:07:14 test sshd[1461]: error: Received disconnect from 172.16.129.246: 14: No supported authentication methods available [preauth]

When used my other key, which was used for the snapshot:

Jul 24 05:03:16 test sshd[1024]: pam_unix(sshd:session): session opened for user centos by (uid=0) Jul 24 05:03:58 test sshd[1141]: Accepted publickey for centos from 172.16.129.246 port 19467 ssh2: RSA c1:ea:67:6e:72:39:0c:66:40:94:9f:19:08:6d:b9:96

Is there any difference in the way, how the keys generated from Openstack and Openbaton be used? I 'm using use private key box and I select the .pem file to login.

lorenzotomasini commented 7 years ago

well the good thing is that the key is there.

can you also print the full log of the command:

ssh -v -i ashish-baton.pem centos@VM_IP

ashish235 commented 7 years ago

@lorenzotomasini , it worked when I used it with a ssh command from a linux server.

ashish@Ubuntu14:~$ ssh -v -i /tmp/ashish-baton.pem centos@172.16.110.14 OpenSSH_6.6.1, OpenSSL 1.0.1f 6 Jan 2014 debug1: Reading configuration data /etc/ssh/ssh_config debug1: /etc/ssh/ssh_config line 19: Applying options for debug1: Connecting to 172.16.110.14 [172.16.110.14] port 22. debug1: Connection established. debug1: identity file /tmp/ashish-baton.pem type -1 debug1: identity file /tmp/ashish-baton.pem-cert type -1 debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_6.6.1p1 Ubuntu-2ubuntu2.8 debug1: Remote protocol version 2.0, remote software version OpenSSH_6.6.1 debug1: match: OpenSSH_6.6.1 pat OpenSSH_6.6.1 compat 0x04000000 debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug1: kex: server->client aes128-ctr hmac-md5-etm@openssh.com none debug1: kex: client->server aes128-ctr hmac-md5-etm@openssh.com none debug1: sending SSH2_MSG_KEX_ECDH_INIT debug1: expecting SSH2_MSG_KEX_ECDH_REPLY debug1: Server host key: ECDSA ac:95:12:24:2a:66:e2:51:fa:f5:a5:33:e4:54:66:53 debug1: Host '172.16.110.14' is known and matches the ECDSA host key. debug1: Found key in /home/alepo/.ssh/known_hosts:1 debug1: ssh_ecdsa_verify: signature correct debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug1: SSH2_MSG_NEWKEYS received debug1: SSH2_MSG_SERVICE_REQUEST sent debug1: SSH2_MSG_SERVICE_ACCEPT received debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic debug1: Next authentication method: gssapi-keyex debug1: No valid Key exchange context debug1: Next authentication method: gssapi-with-mic debug1: Unspecified GSS failure. Minor code may provide more information No Kerberos credentials available

debug1: Unspecified GSS failure. Minor code may provide more information No Kerberos credentials available

debug1: Unspecified GSS failure. Minor code may provide more information

debug1: Unspecified GSS failure. Minor code may provide more information No Kerberos credentials available

debug1: Next authentication method: publickey debug1: Trying private key: /tmp/ashish-baton.pem debug1: key_parse_private2: missing begin marker debug1: read PEM private key done: type RSA debug1: Authentication succeeded (publickey). Authenticated to 172.16.110.14 ([172.16.110.14]:22). debug1: channel 0: new [client-session] debug1: Requesting no-more-sessions@openssh.com debug1: Entering interactive session. debug1: Sending environment. debug1: Sending env LANG = en_IN Last login: Mon Jul 24 12:54:39 2017 from 172.16.111.94 [centos@aaa-server-2962600 ~]$

So, yes the key is there on the server. Strange that my SSH client (MobaXterm) on my windows can use that key. Will debug that a bit on the client. I think we can close this issue.

Thanks for the help.

ashish235 commented 7 years ago

@lorenzotomasini the key didn't work from WINSCP or Putty too. Whereas the keys generated from Openstack always work with my ssh clients. What's the difference between Openstack and Openbaton generated keys, that Openbaton keys only works with SSH from a linux server. I 'm completely clueless.

ashish235 commented 7 years ago

@lorenzotomasini, can you please update me if you have any idea on this issue. The issue is in still in open state and the label is "wontfix", so I 'm in bit of dilemma here.

lorenzotomasini commented 7 years ago

Hi @ashish235

we are generating the key in this way and then pushing it into the authorized file in the VM via user data.

I don't know if we tested using other tool but our reference is the unix ssh command, and with this one works pretty good.

I know the key management could be improved and it is in our roadmap for future development, but for now and for this release we are planning to keep this approach, unless bugs of course.

openbaton / NFVO

KeyPairs is not reflected to OpenStack #149