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/