Nova 没法向虚机注入密钥

时间 2019-12-08

标签 nova 没法注入密钥繁體版

原文原文链接

欢迎各位关注个人博客：http://weibo.com/u/216633637 html

废话开头：node

以前参考这位同窗的博客http://www.cnblogs.com/awy-blog/p/3447176.html，同时综合OpenStack的ubuntu的官方安装文档，在修改了一些小错误以后，成功地用三台普通的物理PC机搭了一个OpenStack的环境，各项服务、功能都测试了一遍，感受还能够。不事后来，因为其中的一台物理机被别人拿走以后，因而乎没继续使用测试了，转而去研究代码了。git

后来，因为某种需求，又要开从新搭建这个环境。没有够多的物理机，因而乎开始使用楼下的一台刀片服务器来完了，12核24线程、40多G的大内存，4块500G的硬盘，够给力了，跑三个虚拟机来搭OpenStack的环境也绰绰有余了。可是，搭完以后，问题就来了，发现没法向虚机注入密钥，也就是用ssh密钥登陆虚机了。这对那些必须须要使用密钥登陆的镜像来讲仍是有很大的不便。github

下面开始步入正题：web

在node4上面架设三个kvm的虚机，分别跑controller、network、compter，如今已经成功把openstack跑起来了，能够运行实例，neutron组网没问题，虚机内外网都能ping通，可是当我想用ssh密钥登陆时发现：先前导入的密钥对，没法将公钥导入到虚机中，以致于无法实现密钥登陆。

虚机起来后，查看日志/var/log/nova/nova-api.log ：ubuntu

2014-03-08 15:36:02.347 16855 INFO nova.metadata.wsgi.server [-] (16855) accepted ('192.168.122.3', 55466)

 

2014-03-08 15:36:02.349 16855 WARNING nova.api.metadata.handler [-] X-Instance-ID-Signature: ed0c9bbac98384bb1d4f2b0923e33488af7ac2fbbaac0aef6fe2b80257cded79 does not match the expected value: 93008c9f8f5a8ddda5a9fd48fb29b53db2e2ef1c76684ef4f6e5152fc951885d for id: c011b486-3cfd-4e33-8fb8-526abe1e51fb. Request From: 10.50.50.2

2014-03-08 15:36:02.350 16855 INFO nova.api.ec2 [-] 0.1089s 192.168.122.3 GET /2009-04-04/meta-data/public-hostname None:None 403 [Python-httplib2/0.7.2 (gzip)] text/plain text/plain

2014-03-08 15:36:02.350 16855 INFO nova.metadata.wsgi.server [-] 10.50.50.2,192.168.122.3 "GET /2009-04-04/meta-data/public-hostname HTTP/1.1" status: 403len: 176 time: 0.0018518

 

2014-03-08 15:36:02.865 16855 WARNING nova.api.metadata.handler [-] X-Instance-ID-Signature: ed0c9bbac98384bb1d4f2b0923e33488af7ac2fbbaac0aef6fe2b80257cded79 does not match the expected value: 93008c9f8f5a8ddda5a9fd48fb29b53db2e2ef1c76684ef4f6e5152fc951885d for id: c011b486-3cfd-4e33-8fb8-526abe1e51fb. Request From: 10.50.50.2

2014-03-08 15:36:02.867 16855 INFO nova.api.ec2 [-] 0.1279s 192.168.122.3 GET /2009-04-04/meta-data/placement/availability-zone None:None 403 [Python-httplib2/0.7.2 (gzip)] text/plain text/plain

2014-03-08 15:36:02.868 16855 INFO nova.metadata.wsgi.server [-] 10.50.50.2,192.168.122.3 "GET /2009-04-04/meta-data/placement/availability-zone HTTP/1.1" status: 403len: 176 time: 0.0024281

在dashboard的界面里面，查看虚机的日志中提示错误：vim

