Re: OpenBSD2.9 ssh to OpenBSD3.0 sshd - Secure connection to <ipaddress> refused.

From: fsh (
Date: 02/16/02

From: "fsh" <>
Date: Fri, 15 Feb 2002 21:53:15 -0600

Thanks for the help. It was the listening address (I made it the dns name
to fix)


"Richard E. Silverman" <> wrote in message
> >>>>> "fsh" == fsh <> writes:
> fsh> Actually, I think ssh is communicating but sending information
> fsh> that sshd can't understand, therefore sending a TCP reset.
> No; the packet trace you posted shows that this is not what's happening
> (and your suggestion indicates that you need to review how TCP works).
> The client sends a SYN to start the TCP handshake; the server sends an
> immediate RST -- this happens several times as the client retries before
> giving up. No connection is ever set up, no application data are
> exchanged, and the listening process (sshd) is completely unaware of these
> events. This is consistent with your report that there are no verbose
> messages from sshd during this test. If you want more direct
> confirmation, ktrace sshd while this is happening -- you will see that it
> does not get woken up from io sleep.
> fsh> I also stated that if I ssh from the localhost it works fine -
> fsh> indicating sshd is listening on port 22.
> I know, and I did not write anything inconsistent with that. The RST
> reply is, as a matter of protocol, an indication that the socket is
> closed. However, there are other reasons why this could happen besides
> that nothing is actually listening, and I suggested one: an intervening
> firewall sending masqueraded RST's. Also, you did not say exactly how you
> conducted your same-host test. "ssh localhost" and "ssh hostname" would,
> for example, test completely different listening sockets. And still, your
> sshd might not be listening on the right protocol -- OpenBSD supports both
> ipv4 and ipv6. Perhaps for some reason, sshd is only listening on the
> 4-in-6 socket, and your local test is using that one. Check with netstat
> -a or lsof to see if that's the case. You might try "ListenAddress
>" or "ListenAddress <real IP address>" and see if it makes a
> difference.
> --
> Richard Silverman