>>>>> "Noah" == Noah writes:

Noah> Hi there, I'm using OpenSSH_3.8.1p1 to setup a chain of tunnels
Noah> through a firewall machine to a dbserver. (I'm trying to make my
Noah> local machine appear as if it were running dbserver).

Noah> Originally I tried this: ssh -N -f -L
Noah> 5432:dbserver.example.com:5432 noah@firewall.example.com This
Noah> did setup a valid tunnel for port 5432. The problem is that
Noah> postgres running on dbserver has host-based authentication
Noah> configured to only accept connections from itself (localhost on
Noah> dbserver). I would get an error that my host (firewall) was not
Noah> authorized to connection to the database. Fair enough. This
Noah> isn't an SSH problem.

Noah> So I figured I could have dbserver loop back to itself so that
Noah> Postgres would see the incoming connections coming from itself
Noah> (locahost on dbserver). I thought I could forward something
Noah> like this: localhost:5432 --> 9999:firewall --> 9999:dbserver
Noah> --> dbserver:5432

Noah> So I tried to create a chain of port forwarded tunnels like
Noah> this: ssh -L 5432:firewall.example.com:9999
Noah> noah@firewall.example.com ssh -f -N -L
Noah> 9999:dbserver.example.com:5432 noah@dbserver.example.com

Noah> The first ssh asks me for my password, but the second ssh never
Noah> asks me for my password and instead gives me an error:
Noah> Permission denied (publickey,password,keyboard-interactive).

The problem is that the second ssh instance does not have a tty, so it
can't prompt for your password. You can fix this with -t on the first ssh
instance.

Noah> Normally I can ssh from firewall to dbserver with a password.
Noah> Note that I'm not allowed use a public key due to a policy
Noah> against private keys on the firewall.

Only your public key needs to be on the firewall; this policy is
misguided.

Noah> That's where things started to fall apart and I got confused
Noah> with the SSH syntax. I'm not even sure if that would have setup
Noah> the double-hop SSH tunnel as I expected. I didn't get that far,
Noah> so I may be on the wrong path anyway.

What you're doing will work, but it's fragile in various respects. I
would remove the -f from the second ssh; it will fork and then not
terminate when the first one does, preventing you from running the same
command again (since that port is now bound).

When you have to go through multiple hops, it's usually better to get an
end-to-end connection. In this case:

ssh -oproxycommand="ssh -qaxT firewall nc %h %p" -L 5432:localhost:5432 dbserver

If you have a copy of the snail book, section 11.4 (p444) has a discussion
of these two approaches.

The annoyance with the second approach is that it requires having netcat
("nc") or something equivalent on the intermediate host. I hope that
someday OpenSSH will have this feature built in, i.e. connecting an exec
channel to a remote TCP connection.

--
Richard Silverman
res@qoxp.net

I got this to work pretty well:

ssh -t -L 5432:127.0.0.1:9991 firewall.example.com \
ssh -t dbserver \
ssh -t -R 9991:127.0.0.1:5432 firewall

Note that I was not able to use -f because the first SSH would
fork before the last SSH asked me for my password.
I found that I had to use -t on all three ssh commands.
It did not seem to work otherwise.
Is there anything I can clean up?

So using this I am able to use psql on my localhost machine
to connect to dbserver (although, I have to tell to use 127.0.0.1
as the host so it would make an IP connection instead of
trying to use a local pipe, "psql -h 127.0.0.1 my_database").
The Postgres server on dbserver allows the
connection without a password because
host based authentication sees that the connection
originates from dbserver's localhost.

Richard E. Silverman wrote:
> >>>>> "Noah" == Noah writes:
> The problem is that the second ssh instance does not have a tty, so it
> can't prompt for your password. You can fix this with -t on the first ssh
> instance.

Yes, the -t was the trick. Thanks.

> What you're doing will work, but it's fragile in various respects. I
> would remove the -f from the second ssh; it will fork and then not
> terminate when the first one does, preventing you from running the same
> command again (since that port is now bound).
>
> When you have to go through multiple hops, it's usually better to get an
> end-to-end connection. In this case:
>
> ssh -oproxycommand="ssh -qaxT firewall nc %h %p" -L 5432:localhost:5432 dbserver
>
> If you have a copy of the snail book, section 11.4 (p444) has a discussion
> of these two approaches.

I will check this out. Thanks!

Yours,
Noah