checking http://169.254.169.254/2009-04-04/instance-id
failed 1/20: up 10.44. iid had '<html>
<head>
<title>500 Internal Server Error</title>
</head>
<body>
<h1>500 Internal Server Error</h1>
An unknown error has occurred. Please try your request again.<br /><br />api

而当我登陆虚拟，查看里面的~/.ssh/authorized_keys里面内容不是要注入的公钥，正是上面出错的html页面代码！服务器

在虚机中运行curl检测以下：网络

$ curl -I http://169.254.169.254/2009-04-04/meta-data/instance-id

HTTP/1.1 500 Internal Server Error

Content-Type: text/html; charset=UTF-8

Content-Length: 0

Date: Sat, 08 Mar 2014 09:45:57 GMT

我知道应该是nova-api-metadata的问题，但这个该怎么解决呢？

开始，我也以为是网络的问题，总感受169.254.169.254很奇怪，后来一搜才知道是为了兼容 amazon 的 EC2 ，才把获取metadata的ip也写死成这个，不过在openstack里面，经过iptables映射成controller的ip并对应8775端口。从nova-api.log的日志分析，显然在computer的虚机10.50.50.2的请求，是已经被在controller的nova-api-metadata的服务获取到了。可是 “WARNING nova.api.metadata.handler [-] X-Instance-ID-Signature”，这说明X-Instance-ID-Signature 验证不经过，致使metadata server 拒绝请求，从而引起了：10.50.50.2,192.168.122.3 "GET /2009-04-04/meta-data/public-hostname HTTP/1.1" status: 403 len: 176 time: 0.0018518，即服务端返回403的错误代码，而在虚机中则获得了HTTP 500的错误响应。

后来问题搞定了，当我去分别查找Network node 上面的nova/api/metadata/handler.py ，以及在网络节点的neutron/agent/metadata/agent.py 去比较如何处理X-Instance-ID-Signature的时候，发现以下：

         if resp.status == 200:
             LOG.debug(str(resp))
             return content
         elif resp.status == 403:
             msg = _(
                 'The remote metadata server responded with Forbidden. This'
                 'response usually occurs when shared secrets do not match.'
            )
             LOG.warn(msg)
             return webob.exc.HTTPForbidden()
         elif resp.status == 404:
             return webob.exc.HTTPNotFound()
         elif resp.status == 409:
             return webob.exc.HTTPConflict()
         elif resp.status == 500:
             msg = _(
                 'Remote metadata server experienced an internal server error.'
             )
             LOG.warn(msg)
             return webob.exc.HTTPInternalServerError(explanation=unicode(msg))
         else:
             raise Exception(_('Unexpected response code: %s') % resp.status)

显然提示403出错的代码，是由于“The remote metadata server responded with Forbidden. This response usually occurs when shared secrets do not match.”，即提示 share secrets 不匹配。这个我很早就注意到了，网上的提示的方法也是这么说的。我当时很肯定地把nova.conf 的service_neutron_metadata_proxy 设为true，而且neutron_metadata_proxy_shared_secret 跟neutron里面的metadata_agent.ini同样都是helloOpenStack，这个是我反复检查过的。但是，让我万万没想到的是。。。。。。。

当我vim查看metadata_agent.ini的文件时，无心间看到一句comment：

# When proxying metadata requests, Neutron signs the Instance-ID header with a
# shared secret to prevent spoofing. You may select any string for a secret,
# but it must match here and in the configuration used by the Nova Metadata
# Server. NOTE: Nova uses a different key: neutron_metadata_proxy_shared_secret

我靠！nova.conf与metadata_agent.ini里面关于share secret 的字段名是不同的！！！一个是neutron_metadata_proxy_shared_secret,而另外一个倒是metadata_proxy_shared_secret

天杀的，好大一个坑。。。。。。。。。

关于metadata的注入流程分析，能够参考贤哥的两篇文章：

【OpenStack】metadata在OpenStack中的使用：

http://blog.csdn.net/lynn_kong/article/details/9115033

　　　　　　　　　　　　　　　　　　　　　　　　 http://lingxiankong.github.io/blog/2014/03/25/metadata/