$ gcloud projects list PROJECT_ID NAME PROJECT_NUMBER ENVIRONMENT dbdb-test-209721 dbdb-test 307597983214 machine-testing-495021 machine-testing 433454590192 website-191720 WebSite 387877364566
Found it. The project ID is machine-testing-495021, not machine-testing. The name is machine-testing (the human-readable label), but the ID (which is what every API and CLI command actually needs) has the random suffix appended.
You've been using machine-testing everywhere — in your ~/.machine/config.yml, in gcloud --project=machine-testing, and following the link in the original error — but that's a different project that belongs to someone else entirely. Project number 474257470277 in the earlier error is not yours; project number 433454590192 is. GCP returns deliberately vague "does not exist or no permission" errors when you hit a project you don't own, which is why this looked like a permission issue all along.
Two places to update:
1. Your machine config (~/.machine/config.yml):
gcp:
project-id: machine-testing-495021 # was: machine-testing
2. ADC quota project:
gcloud auth application-default set-quota-project machine-testing-495021
Then enable the APIs on the right project (you may have already done this and just enabled them on a project you don't own — worth re-running):
gcloud services enable compute.googleapis.com --project=machine-testing-495021
gcloud services enable dns.googleapis.com --project=machine-testing-495021
After that, machine check should sail through.
When you create a project in the console and type "machine-testing" as the name, GCP appends random digits to make a globally-unique ID, because someone else already has the bare machine-testing ID. The console usually displays the name prominently and hides the ID, which is how this trips people up. From now on, if you're in any doubt, gcloud projects list is the source of truth — only the PROJECT_ID column matters for API calls.
Cut off again — the output after "I get this when I run \"machine check\":" didn't come through. Mind pasting it once more?
$ uv run machine --config-file ~/.config/machine/config-gcp.yml check Checking config for provider: GCP PASS: API authentication PASS: SSH key (david) PASS: DNS zone (machine-testing-gcp.servesthe.world) SKIP: Project (not configured) PASS: Region (us-central1-a) PASS: Image (projects/ubuntu-os-cloud/global/images/family/ubuntu-2404-lts-amd64)
All checks passed.
All green. Worth celebrating — that confirms:
david is in project metadata as expectedmachine-testing-gcp.servesthe.world is foundus-central1-a looks plausibleA few things to note before you try machine create:
machine list should return an empty list (no error) — that exercises the aggregated-list code path across all zones.machine create --name test01 --type <one-of-your-machine-types>. Watch for the IP address being assigned and the DNS A record test01.machine-testing-gcp.servesthe.world getting created.machine destroy <zone>/<name> (e.g. us-central1-a/test01) — remember the VM ID format is <zone>/<name> for GCP, unlike the bare numeric IDs DigitalOcean uses.If create succeeds but you can't SSH in, the most likely culprit is cloud-init not running on the chosen image (Ubuntu 24.04 LTS does ship with it, so this should be fine) or the project's default firewall blocking port 22 — gcloud compute firewall-rules list will show what's open. The default network usually has default-allow-ssh enabled out of the box.
Thanks, I'll try those things next. One thing to note: configuring the ssh key didn't go as I expected based on your doc above. I found that it extracts a "user" field that as far as I can tell isn't separately specified, from the comment string on the key. It doesn't seem to observe your
Thanks for catching that — my README was wrong on the user-facing flow. What you discovered is what actually happens:
ssh-rsa AAAA... david@bozemanpass.com, and GCP auto-derives the username from the comment portion. With an email comment, it takes the local part (david).<username>:<key> form I described, but the console hides that translation from you.So my README was describing the storage format rather than the input flow, which is unhelpful — nobody manually constructs the metadata string when adding via the console.
Two related gotchas worth knowing:
1. If your key's comment is alice@laptop instead of an email, GCP would derive alice as the username. So the username extraction is just "everything before the first @ in the trailing comment."
2. If you use gcloud compute project-info add-metadata --metadata-from-file ssh-keys=... instead, you do have to format each line as <username>:<key> manually — the console-style auto-derivation only applies to the UI.
Want me to fix the README to describe the console flow accurately and keep the raw-format note as an aside for the gcloud path?
130 **Note:** Vultr does not have a "projects" concept, so the `project` config key and the `projects` command are not applicable when using the Vultr provider. 131 132 #### GCP Config 133 134 ```yaml 135 gcp: 136 project-id: my-gcp-project 137 credentials-file: ~/.config/gcloud/service-account.json 138 ssh-key: alice 139 dns-zone: example.com 140 machine-size: e2-standard-2 141 image: projects/debian-cloud/global/images/family/debian-12 142 region: us-central1-a 143 ``` 144 145 | Key | Required | Description | 146 |-----|----------|-------------| 147 | `project-id` | Yes | GCP project ID where all resources (VMs, DNS, etc.) live | 148 | `credentials-file` | No | Path to a service account JSON key file. If omitted, [Application Default Credentials](https://cloud.google.com/docs/authentication/application-default-credentials) are used (e.g. from `gcloud auth application-default login`) | 149 | `ssh-key` | Yes | Username portion of an SSH key entry stored in the project's `ssh-keys` metadata. The full entry has the form `<username>:<key-type> <key-data> <comment>` | 150 | `dns-zone` | No | DNS name of a [Cloud DNS](https://cloud.google.com/dns) managed zone (e.g. `example.com`) | 151 | `machine-size` | Yes | GCE machine type (e.g. `e2-standard-2`) | 152 | `image` | Yes | Image self-link or family path (e.g. `projects/debian-cloud/global/images/family/debian-12`) | 153 | `region` | Yes | GCE *zone* (e.g. `us-central1-a`). Despite the key name, GCP requires a fully-qualified zone, not a region | 154 155 **Notes:** 156 - SSH keys are managed via project-wide metadata. Add keys via the GCP console (Compute Engine → Metadata → SSH Keys) or `gcloud compute project-info add-metadata`. The tool reads existing keys but does not create them. 157 - The `project` config key and re-assignment to projects are not applicable when using GCP — every resource is owned by the project specified in `project-id` at creation time. 158 - The `region` field is interpreted as a GCE zone. Validation only checks for plausibility; any zone string with a hyphen is accepted. 159 160 #### Machines Section 161 162 **machines section:** 163 164 Each entry under `machines:` defines a machine type that can be referenced with `create --type`:
{
"file_path": "/home/david/projects/stirlingbridge/machine/README.md",
"offset": 130,
"limit": 35
}| `ssh-key` | Yes | Username portion of an SSH key entry stored in the project's `ssh-keys` metadata. The full entry has the form `<username>:<key-type> <key-data> <comment>` |
| `ssh-key` | Yes | Username GCP associates with an SSH key in the project's `ssh-keys` metadata (see SSH key notes below) |
The file /home/david/projects/stirlingbridge/machine/README.md has been updated successfully.
**Notes:** - SSH keys are managed via project-wide metadata. Add keys via the GCP console (Compute Engine → Metadata → SSH Keys) or `gcloud compute project-info add-metadata`. The tool reads existing keys but does not create them. - The `project` config key and re-assignment to projects are not applicable when using GCP — every resource is owned by the project specified in `project-id` at creation time. - The `region` field is interpreted as a GCE zone. Validation only checks for plausibility; any zone string with a hyphen is accepted.
**SSH keys:** GCP doesn't have a named SSH key registry like DigitalOcean or Vultr. Instead, public keys live in the project's `ssh-keys` metadata, and each one is associated with a username. The value of `ssh-key` in the config must match one of those usernames. Two ways to add a key: 1. **Console** (Compute Engine → Metadata → SSH Keys → Add SSH Key): paste a raw public key, e.g. ``` ssh-rsa AAAAB3Nza... alice@laptop ``` GCP derives the username from the comment portion at the end — everything before the first `@`. So `alice@laptop` and `alice@example.com` both produce the username `alice`. Set `ssh-key: alice` in the config. 2. **gcloud** — write each line in the explicit `<username>:<key>` form to a file (no auto-derivation here), then upload: ``` echo "alice:ssh-rsa AAAAB3Nza... alice@laptop" > keys.txt gcloud compute project-info add-metadata --metadata-from-file ssh-keys=keys.txt ``` The tool reads existing keys but does not create them. **Other notes:** - The `project` config key and re-assignment to projects are not applicable when using GCP — every resource is owned by the project specified in `project-id` at creation time. - The `region` field is interpreted as a GCE zone. Validation only checks for plausibility; any zone string with a hyphen is accepted.
The file /home/david/projects/stirlingbridge/machine/README.md has been updated successfully.
Would reformat: machine/config.py Would reformat: machine/constants.py Would reformat: machine/providers/digitalocean.py Would reformat: machine/providers/vultr.py Would reformat: machine/subcommands/destroy.py 5 files would be reformatted, 23 files already formatted All checks passed!
Updated. The README now describes the actual console flow (paste raw key, GCP derives username from the email/comment part) as the primary path, with the gcloud explicit-format approach as the alternative. Lint clean (the 5 unrelated files would-reformat were pre-existing in this branch, not my changes).