在 linux 中使用 Set-AzureRmVMOSDisk 并附加时无法登录到新创建的 ARM VM
Unable to log in to the newly created ARM VM when using Set-AzureRmVMOSDisk with linux and attach
我正在尝试为我正常工作的 ARM VM 运行 Ubuntu 开发一个克隆工作流。
此 VM 是从 Marketplace 中的 Bitnami LAMP 映像创建的。
我正在尝试使用 -CreateOption attach 选项而不是 fromImage，据我所知它应该可以工作...我是知道还有另一个选项：deprovision->capture->-CreateOption fromImage，但也有问题，请参阅 Creating new ARM VM from captured image: Blob name in URL must end with '.vhd' extension error 我遵循的工作流程是根据许多描述进行的，我不明白这个登录问题，希望我错过了一个简单的步骤...
我已经用不同的 源 ARM 虚拟机尝试了两次此工作流，得到了完全相同的结果：新机器看起来 完全 可操作，但我无法使用已知的用户名密码登录到新机器（通过 SSH）。
诊断：
- 甚至网络服务器和mysql在新机器上都能正常工作，因为在新机器启动后我可以查看它所服务的网站。
- 在下面的脚本中，我省略了入站规则的配置，但我成功地允许了 HTTP（见上文）和 SSH。 SSH 连接询问密码并将其评估为错误。
这是我所做的：
- 停止了功能齐全的 ARM VM（没有 waagent -deprovision 运行）
- 已将 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
我看了一下，似乎是 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 对我正在使用的密码具有正确的 salt/hash。具有更多 Linux / bitnami 经验的人可能能够查明其中的错误所在。不过初刷应该是可以的...
这在普通 ubuntu 图像上确实可以正常工作，因此从头开始构建新机器可能更简单。
否则，您可能会在 bitnami 论坛上获得更好的答案。 （它很可能只是一个配置设置）
我在尝试捕获->从图像创建 (CCFI) 时意外地得到了一些诊断结果（不要与复制->附加 (CA) 混淆，这个问题是关于什么的）
如果你不关心细节直接跳到最后看"Currently known simplest workaround"
诊断：
如果新创建的市场 bitnami LAMP ARM VM 遭受 CA 则原始管理员用户 无法 登录
如果新创建的市场 bitnami LAMP ARM VM 遭受 CCFI，则原始管理员用户 可以 登录，并且新定义的凭据 ( admin2) 也可以登录。
如果通过 CCFI 创建的 VM 遭受 CA，则原始管理员用户 可以 登录，但 admin2 （在之前的CCFI中创建）无法登录
在这个实验之后，我能够用原来的管理员用户登录到一台 CA-d 机器，这台机器以前是 CCFI-d。
检查 /etc/shadow 发现 admin2 被禁用：(!sign) 在密码哈希之前。唯一的问题仍然是，哪个聪明人做了这件显然不受欢迎和意外的事情。我们有两个嫌疑人和三个场景：
- 一些 bitnami 自定义脚本
- waagent
- waagent 被某些 bitnami 自定义操作或错误配置误导
虽然我不确定但是我猜是"pure waagent"，第二个是"waagent misleaded..."
原因如下：
我检查了 /var/lib/waagent/ovf-env.xml 文件，发现有一个
<ns1:UserPassword>REDACTED</ns1:UserPassword>
最后一个配置用户的条目。这是针对 "admin" 的处女市场机器，以及 admin2 的 CCFI-d 机器。当一台机器受到 CA 的影响时，该用户将被禁用。由于此文件属于 waagent，我猜测 waagent 以某种方式检测到 CA（为什么？？？）操作并首先启动禁用用户。诊断与该理论完全一致。
有一件事是肯定的：这个问题是一个不需要的自动化，它发生在 VM 本身和 bitnami 特定的或者 Linux 特定的。
这个问题总是发生 during/after 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登录。
我正在尝试为我正常工作的 ARM VM 运行 Ubuntu 开发一个克隆工作流。 此 VM 是从 Marketplace 中的 Bitnami LAMP 映像创建的。
我正在尝试使用 -CreateOption attach 选项而不是 fromImage，据我所知它应该可以工作...我是知道还有另一个选项：deprovision->capture->-CreateOption fromImage，但也有问题，请参阅 Creating new ARM VM from captured image: Blob name in URL must end with '.vhd' extension error 我遵循的工作流程是根据许多描述进行的，我不明白这个登录问题，希望我错过了一个简单的步骤...
我已经用不同的 源 ARM 虚拟机尝试了两次此工作流，得到了完全相同的结果：新机器看起来 完全 可操作，但我无法使用已知的用户名密码登录到新机器（通过 SSH）。
诊断：
- 甚至网络服务器和mysql在新机器上都能正常工作，因为在新机器启动后我可以查看它所服务的网站。
- 在下面的脚本中，我省略了入站规则的配置，但我成功地允许了 HTTP（见上文）和 SSH。 SSH 连接询问密码并将其评估为错误。
这是我所做的：
- 停止了功能齐全的 ARM VM（没有 waagent -deprovision 运行）
- 已将 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
我看了一下，似乎是 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 对我正在使用的密码具有正确的 salt/hash。具有更多 Linux / bitnami 经验的人可能能够查明其中的错误所在。不过初刷应该是可以的...
这在普通 ubuntu 图像上确实可以正常工作，因此从头开始构建新机器可能更简单。
否则，您可能会在 bitnami 论坛上获得更好的答案。 （它很可能只是一个配置设置）
我在尝试捕获->从图像创建 (CCFI) 时意外地得到了一些诊断结果（不要与复制->附加 (CA) 混淆，这个问题是关于什么的）
如果你不关心细节直接跳到最后看"Currently known simplest workaround"
诊断：
如果新创建的市场 bitnami LAMP ARM VM 遭受 CA 则原始管理员用户 无法 登录
如果新创建的市场 bitnami LAMP ARM VM 遭受 CCFI，则原始管理员用户 可以 登录，并且新定义的凭据 ( admin2) 也可以登录。
如果通过 CCFI 创建的 VM 遭受 CA，则原始管理员用户 可以 登录，但 admin2 （在之前的CCFI中创建）无法登录
在这个实验之后，我能够用原来的管理员用户登录到一台 CA-d 机器，这台机器以前是 CCFI-d。
检查 /etc/shadow 发现 admin2 被禁用：(!sign) 在密码哈希之前。唯一的问题仍然是，哪个聪明人做了这件显然不受欢迎和意外的事情。我们有两个嫌疑人和三个场景：
- 一些 bitnami 自定义脚本
- waagent
- waagent 被某些 bitnami 自定义操作或错误配置误导
虽然我不确定但是我猜是"pure waagent"，第二个是"waagent misleaded..."
原因如下： 我检查了 /var/lib/waagent/ovf-env.xml 文件，发现有一个
<ns1:UserPassword>REDACTED</ns1:UserPassword>
最后一个配置用户的条目。这是针对 "admin" 的处女市场机器，以及 admin2 的 CCFI-d 机器。当一台机器受到 CA 的影响时，该用户将被禁用。由于此文件属于 waagent，我猜测 waagent 以某种方式检测到 CA（为什么？？？）操作并首先启动禁用用户。诊断与该理论完全一致。
有一件事是肯定的：这个问题是一个不需要的自动化，它发生在 VM 本身和 bitnami 特定的或者 Linux 特定的。
这个问题总是发生 during/after 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登录。