You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Jun 10, 2018. It is now read-only.
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:
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?
The text was updated successfully, but these errors were encountered:
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:
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?
The text was updated successfully, but these errors were encountered: