Skip to content
This repository has been archived by the owner on Jun 10, 2018. It is now read-only.

Doesn't support keyfile as set in ssh_options #22

Open
dafstone opened this issue Jun 27, 2016 · 1 comment
Open

Doesn't support keyfile as set in ssh_options #22

dafstone opened this issue Jun 27, 2016 · 1 comment

Comments

@dafstone
Copy link

So I just converted a repository that I use capistrano-rails-console on from a staging to production situation. As part of this we're using a hard linked ssh key, as opposed to inheriting one from the ssh-agent/user keys.

We just spent a couple of hours trying to figure out what was going on, but basically the gem is not accepting whatever is set under:

ssh_options, {..., keys: <code to produce keypath here>, ...}

What actually seems to be happening is that if the local capistrano users keychain can't get into a system (such as in our test) it tries to use this setting, but for some reason only trys to send whatever is the first character of the path as a key. So if you have:

keys: File.expand_path('~')<<"/.ssh/my_special_key"

Returns: Load key "/": Is a directory

But if you send: keys: 'config/my_special_key then you get:

Warning: Identity file c not accessible: No such file or directory.

And if you send keys: './config/my_special_key

You get: Load key ".": bad permissions

In the first example it's reading the "/" in the Dir.file_expand and trying to use it as the key. In the second it's reading the 'c' in the string, where the line begins 'config' and in the third it's reading the first '.' in the string as the argument and calling bad permissions on it....

Very confusing. I took a look at the code for the gem but it seems that in version 1.0.2 a lot of the code was reworked, and I'm thinking perhaps the author has some insight as to what's happening here.

I have to say this is also pretty mysterious, because if you're using a config/deploy/.rb configuration that's also your users ssh key, it appears as if it's using the config to work... but it's not.

Hope this makes sense - truly baffling, any ideas?

@ydkn
Copy link
Owner

ydkn commented Sep 16, 2016

I guess it is a problem in conjunction with the used sshkit version. And it really sound very weird and confusing.
I was planning to extract the interactive part of the gem to a more generic gem that can be used for all kinds of things. That's why the code from master was very different from the released version.

Can you please try again using the latest version (2.0.0) and use the latest revision of sshkit-interactive which is now used for the ssh connection:

gem 'sshkit-interactive', git: 'https://github.com/afeld/sshkit-interactive.git'

I tested it by renaming my default key according to your example and it worked

set :ssh_options, { keys: [File.expand_path('~')<<"/.ssh/my_special_key"] }

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants