Changing VM metadata

In the Yandex Cloud CLI, you can provide metadata in any of the three parameters:

• --metadata-from-file: As a configuration file in this format: --metadata-from-file key=<file_path>. Use this method to conveniently deliver a value consisting of several lines.

  For example, to add several users to a VM at the same time, describe the configuration in a YAML file:

  #cloud-config
  datasource:
    Ec2:
      strict_id: false
  ssh_pwauth: no
  users:
  - name: <username_1>
    sudo: 'ALL=(ALL) NOPASSWD:ALL'
    shell: /bin/bash
    ssh_authorized_keys:
    - <public_SSH_key_1>
  - name: <username_2>
    sudo: 'ALL=(ALL) NOPASSWD:ALL'
    shell: /bin/bash
    ssh_authorized_keys:
    - <public_SSH_key_2>
  ...
  - name: <username_n>
    sudo: 'ALL=(ALL) NOPASSWD:ALL'
    shell: /bin/bash
    ssh_authorized_keys:
    - <public_SSH_key_n>
  runcmd: []
  

• --metadata: As a comma-separated list of key=value pairs, e.g., --metadata foo1=bar,foo2=baz.

  For a multiline value, use \n as a separator: --metadata user-data="#ps1\nnet user Administrator Passw0rd".

• --ssh-key: SSH key. Only for Linux VMs.

  Compute Cloud creates the yc-user user and adds the specified SSH key to the list of authorized keys. After the VM is created, you can use this key to connect to it over SSH.

You can combine these parameters, for example:

yc compute instance update \
  --name my-instance \
  --metadata-from-file user-data=metadata.yaml \
  --metadata serial-port-enable=1
...

In Terraform, you can specify metadata in three ways:

• As a separate file with user metadata to process by the cloud-init agent. To do this, under metadata, specify the path to the file with user metadata, such as cloud-init.yaml:

  ...
  metadata = {
    user-data = "${file("cloud-init.yaml")}"
  }
  ...
  

  {% cut "Sample contents of the cloud-init.yaml" file %}

  #cloud-config
  datasource:
    Ec2:
      strict_id: false
  ssh_pwauth: no
  users:
  - name: <username_1>
    sudo: 'ALL=(ALL) NOPASSWD:ALL'
    shell: /bin/bash
    ssh_authorized_keys:
    - <public_SSH_key_1>
  - name: <username_2>
    sudo: 'ALL=(ALL) NOPASSWD:ALL'
    shell: /bin/bash
    ssh_authorized_keys:
    - <public_SSH_key_2>
  ...
  - name: <username_n>
    sudo: 'ALL=(ALL) NOPASSWD:ALL'
    shell: /bin/bash
    ssh_authorized_keys:
    - <public_SSH_key_n>
  runcmd: []
  

• Under metadata, as a line with user metadata. For a multiline value, use \n as a separator. For example:

  ...
  metadata = {
    user-data = "#cloud-config\nusers:\n  - name: <username>\n    groups: sudo\n    shell: /bin/bash\n    sudo: 'ALL=(ALL) NOPASSWD:ALL'\n    ssh_authorized_keys:\n      - <SSH_key_contents>"
  }
  ...
  

• Only for Linux VMs. Under ssh-keys, specify the username and the SSH key to access Linux VMs. Enter your username and the contents of your SSH key as follows:

  ...
  metadata = {
    ssh-keys = "<username>:<SSH_key_contents>"
  }
  ...
  

  If you are using an out-of-the-box public image from Yandex Cloud Marketplace, the specified username does not matter. The key will be assigned to the user specified in the cloud-init configuration by default. Such users vary depending on an image.

  If you do not know the default user, find the string containing Authorized keys from in the serial port output. It will contain the name of the user the authorized keys are assigned to.

  If you cannot find this string but you see the no authorized ssh keys fingerprints found for user string, it means you have provided your SSH key incorrectly. Check the format once again or try providing the SSH keys in the user-datafield.

In the API, specify the metadata in the metadata property as a JSON object, e.g.:

"metadata": {
  "ssh-keys": "ssh-ed25519 AAAAB3Nza... user@example.com",
  "serial-port-enable": "1"
}

For a line break, use \n.

If you do not have the Yandex Cloud CLI yet, install and initialize it.

The folder specified when creating the CLI profile is used by default. To change the default folder, use the yc config set folder-id <folder_ID> command. You can specify a different folder using the --folder-name or --folder-id parameter.

1. See the description of the CLI command for removing metadata:

   yc compute instance remove-metadata --help
   

2. Remove the keys:

   yc compute instance remove-metadata <VM_ID> --keys <SSH_key_name>
   

To remove SSH keys from the VM metadata, use the updateMetadata REST API method for the Instance resource or the InstanceService/UpdateMetadata gRPC API call.

In your request, provide the delete parameter with the SSH key.

REST API request example

curl \
  --request POST \
  --header "Authorization: Bearer <IAM_token>" \
  --data '{"delete":["<SSH_key_name>"]}' \
  https://compute.api.cloud.yandex.net/compute/v1/instances/<VM_ID>/updateMetadata

If you do not have the Yandex Cloud CLI yet, install and initialize it.

The folder specified when creating the CLI profile is used by default. To change the default folder, use the yc config set folder-id <folder_ID> command. You can specify a different folder using the --folder-name or --folder-id parameter.

1. See the description of the CLI command for updating VM parameters:

   yc compute instance update --help
   

2. Get a list of VMs in the default folder:

   yc compute instance list
   

   Result:

   +----------------------+-----------------+---------------+---------+----------------------+
   |          ID          |       NAME      |    ZONE ID    | STATUS  |     DESCRIPTION      |
   +----------------------+-----------------+---------------+---------+----------------------+
   | fhm0b28lgfp4******** | first-instance  | ru-central1-a | RUNNING | my first vm via CLI  |
   | fhm9gk85nj7g******** | second-instance | ru-central1-a | RUNNING | my second vm via CLI |
   +----------------------+-----------------+---------------+---------+----------------------+
   

3. Select ID or NAME of the VM, e.g., first-instance.

4. Enable access via OS Login:

   yc compute instance update first-instance \
     --metadata enable-oslogin=true
   

Use the metadata field to provide enable-oslogin=true in the update REST API method for the Instance resource or in the InstanceService/Update gRPC API call.