vagrant-digitalocean
vagrant-digitalocean copied to clipboard
devopsgroup-io
SSH key allready exists gettig error
Hi, My SSH public key was allrady added on my digital ocean account. I got following error
agrant up --provider=digital_ocean
Bringing machine 'default' up with 'digital_ocean' provider...
==> default: Creating new SSH key: Vagrant...
There was an issue with the request made to the Digital Ocean
API at:
Path: /v2/account/keys
URI Params: {:name=>"Vagrant", :public_key=>"ssh-rsa XXXXXXXXXXXXXXXXXXXXXXXXXXXXX"}
The response status from the API was:
Status: 422
Response: {"id"=>"unprocessable_entity", "message"=>"Ssh key SSH Key is already in use on your account"}
Same. I hope the solution isn't to manually delete all existing ssh keys.
P.S. Manually deleting your keys via the web is a workaround (vagrant will just put the same key back in and then save the id).
Once I manually deleted the key I didn't have any further trouble. Vagrant seemed to add it and delete it correctly from there. I just couldn't manually add it before Vagrant.
+1
I was experiencing the same problem. The fix was to use the same name that was registered on Digital Ocean for the specified key.
provider.ssh_key_name = 'Same key name as in DO'
+1. I believe that it is right that the error is issued. Perhaps, the message displayed in the terminal should include a suggestion. What @leonfs wrote in the previous comment is accurate.
+1
As this is set to 'more information needed', here's my requirements:
Go to https://cloud.digitalocean.com/settings/security
This will list all the SSH keys DO has saved. When using Do to 'Create Droplet' these keys can be used to automatically put 1 or more keys on the new instance.
We work in a team and this is really handy to have the whole Dev team automatically set-up to connect to a new instance over SSH key pairs.
With this vagrant-digitalocean plugin:
Using an already existing 'private_key_path' on vagrant up errors with:
The response status from the API was:
Status: 422
Response: {"id"=>"unprocessable_entity", "message"=>"SSH Key is already in use on your account"}
The only way way I have found to avoid this is to delete the key on DO and recreate it every time a new instance is provisioned.
That's dumb!
In addition it would be good if more than 1 key can be copied to the instance, even better, keys that already exist on DO. Eg.
provider.ssh_key_name = ["Team Member A Key, "Team Member B Key", "Team Member C Key", "Team Member D Key"]
The solution is to make sure the key names match:
provider.ssh_key_name = "KEY_NAME_IN_VAGRANT"
See #223 for details.
@designorant Match what? If you use a name that matches a key name already in DO, that's when the error occurs. DO complains the key has already been used.
@elliotlewis Unless you're confusing the key itself: override.ssh.private_key_path with its name: provider.ssh_key_name, I'm of no help, I'm afraid. Matching provider.ssh_key_name with DigitalOcean's SSH Key Name certainly did the trick for me (and for a few others, as I've just learned).
in my case i fix changing the ssh key name on digitalocean site:
I put the name that appears in error and its work. URI Params: {:name=>"Vagrant", :public_key=>"ssh-rsa ...
I keep running into the same issue. I've tried and double-checked check every solution documented. What's very odd is that this started happening suddenly, it was all working fine until it wasn't. I've rolled back code, changed keys, add new keys... i don't know what to do anymore
Update: I added a new key and specified it in the provider.ssh_key_name = 'My New Key Name' and it started working. I also deleted the .vagrant directory just in case and started vagrant with vagrant up provider=digital_ocean
I also received the same error and adding a new SSH key and only using the provider.ssh_key_name did not resolve the issue - when I only provide the key name I receive an error that the SSH private key path is required, but of course when I provide the private key path... it tries to make a new key. So I can use Vagrant to setup the new droplet with a key, but I have to delete the key out of DigitalOcean every time so that it's always a "new" key. :-|
It looks to me that the solution to this issue is to add the test:
if provider.ssh_key_name is not set then
if key ssh.private_key_path is on DO account (/v2/account/keys/$KEY_FINGERPRINT)
use it on the droplet
else
add the pub key from ssh.private_key_path to the DO account
end
end
Sorry, I'm not a ruby guy, otherwise I'd make a pull request myself.
Btw, I've tested PR #267 and it worked well for that specific problem that is a bit related to this one.
