将Set-AzureRmVMOSDisk与linux和attach一起使用时，无法登录到新创建的ARM VM

Question

我正在尝试为运行Ubuntu的正常工作的ARM虚拟机开发一个克隆工作流。此VM是从市场上的Bitnami LAMP图像创建的。

我正在尝试使用-CreateOption attach选项而不是fromImage，据我所知，它应该可以工作。。。我知道还有另一种选择：取消提供-

我用不同的源ARM VM尝试了两次此工作流，得到了非常相同的结果：新机器似乎完全可以运行，但我无法使用已知的用户名密码登录到新机器（通过SSH）。

诊断：

• 甚至web服务器和mysql也能在新机器中正常工作，因为在新机器启动后，我可以查看它所服务的网站

这是我所做的：

• 已停止功能齐全的ARM VM（未运行waagent-取消提供）
• 已将OS vhd复制到新的。vhd blob（成功，复制脚本超出主题）
• 然后完全成功地运行以下脚本：

.

Login-AzureRmAccount
Select-AzureRmSubscription -SubscriptionName "Visual Studio Premium with MSDN"

# Create VM from an existing image

$location = "westeurope"
$vmSize = "Standard_DS2"

#Existing resource name parameters:
$rgName = "rg-wp"
$vnetName= "vn-wp" 
$stName = "mystorage"
#This vhd is a copy of a completely working ARM OS vhd: 
$vhdUri = "https://mystorage.blob.core.windows.net/vhds/disk-wp-01.vhd"

#Newly creatable resource names and other parameters
$vmName = "vm-wp-02"
$nicName="ni-wp-02"
$pipName="pip-wp-02"
$nsgName="nsg-wp-02"
$vhdName = "disk-wp-02"

$vnet = Get-AzureRmVirtualNetwork -Name $vnetName -ResourceGroupName $rgName
$storageAccount = Get-AzureRmStorageAccount -AccountName $stName -ResourceGroupName $rgName 

$pip = New-AzureRmPublicIpAddress -Name $pipName -ResourceGroupName $rgName -Location $location -AllocationMethod Static -DomainNameLabel $pipName 
$nsg = New-AzureRmNetworkSecurityGroup -Name $nsgName -ResourceGroupName $rgName -Location $location
$nic = New-AzureRmNetworkInterface -Name $nicName -ResourceGroupName $rgName -Location $location -SubnetId $vnet.Subnets[0].Id -PublicIpAddressId $pip.Id -NetworkSecurityGroupId $nsg.Id

# Configure VM: 
$vm = New-AzureRmVMConfig -vmName $vmName -vmSize $vmSize
$vm = Add-AzureRmVMNetworkInterface -VM $vm -Id $nic.Id
$vm = Set-AzureRmVMOSDisk -VM $vm -Name $vhdName -VhdUri $vhdUri -Linux -CreateOption attach

New-AzureRmVM -ResourceGroupName $rgName -Location $location -VM $vm

Answer 1

在尝试捕获时意外地得到了一些诊断结果-

如果您不关心细节，只需跳到最后并查看“目前已知的最简单的解决方法”

诊断：

>

如果新创建的marketplace bitnami LAMP ARM VM遇到CA，则原始管理员用户无法再登录

如果新创建的marketplace bitnami LAMP ARM VM遇到CCFI，则原始管理员用户可以登录，并且新定义的凭据（admin2）也可以登录。

如果通过CCFI创建的VM遇到CA，则原始管理员用户可以登录，但admin2（在以前的CCFI中创建）无法登录

在这个实验之后，我能够登录到一台CA-d机器，这台机器以前是使用原始管理员用户的CCFI-d。

检查/etc/shadow后发现，admin2在密码哈希之前被禁用：（！sign）。唯一的问题是，到底是哪个smartie做了这件显然是不想要的、没有完成的事情。我们有两个嫌疑人和三个场景：

• 一些bitnami自定义脚本
• waagent公司
• waagent被某些bitnami自定义操作或错误配置误导

虽然我不确定，但我的猜测是“纯waagent”，第二个是“waagent误导…”

原因如下：我已经检查了/var/lib/waagent/ovf env。xml文件，并发现

<ns1:UserPassword>REDACTED</ns1:UserPassword>

最后配置的用户的条目。对于virgin marketplace机器，这是“admin”，对于CCFI-d机器，这是admin2。当机器遇到CA时，此用户将被禁用。由于该文件属于waagent，我猜waagent不知怎么检测到了CA（为什么？）操作和首次启动禁用用户。诊断结果与这一理论完全一致。

有一件事是肯定的：这个问题是一个不必要的自动现象，它发生在VM本身以及特定于bitnami的Linux特定的。

此问题总是在CA期间/之后发生。这显然是不需要的，因为CA与设置、取消设置、泛化、清除敏感信息等无关。

解决方法：

经过尝试和验证：CCFI，然后您可以根据需要多次CA CCFI-d VM。

目前已知的最简单的解决方法：

值得尝试从解决方案中消除CCFI，因为它的时间成本。（不是说原来的机器被泛化后不能再通过设计（Azure）启动了）

在任何机器上执行以下操作：

sudo adduser dummyadmin
sudo adduser dummyadmin sudo
edit the /var/lib/waagent/ovf-env.xml file and replace admin to dummyadmin

如果您在任何机器上执行此操作，包括创建然后定制的市场机器，那么您可以自由地CA它。当然，您不能使用Dummyadmin登录新机器，但您可以使用admin登录。

Answer 2

我仔细查看了一下，似乎bitnami中有什么东西阻止它登录。

我没有花太多时间去尝试找出所有东西是如何连接的，但那里肯定有代码来检查何时从映像部署了新的VM，因为这样做时它总是会重新生成sshd密钥。

所有预期的文件都是相同的（我在普通ubuntu框和bitnami框之间进行了区分）

它产生的误差是

Mar  8 20:09:19 lamp sshd[2511]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=13.69.83.238  user=ubuntu
Mar  8 20:09:21 lamp sshd[2511]: Failed password for ubuntu from 13.69.83.238 port 32991 ssh2

然而， /etc/shadow对我正在使用的密码有正确的盐/哈希值。有更多Linux/bitnami经验的人可能能够指出其中的错误。但是乍一看，它应该是有效的...

这与普通ubuntu映像上的预期完全一样，因此从头开始构建新机器可能更简单。

否则，你可能会在bitnami论坛上得到更好的答案。（很可能只是配置设置）