Additional SSH options for gateway?

[Kali]

Hi all,

I'm working with a client where I have access to a gateway server, and
from there I can SSH into the two app servers. My problem is that I
have one SSH username and public key to access the gateway server, and
once there a second set (different username/key) is required to access
the app servers.

Setting the :gateway option connects to the gateway host perfectly,
but the subsequent connections to the app servers are using the same
SSH options capistrano used to connect to the gateway. Is there a way
to set a different gateway user and gateway ssh options?

Thanks!
-Kali

[Jamis Buck]

You can specify a user specifically for the gateway in the hostname:

set :gateway, "us...@gateway.com"

Alas, though, you can't set any other options that way...but note that
you can specify a list of keys to try when logging in:

ssh_options[:keys] = %w(/path/to/first/key /path/to/next/key ...)

All keys will be tried for all hosts. I've never needed this specific
feature, but it _should_ work. :)

- Jamis

> --~--~---------~--~----~------------~-------~--~----~
> To unsubscribe from this group, send email to capistrano-...@googlegroups.com
> For more options, visit this group at http://groups.google.com/group/capistrano
> -~----------~----~----~----~------~----~------~--~---
>

[David Masover]

If that doesn't work, note that if ssh_options[:keys] is unset, Capistrano will check for a running ssh-agent. If one is running, all of its keys will be tried.

I'm fairly sure that there's no security risk involved in trying every key on every host.

[Kali]

Wow, thanks so much for the quick responses!

The first part (set :gateway, "us...@gateway.com") works great.
Unfortunately, even after changing my ssh options to

ssh_options[:keys] = %w(/path/to/local/key /path/to/key/on/remote)

I'm still prompted for a password. Is there any way to force using SSH
keys? I've verified manually that the path to the remote key is
correct, so I'm a little stumped.

Thanks!
-Kali

$ cap --version
Capistrano v2.2.0
$ cap tail_logs
* executing `tail_logs'
* executing "tail -f /path/to/logs/production.log"
servers: ["web01", "web02"]
* establishing connection to gateway `us...@gateway.com'
starting connection to gateway `us...@gateway.com'
gateway connection established
* establishing connection to `web01' via gateway
* establishing connection to `web02' via gateway
Password:

On Apr 11, 2:08 pm, Jamis Buck <ja...@37signals.com> wrote:
> You can specify a user specifically for the gateway in the hostname:
>

> set :gateway, "u...@gateway.com"

>
> Alas, though, you can't set any other options that way...but note that
> you can specify a list of keys to try when logging in:
>
> ssh_options[:keys] = %w(/path/to/first/key /path/to/next/key ...)
>
> All keys will be tried for all hosts. I've never needed this specific
> feature, but it _should_ work. :)
>
> - Jamis
>
> On Apr 11, 2008, at 2:59 PM, Kali wrote:
>
>
>
> > Hi all,
>
> > I'm working with a client where I have access to a gateway server, and
> > from there I can SSH into the two app servers. My problem is that I
> > have one SSH username and public key to access the gateway server, and
> > once there a second set (different username/key) is required to access
> > the app servers.
>
> > Setting the :gateway option connects to the gateway host perfectly,
> > but the subsequent connections to the app servers are using the same
> > SSH options capistrano used to connect to the gateway. Is there a way
> > to set a different gateway user and gateway ssh options?
>
> > Thanks!
> > -Kali
> > >
>
>

> smime.p7s
> 3KDownload

[David Masover]

Unless I'm misunderstanding, Capistrano would be expecting all keys to be local. That would be:

ssh_options[:keys] = %w(/path/to/key/for/gateway /path/to/key/for/thing/beyond/gateway)

Both of which would be on the local host.

Personally, I tend to have one key per client I deploy from, and just copy those keys to all machines we deploy to. It's easier for users to just keep track of their own key, instead of three or four, and it's also easier to revoke access to any machine a user doesn't need to be on (or has been abusing).