Question

我在我的应用程序中的一个特殊应用程序端口上调用:: connect（）并且它一般工作正常，但是，在两个特定的机器之间，从一个到另一个，它失败了EHOSTUNREACH，这意味着“没有到主机的路由” 。“

如果我可以在没有问题的情况下在端口22上进行ssh，那么这个特定的机器对的:: connect（）总是会失败吗？

以详细模式运行ssh会产生：

[localMachine ~] ssh -v -p 22 remoteMachine
OpenSSH_3.9p1, OpenSSL 0.9.7a Feb 19 2003
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to remoteMachine [10.34.49.107] port 22.
debug1: Connection established.
debug1: identity file /home/WilliamKF/.ssh/identity type -1
debug1: identity file /home/WilliamKF/.ssh/id_rsa type 1
debug1: identity file /home/WilliamKF/.ssh/id_dsa type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_4.3
debug1: match: OpenSSH_4.3 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_3.9p1
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-cbc hmac-md5 none
debug1: kex: client->server aes128-cbc hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host 'remoteMachine' is known and matches the RSA host key.
debug1: Found key in /home/WilliamKF/.ssh/known_hosts:47
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,gssapi-with-mic,password
debug1: Next authentication method: gssapi-with-mic
debug1: Authentications that can continue: publickey,gssapi-with-mic,password
debug1: Authentications that can continue: publickey,gssapi-with-mic,password
debug1: Next authentication method: publickey
debug1: Trying private key: /home/WilliamKF/.ssh/identity
debug1: Offering public key: /home/WilliamKF/.ssh/id_rsa
debug1: Server accepts key: pkalg ssh-rsa blen 149
debug1: read PEM private key done: type RSA
debug1: Authentication succeeded (publickey).
debug1: channel 0: new [client-session]
debug1: Entering interactive session.

这是客户端的功能：

void // virtual
Sender::connectTCP()
{
  // First build the feedback channel's socket & make it reuseable
  // so we don't get the nasty message.
  if (0 > (setFbSocket(socket(AF_INET, SOCK_STREAM, 0)))) {
    THROW_ERR("failed to create the command socket: ");
  }

  setSocketOptions();

  // Build the localIp address and bind it to the feedback socket.
  // Although it's not traditional for a client to bind the sending socket
  // to a the local address, we do it to prevent connect() from using an
  // ephemeral port which (our site's firewall may block). Also build the
  // remoteIp address.
  buildAddr(getTCPcommandLocalAddr(), getLocalHost().c_str(),
            getLocFbPort());
  deepBind(getFbSocket(), getTCPcommandLocalAddr());
  buildAddr(getTCPcommandRemoteAddr(), getRemoteHost().c_str(),
            getRemFbPort());

  // Connect to the receiver at the remote addr.  Make multiple attempts
  // when we get a connection refused errno (ECONNREFUSED).  ECONNREFUSED
  // means no one is listening at the other end ... which my be the result
  // of a race condition (i.e., we're calling connect before the server has
  // gotten to listen.)
  const int timeoutMinutes = 5;
  const int timeoutSeconds = timeoutMinutes * 60;
  int conCount = timeoutSeconds;

  while ((conCount > 0) &&
         (0 > ::connect(getFbSocket(),
                        (sockaddr*)&getTCPcommandRemoteAddr(),
                        sizeof(sockaddr)))) {
    switch (errno) {
      case ECONNREFUSED: {
        ::sleep(1);
        --conCount;
        // Warn every 15 seconds, but don't warn at 5 minutes exactly.
        if ((conCount % 15) == 0 && conCount) {
          clog << "Warning: The server connection"
               << " has been refused for "
               << timeFromSeconds(timeoutSeconds - conCount)
               << ", will continue to retry  for up to "
               << timeoutMinutes << " minutes.\n"
               << "Perhaps ports " << getRemFbPort() << " and "
               << getRemDataPort()
               <<
            " are not being routed properly to the server or alternatively "
            "perhaps nothing on the server is listening to those ports?\n";
        }
        continue;
      }
      case EHOSTUNREACH: {
        clog << "Error: Command connect failed: No route to host '"
             << getRemoteHost() << "'." << endl;
        throw;
      }
      default: {
        clog << "Error: Command connect failed: "
             << strerror(errno) << endl;
        throw;
      }
    }
  }
  if (conCount == 0) {
    clog << "Error: Command connect"
         << " continually refused after retrying for " << timeoutMinutes
         << " minutes: "
         << strerror(errno) << endl;

    throw;
  }

  setCmdBlocking();
  setDataBlocking();
  setFbIsConn(true);

  clog << "Application has connected to "
       << getRemoteHost() << ":" << getRemFbPort() << endl;
}

Answer 1

您是否可能在目标端口上遇到防火墙过滤？您是否尝试连接到端口22或运行sshd的端口;还是其他一些港口？

Answer 2

您似乎明确绑定了套接字的客户端 - 看看您绑定的地址是否恰好无法从服务器框中访问（例如，由于路由问题）。为了能够从潜在的防火墙问题（即防火墙允许端口22，但拒绝您的应用程序端口）告诉它，尝试telnet到目标主机：端口而不是ssh到端口22。

Answer 3

名称解析有些奇怪吗？（您可能会被主机文件绊倒吗？通过DNS中的AAAA（IPv6）记录，ssh忽略了吗？ssh_config？）可能值得在详细模式下运行ssh以查看它连接的主机。

当ssh工作正常时，为什么:: connect（）返回EHOSTUNREACH？

3 个答案: