Hi,
Is that possible to modify ssh key for an instance while it is running!! Imagine that we did not mention the key in nova boot command but later once trying to access it we should add a ssh key !!1
Thanks for any response !
Thanks for response.
Actually, I found many problem with sshing the instances even whiile proceeding by creating the ssh key first with nova keypair-add command line and then boot new instance by specifying the keyname but once ssh the instance it still not accpeted . I was following documentation in OpenStack website and get in -verbose mode such output:
ssh -vvvvvvvvvvvvv -i mykey root@10.10.10.1 OpenSSH_5.9p1 Debian-5ubuntu1, OpenSSL 1.0.1 14 Mar 2012 Warning: Identity file mykey not accessible: No such file or directory. debug1: Reading configuration data /etc/ssh/ssh_config debug1: /etc/ssh/ssh_config line 19: Applying options for * debug2: ssh_connect: needpriv 0 debug1: Connecting to 10.10.10.1 [10.10.10.1] port 22. debug1: Connection established. debug1: permanently_set_uid: 0/0 debug3: Incorrect RSA1 identifier debug3: Could not load "/root/.ssh/id_rsa" as a RSA1 public key debug1: identity file /root/.ssh/id_rsa type 1 debug1: Checking blacklist file /usr/share/ssh/blacklist.RSA-2048 debug1: Checking blacklist file /etc/ssh/blacklist.RSA-2048 debug1: identity file /root/.ssh/id_rsa-cert type -1 debug1: identity file /root/.ssh/id_dsa type -1 debug1: identity file /root/.ssh/id_dsa-cert type -1 debug1: identity file /root/.ssh/id_ecdsa type -1 debug1: identity file /root/.ssh/id_ecdsa-cert type -1 debug1: Remote protocol version 2.0, remote software version OpenSSH_5.9p1 Debian-5ubuntu1 debug1: match: OpenSSH_5.9p1 Debian-5ubuntu1 pat OpenSSH* debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_5.9p1 Debian-5ubuntu1 debug2: fd 3 setting O_NONBLOCK debug3: load_hostkeys: loading entries for host "10.10.10.1" from file "/root/.ssh/known_hosts" debug3: load_hostkeys: found key type ECDSA in file /root/.ssh/known_hosts:1 debug3: load_hostkeys: loaded 1 keys debug3: order_hostkeyalgs: prefer hostkeyalgs: ecdsa-sha2-nistp256-cert-v01@openssh.... debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug2: kex_parse_kexinit: ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1 debug2: kex_parse_kexinit: ecdsa-sha2-nistp256-cert-v01@openssh.... debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcf... debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcf... debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64@openssh.co... debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64@openssh.co... debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: first_kex_follows 0 debug2: kex_parse_kexinit: reserved 0 debug2: kex_parse_kexinit: ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1 debug2: kex_parse_kexinit: ssh-rsa,ssh-dss,ecdsa-sha2-nistp256 debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcf... debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcf... debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64@openssh.co... debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64@openssh.co... debug2: kex_parse_kexinit: none,zlib@openssh.com debug2: kex_parse_kexinit: none,zlib@openssh.com debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: first_kex_follows 0 debug2: kex_parse_kexinit: reserved 0 debug2: mac_setup: found hmac-md5 debug1: kex: server->client aes128-ctr hmac-md5 none debug2: mac_setup: found hmac-md5 debug1: kex: client->server aes128-ctr hmac-md5 none debug1: sending SSH2_MSG_KEX_ECDH_INIT debug1: expecting SSH2_MSG_KEX_ECDH_REPLY debug1: Server host key: ECDSA c6:8c:20:18:6d:e3:23:30:1f:25:0b:d4:10:31:0c:f2 debug3: load_hostkeys: loading entries for host "172.16.0.14" from file "/root/.ssh/known_hosts" debug3: load_hostkeys: found key type ECDSA in file /root/.ssh/known_hosts:1 debug3: load_hostkeys ...
no, AFAIK.
There are options to change the root password, dependent on having an agent running in the instance, and depending on the hypervisor you are using.
What you could do is take a snapshot, boot a new instance from that snapshot, and specify a key to get injected.
First you need to check your key got added OK, it probably did, but worth making sure it look OK in Horizon/web gui. I normally create a brand new key, and so need to use the new private key when logging in.
OpenStack has to inject the key into the instance. It depends what image you have, but normally you would have cloud-init that picks up the ssh key from the metadata service (if you use cirros or the ubuntu cloud image).
What image are you using? Are you using config drive or the metadata service? Those kinds of things are worth checking.
These are the docs I remember helped me: http://docs.openstack.org/trunk/openstack-compute/admin/content/booting-a-test-image.html (http://docs.openstack.org/trunk/opens...)
Hey John,
Thanks for resopnse. In fact, I am using cirros image. But what cloud-init does with that ?
Asked: 2013-02-18 13:00:41 -0600
Seen: 966 times
Last updated: Feb 19 '13
