對Azure虛擬機器的一些操作可能會導致無法遠端連線，本文羅列了以下導致不能遠端連線的場景：

場景1

在配置檔案（/etc/sysconfig/network-scripts/ifcfg-eth0）中配置固定的IP地址或MAC地址：

DHCP_HOSTNAME=DanCentOS65
DEVICE=eth0
ONBOOT=yes
BOOTPROTO=static
IPADDR=10.0.0.36
NETMASK=255.255.255.224
GATEWAY=10.0.0.33
HWADDR=00:0C:29:13:5D:74
TYPE=Ethernet
USERCTL=no
PEERDNS=yes
IPV6INIT=no
 

修改後，在介面上關機後再開機，虛擬機器會無法ssh登陸。（針對固定IP的情況，如果配置檔案中寫入的IP與虛擬機器啟動後DHCP獲取到的IP恰巧一致，這種情況下可以連結，但是如果再次重啟的時候，DHCP獲取到的IP可能會變化，所以仍然存在風險）

注：本場景測試環境為CentOS 6.5, 如果您當前使用的非該版本, 請注意版本的差異性。  

場景2

錯誤地修改服務的配置檔案/etc/ssh/sshd_config（語法錯誤或者配置錯誤），導致sshd服務無法啟動失敗：

由於針對該檔案的修改方法多種多樣，所以這裡只舉例說明，例如我們在修改sshd配置檔案的時候，在某一行手誤多輸入了一個字母：

結果sshd服務就無法正常啟動了：

注：本場景測試環境為CentOS 6.5, 如果您當前使用的非該版本, 請注意版本的差異性。  

場景3

錯誤地配置了虛擬機器的防火牆（firewalld），iptables等等： 出於安全形度考慮，很多使用者會針對ssh的客戶端ip進行限制，或者配置其他安全策略，這種情況下，如果出現配置不當或者錯誤配置，會導致客戶端不能正常ssh連線。 關於iptables的使用說明，請閱讀這篇文章 關於firewalld的使用說明，請閱讀這篇文章  

場景4

同一個版本的Linux映像創建出來的虛擬機器的系統盤UUID相同，例如使用平臺映像建立兩臺CentOS6.5的虛擬機器，系統盤UUID都為8fc4d768-29cd-462c-a7ab-5bf4bcfa9fa2：

因此如果將虛擬機器的系統盤掛載到用相同平臺映像建立其他機器上作為資料盤，不要使用UUID掛載（可以使用device名稱來掛載），否則可能因為UUID相同導致掛載錯誤的系統盤引起啟動失敗，導致無法連線（如果這種情況發生，分離磁碟可能會將正常的系統盤分離下來）。

注：本場景測試環境為CentOS 6.5, 如果您當前使用的非該版本, 請注意版本的差異性。  

場景5

虛擬機器做軟raid後，使用device名稱掛載而非UUID掛載，重啟後軟raid的device名稱發生變化，導致無法正常掛載，虛擬機器啟動失敗從而無法正常ssh： 例如，在建立raid的時候，使用md0，md1，md2作為名稱進行建立（參考連結）：

mdadm --create /dev/md0 --level 0 --raid-devices 2 /dev/sdc1 /dev/sdd1

mdadm --create /dev/md1 --level 0 --raid-devices 2 /dev/sde1 /dev/sdf1

mdadm --create /dev/md2 --level 0 --raid-devices 2 /dev/md0 /dev/md1

建立完成後，如果虛擬機器重啟，device名稱會發生變化，從127開始向前遞減：

如果在fstab檔案中使用device名稱進行掛載，會導致重啟後，系統找不到/dev/md0，/dev/md1，/dev/md2，從而掛載失敗無法啟動。所以建議使用UUID進行掛載。

注：本場景測試環境為CentOS 6.5, 如果您當前使用的非該版本, 請注意版本的差異性。

立即訪問http://market.azure.cn