谷歌云 SSH 密钥 [英] Google Cloud SSH Keys

问题描述

我已经使用 Google Compute Engine 设置了我的新服务器.我在 Google Cloud 控制台 (sshKeys) 的元数据中添加了一个用户及其公钥.

I have set up my new server with Google Compute Engine. I added a user and their public key into the metadata in the Google Cloud console (sshKeys).

我试图替换元数据中的公钥，但现在旧的似乎是唯一能够通过 ssh 进入我的服务器的公钥(使用 PuTTY).新的好像没有更新.

I attempted to replace a public key in the metadata, but now the old one seems to be the only one able to ssh into my server (using PuTTY). The new one doesn't seem to be updated.

现在，即使我删除整个元数据或在 sshKeys 字段中输入乱码，它仍然可以工作！

Now, even if I remove the whole metadata or type gibberish text into the sshKeys field, it will still work!

会不会是将元数据推送到服务器需要一些时间(我之前的尝试是即时的)?

Could it be that it will require sometime for the metadata to be pushed to the server (my previous attempts were instantaneous)?

推荐答案

要了解 Google Compute Engine 如何管理 ssh 密钥，您必须了解 GCE 如何管理 metadata(因为，正如您所写的，它们在元数据存储中).

To understand how Google Compute Engine manages the ssh keys, you have to understand how GCE manages the metadata (since, as you wrote, they are in the metadata store).

更具体地说，项目和实例元数据之间的区别至关重要.引用文档(见前面的链接):

And more specifically, the difference between project and instance metadata is crucial. To quote the documentation (see previous links):

可以在项目和实例级别分配元数据.项目级元数据传播到项目内的所有虚拟机实例，而实例级元数据仅影响该实例.您可以设置项目和实例级元数据，但如果您为项目和实例元数据设置相同的键，Compute Engine 将使用实例元数据.

Metadata can be assigned at both the project and instance level. Project level metadata propagates to all virtual machine instances within the project, while instance level metadata only impacts that instance. You can set both project and instance level metadata but if you set the same key for both your project and instance metadata, Compute Engine will use the instance metadata.

虽然这看起来相当合乎逻辑和直截了当，但必须非常密切地注意所使用的术语:

While this seems rather logical and straightforward, one has to pay attention, very closely, to the used terms:

项目级元数据传播到项目内的所有虚拟机实例[...]

Project level metadata propagates to all virtual machine instances within the project [...]

和

您可以同时设置 [...]，但如果您为两者设置相同的键 [...]，Compute Engine 将使用实例元数据.

You can set both [...] but if you set the same key for both [...], Compute Engine will use the instance metadata.

如果您考虑这两个断言，则意味着两件事:

If you consider both assertions, it means two things:

1. 如果您在项目级别仅设置元数据，它将在您的实例中传播.
2. 如果您在实例级别设置元数据，它将优先于项目级别的元数据，并且不会传播任何内容.

1. If you set the metadata at the project level ONLY, it will propagate in your instances.
2. If you set the metadata at the instance level, it will take precedence over the project level ones, and nothing will be propagated.

因此，GCE 平台负责在实例中放置/删除您的 ssh 密钥(并在放置时创建相关用户，而只需从 ~user/.ssh/authorized_keys 文件时删除它们 - 这样您就不会丢失 ~user 的任何数据)仅当您不指定自己的密钥时(在实例创建时)或以后).如果这样做，GCE 平台会将 ssh 密钥管理视为手动，并且不会与元数据存储保持同步.

As a direct consequence of that, the GCE platform takes care of placing/removing your ssh keys in the instance (and creating the relevant users when placing them, while just removing the key from the ~user/.ssh/authorized_keys file when removing them - so you don't lose any data for ~user) ONLY when you do not specify your own keys (at instance creation or later). If you do, the GCE platform will consider the ssh key management as manual, and nothing will be kept in sync with the metadata store.

幸运的是，GCE 平台做得很好，因此，您无需重新创建实例来让 GCE 平台管理您的密钥:您只需要删除与 sshKeys<相关的实例级元数据/代码>.

Fortunately, the GCE platform is well done, and therefore, you need not re-creating an instance to get your keys managed by the GCE platform: you only need to remove the instance level metadata relative to the sshKeys.

同理，如果你添加一些带有sshKeys键的实例级元数据，会禁用ssh键GCE平台管理；除非您删除该实例级元数据.

The same way, if you add some instance level metadata with the key sshKeys, it will disable the ssh keys GCE platform management; unless you remove that instance level metadata.

关于延迟问题:到目前为止，除了网络延迟(因此没有明显的平台执行延迟)之外，我没有任何延迟.我不认为平台不时出现延迟是不可能的，但它似乎不太可能是您问题的原因.

Concerning the delay question: I didn't have any delay other than the network delay (so no platform execution delay noticeable) so far. I don't think it's impossible that the platform has delays from time to time, but it doesn't seem very likely to be the cause of your problem.

附加说明:

某些发行版(例如 ubuntu)包含特定用户(在 ubuntu 的情况下:~ubuntu)，项目中的每个用户都具有该用户-level ssh 键可以登录；但该用户的 authorized_keys 是在实例创建时生成的，并且似乎永远不会被 GCE 平台再次更改.恕我直言，应该首选自动 ssh 密钥管理.

Some distributions (such as ubuntu) include a specific user (in the case of ubuntu: ~ubuntu), with which every user existing in the project-level ssh keys can login; but that user's authorized_keys is generated at instance creation time, and never seems to be changed again by the GCE platform. IMHO, the automatic ssh key management should be preferred.

来源:个人对 GCE、terraform 和 Google Developer Console 的体验

这篇关于谷歌云 SSH 密钥的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！