[ILUG] Curious ssh bastion host problem

[Lance Dryden]

Ar 04.06.12 23:56, scríobh Niall O Broin:
> I have a curious problem with using a bastion host for ssh. I have a target machine TARGET and three bastion hosts, H1, H2, H3 each of which is running the same kernel and netcat version. I have a user USER set up on each of H1-3 with an ssh public key installed, and USER is also set up on TARGET with the same public key. The corresponding private key is loaded into my agent.
> 
> From my machine, I can do the following on H1-3
> 
> ssh USER at Hn
> 
> ssh USER at Hn "ssh TARGET hostname"
> 
> ssh USER at Hn 
> 	followed by
> ssh TARGET (executed on Hn)
> 
> None of this is too surprising, really - all fairly standard uses of ssh. What IS surprising though is that I'd like to automate this in the normal way with netcat with a stanza like
> 
> Host                    TARGET
>         User            USER
>         ProxyCommand    ssh -q Hn nc -q0 TARGET 22
> 
> which works perfectly well for H1 and H2 but fails for H3, with
> 
> ssh_exchange_identification: Connection closed by remote host
> 
> which is indicative of the connection being refused by tcp-wrappers, which is somewhat understandable because it is in use - except that there are appropriate allow lines in place for H1-3, as evidenced by the above. So the question is, why can't I reach TARGET via H3 using ProxyCommand with netcat, when I can reach it via H3 otherwise?

I've some guesses but no answers with the available information.

On H3, turn up a secondary, debug sshd on a highport, and shell in from
one of the clients that doesn't work, into the highport sshd, and see if
the debug from the highport provides any insight.

(And if you're using tcp wrappers, don't forget to adjust for this
before testing.)

-- Lance