从未收到 SSH 服务器标识 - 握手死锁 [SSHJ]

Question

我们在尝试为我们的应用程序实现 SftpConnections 池时遇到了一些问题。

我们目前使用SSHJ (Schmizz) 作为传输库，并面临一个我们根本无法在我们的开发环境中模拟的问题（但错误在生产中一直随机显示，有时在三天后，有时在 10 天后分钟）。

问题是，当尝试通过 SFTP 发送文件时，线程被锁定在来自 schmizz 的 TransportImpl 类的 init 方法中：

   @Override
    public void init(String remoteHost, int remotePort, InputStream in, OutputStream out)
            throws TransportException {
        connInfo = new ConnInfo(remoteHost, remotePort, in, out);

    try {

        if (config.isWaitForServerIdentBeforeSendingClientIdent()) {
            receiveServerIdent();
            sendClientIdent();
        } else {
            sendClientIdent();
            receiveServerIdent();
        }


        log.info("Server identity string: {}", serverID);

    } catch (IOException e) {
        throw new TransportException(e);
    }

    reader.start();
}

isWaitForServerIdentBeforeSendingClientIdent 对我们来说是 FALSE，所以首先客户端（我们）发送我们的标识，如日志中所示：

"客户身份字符串：blabla"

然后轮到receiveServerIdent：

    private void receiveServerIdent() throws IOException 
{
        final Buffer.PlainBuffer buf = new Buffer.PlainBuffer();
        while ((serverID = readIdentification(buf)).isEmpty()) {
            int b = connInfo.in.read();
            if (b == -1)
                throw new TransportException("Server closed connection during identification exchange");
            buf.putByte((byte) b);
        }
    }

线程永远不会取回控制权，因为服务器永远不会回复它的身份。似乎代码卡在了这个 While 循环中。没有超时，也没有抛出 SSH 异常，我的客户端一直在等待，线程陷入死锁。

这是 readIdentification 方法的实现：

private String readIdentification(Buffer.PlainBuffer buffer)
        throws IOException {
    String ident = new IdentificationStringParser(buffer, loggerFactory).parseIdentificationString();
    if (ident.isEmpty()) {
        return ident;
    }

    if (!ident.startsWith("SSH-2.0-") && !ident.startsWith("SSH-1.99-"))
        throw new TransportException(DisconnectReason.PROTOCOL_VERSION_NOT_SUPPORTED,
                                     "Server does not support SSHv2, identified as: " + ident);

    return ident;
}

似乎 ConnectionInfo 的输入流永远不会读取数据，就好像服务器关闭了连接一样（即使如前所述，没有抛出异常）。

我尝试通过使协商饱和、在连接时关闭套接字、在握手时使用 conntrack 终止已建立的连接来模拟此错误，但一点运气都没有，所以任何帮助都会非常好感激不尽。

:)

Answer 1

我敢打赌下面的代码会产生问题：

String ident = new IdentificationStringParser(buffer, loggerFactory).parseIdentificationString();
if (ident.isEmpty()) {
    return ident;
}

如果 IdentificationStringParser.parseIdentificationString() 返回空字符串，它将返回给调用者方法。调用者方法将继续调用while ((serverID = readIdentification(buf)).isEmpty())，因为字符串始终为空。打破循环的唯一方法是调用int b = connInfo.in.read(); 返回-1...但如果服务器继续发送数据（或重新发送数据），则永远不会满足此条件。

如果是这种情况，我会添加某种人工方法来检测这种情况：

private String readIdentification(Buffer.PlainBuffer buffer, AtomicInteger numberOfAttempts)
        throws IOException {
    String ident = new IdentificationStringParser(buffer, loggerFactory).parseIdentificationString();

    numberOfAttempts.incrementAndGet();


    if (ident.isEmpty() && numberOfAttempts.intValue() < 1000) { // 1000 
        return ident;
    } else if (numberOfAttempts.intValue() >= 1000) {
        throw new TransportException("To many attempts to read the server ident").

    }

    if (!ident.startsWith("SSH-2.0-") && !ident.startsWith("SSH-1.99-"))
        throw new TransportException(DisconnectReason.PROTOCOL_VERSION_NOT_SUPPORTED,
                                     "Server does not support SSHv2, identified as: " + ident);

    return ident;
}

这样您至少可以确认是这种情况，并且可以进一步挖掘 .parseIdentificationString() 返回空字符串的原因。

Answer 2

遇到了类似的问题，我们会看到：

INFO [net.schmizz.sshj.transport.TransportImpl : pool-6-thread-2] - 客户端身份字符串：blablabla

INFO [net.schmizz.sshj.transport.TransportImpl : pool-6-thread-2] - 服务器标识字符串：blablabla

但在某些情况下，没有服务器响应。 我们的服务通常会同时唤醒并传输多个文件，每个连接/线程一个文件。

问题出在 sshd 服务器配置中，我们将 maxStartups 从默认值 10 增加 （我们注意到问题在批量增加到 10 以上后不久就开始了）

/etc/ssh/sshd_config 中的默认值：

MaxStartups 10:30:100

改为：

MaxStartups 30:30:100

最大启动次数

指定到 SSH 守护程序的最大并发未经身份验证的连接数。其他连接将被丢弃，直到身份验证成功或连接的 LoginGraceTime 过期。默认值为 10:30:100。或者，可以通过指定三个冒号分隔的值 start:rate:full（例如“10:30:60”）来启用随机提前丢弃。如果当前有 (10) 个未经身份验证的连接，sshd 将拒绝连接尝试，概率为 rate/100 (30%)。如果未经身份验证的连接数达到满 (60)，则概率线性增加，并且拒绝所有连接尝试。

如果您无法控制服务器，则可能需要找到一种方法来限制客户端代码中的并发连接尝试。