Not creating droplet with default ssh key

[zuriar]

Hi

USING tugboat version 0.2.0

tugboat keys ->

SSH Keys:
my-key-name (id: _123_)

~/.tugboat ->

---

authentication:
client_key: *******
api_key: ********
ssh:
ssh_user: root
ssh_key_path: /home/******/.ssh/id_rsa
ssh_port: '22'

defaults:
region: '7'
image: '9801950'
size: '62'
ssh_key: 'my-key-name'
private_networking: 'false'
backups_enabled: 'false'

tugboat create foo ->

returns a new droplet but has not copied 'my-key-name' into ~/.ssh/authorized_keys which means when I run

tugboat ssh foo -> (expecting > ssh root@)

It still asks me for password.

Basically, DigitalOcean account has the SSH key set up but Tugboat is not correctly installing it into new droplets. Am I missing something?

thanks
Hugh

[zuriar]

OK, my bad. It turns out that you need to use the ssh_key ID number, not the name.

If you add your local machine public key using 'tugboat add-key' the call to Digital Ocean API will return the new ssh_key ID number and tugboat will update the ~/.tugboat config accordingly. If you have already uploaded an ssh_key to digital ocean (using the web interface) then you can find out the ID number by running 'tugboat keys'

(FYI - this kinda breaks the convention of using like-for-like in API designs. Droplets have IDs as well as names, as do ssh_keys however all tugboat commands dealing with droplets uses the name but ssh_keys uses the ID.... worth considering as I assumed the same API design through out....)

[petems]

Yeah, the 1.0 API had a few inconsistencies, but this has caused some issues, we should clarify (see #136)

[petems]

Clarified in #157