telnet 连接 socket 服务接口返回 SSH-2.0-OpenSSH_7.4

        最近需要部署一套 sockert 长连接程序到服务器,让运维开放服务器端口出来,然后测试发现报 SSH-2.0-OpenSSH_7.4  , 用 telnet 连接后  发送消息,服务端程序未收到什么数据。后面排查才明白过来是端口被映射到了服务器22端口上,应该是运维兄弟没明白我的需求,以为我是需要通过外网登录服务器。

     以下内容是询问AI给的回复: 

     这说明您连接的是一个运行 SSH 服务的 socket。SSH (Secure Shell) 是一种加密网络协议,它用于在不安全的网络上安全地进行远程登录和其他网络服务。通常情况下,telnet 连接的是一个运行 telnet 服务的 socket,但是如果您连接的是一个运行 SSH 服务的 socket,您就会看到 "SSH-2.0-OpenSSH_7.4" 这样的提示。

   

Local ident: 'SSH-2.0-ssh2js1.16.0' Client: Trying 192.168.133.135 on port 22 ... Socket connected Remote ident: 'SSH-2.0-OpenSSH_7.4' Outbound: Sending KEXINIT Inbound: Handshake in progress Handshake: (local) KEX method: curve25519-sha256@libssh.org,curve25519-sha256,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha256,diffie-hellman-group15-sha512,diffie-hellman-group16-sha512,diffie-hellman-group17-sha512,diffie-hellman-group18-sha512,ext-info-c,kex-strict-c-v00@openssh.com Handshake: (remote) KEX method: curve25519-sha256,curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha256,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1 Handshake: KEX algorithm: curve25519-sha256@libssh.org Handshake: (local) Host key format: ssh-ed25519,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,rsa-sha2-512,rsa-sha2-256,ssh-rsa Handshake: (remote) Host key format: ssh-rsa,rsa-sha2-512,rsa-sha2-256,ecdsa-sha2-nistp256 Handshake: Host key format: ecdsa-sha2-nistp256 Handshake: (local) C->S cipher: aes128-gcm@openssh.com,aes256-gcm@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr Handshake: (remote) C->S cipher: chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com,aes128-cbc,aes192-cbc,aes256-cbc,blowfish-cbc,cast128-cbc,3des-cbc Handshake: C->S Cipher: aes128-gcm@openssh.com Handshake: (local) S->C cipher: aes128-gcm@openssh.com,aes256-gcm@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr Handshake: (remote) S->C cipher: chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com,aes128-cbc,aes192-cbc,aes256-cbc,blowfish-cbc,cast128-cbc,3des-cbc Handshake: S->C cipher: aes128-gcm@openssh.com Handshake: (local) C->S MAC: hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1 Handshake: (remote) C->S MAC: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1 Handshake: C->S MAC: <implicit> Handshake: (local) S->C MAC: hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1 Handshake: (remote) S->C MAC: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1 Handshake: S->C MAC: <implicit> Handshake: (local) C->S compression: none,zlib@openssh.com,zlib Handshake: (remote) C->S compression: none,zlib@openssh.com Handshake: C->S compression: none Handshake: (local) S->C compression: none,zlib@openssh.com,zlib Handshake: (remote) S->C compression: none,zlib@openssh.com Handshake: S->C compression: none Outbound: Sending KEXECDH_INIT Received DH Reply Host accepted by default (no verification) Host accepted (verified) Outbound: Sending NEWKEYS Inbound: NEWKEYS Verifying signature ... Verified signature Handshake completed Outbound: Sending SERVICE_REQUEST (ssh-userauth) Inbound: Received EXT_INFO Inbound: Received SERVICE_ACCEPT (ssh-userauth) Outbound: Sending USERAUTH_REQUEST (none) Timed out while waiting for handshake,为什么连接不上虚拟机
最新发布
09-25
<think> 我们正在处理SSH连接虚拟机时出现"Timed out while waiting for handshake"错误的问题。根据引用内容,我们可以分析原因并给出解决方案。 原因分析: 1. SSH服务未运行(引用[4]):检查sshd服务状态,确保服务已启动。 2. 防火墙阻止连接(引用[5]):检查主机和虚拟机的防火墙状态,确保防火墙已关闭或放行SSH端口(22)。 3. 网络配置问题:虚拟机网络设置是否正确(如NAT、桥接等),IP地址是否可达。 4. SSH配置问题(引用[3]):可能SSH配置中设置了某些限制(如监听地址、端口等)。 5. 连接超时设置(引用[3]):可以调整服务端的ClientAliveInterval和ClientAliveCountMax参数。 6. 其他:如端口被占用(引用[2])、主机密钥问题等。 解决方案: 步骤1:检查SSH服务状态 在虚拟机执行: ```bash sudo systemctl status sshd # 或 service sshd status ``` 如果未运行,则启动服务: ```bash sudo systemctl start sshd # 或 service sshd start ``` 并设置开机自启(可选): ```bash sudo systemctl enable sshd # 或 chkconfig sshd on ``` 步骤2:检查防火墙状态 虚拟机中关闭防火墙(临时)并禁止开机启动: ```bash # 对于使用systemd的系统(如CentOS7+、Ubuntu16.04+) sudo systemctl stop firewalld # 停止防火墙 sudo systemctl disable firewalld # 禁止开机启动 # 对于使用iptables的系统(如Ubuntu14.04) sudo service iptables stop sudo chkconfig iptables off ``` 另外,确保主机防火墙也没有阻止连接(特别是Windows主机需检查防火墙设置)。 步骤3:检查SSH端口监听 在虚拟机执行: ```bash sudo netstat -tuln | grep :22 ``` 如果没有输出,说明SSH没有监听22端口。检查SSH配置文件`/etc/ssh/sshd_config`中是否有`Port 22`以及`ListenAddress`是否被注释掉(默认监听所有地址)。 步骤4:检查网络连通性 从主机ping虚拟机的IP地址,确认网络可达。如果虚拟机使用NAT模式,检查主机和虚拟机的IP是否在同一网段(注意NAT模式下主机和虚拟机不在同一网段,但主机可以通过NAT连接虚拟机,所以主要检查虚拟机的网络配置)。 步骤5:检查SSH配置 编辑SSH配置文件: ```bash sudo vi /etc/ssh/sshd_config ``` 确保以下配置(特别是前两条): ``` Port 22 #ListenAddress 0.0.0.0 # 确保这一行被注释,表示监听所有地址 ``` 然后重启SSH服务: ```bash sudo systemctl restart sshd ``` 步骤6:调整超时设置(可选) 在SSH配置文件`/etc/ssh/sshd_config`中添加或修改: ``` ClientAliveInterval 60 ClientAliveCountMax 3 ``` 然后重启SSH服务。 步骤7:检查端口冲突 如果SSH端口22被其他进程占用,则需停止占用进程(引用[2]): ```bash sudo lsof -i :22 ``` 根据输出杀死占用进程(注意不要杀死sshd本身): ```bash sudo kill <PID> ``` 步骤8:检查主机密钥问题 如果之前连接过相同IP的虚拟机,但虚拟机系统重新安装或克隆后密钥改变,主机上的`~/.ssh/known_hosts`文件会记录旧密钥,导致拒绝连接。此时可以删除该IP对应的密钥行,或者使用命令: ```bash ssh-keygen -R 虚拟机IP ``` 如果以上步骤仍无法解决,可以尝试增加SSH连接的详细日志(在客户端连接时加`-v`选项): ```bash ssh -v 用户名@虚拟机IP ``` 根据详细日志进一步排查。 相关问题: §§相关问题§§ 1. 如何配置SSH密钥登录以提高安全性? 2. SSH连接中的主机密钥验证机制是什么? 3. 如何设置SSH免密登录? </think> ### SSH连接虚拟机出现"Timed out while waiting for handshake"错误的原因与解决方案 #### 错误原因分析 根据引用信息和系统诊断,该错误主要由以下因素导致: 1. **网络连接问题** - 防火墙阻止SSH流量(主机或虚拟机端) - 虚拟机网络配置异常(NAT/桥接模式错误)(引用[5]) $$ \text{连接成功率} = P(\text{网络可达}) \cdot P(\text{端口开放}) \cdot P(\text{服务响应}) $$ 2. **SSH服务异常** - sshd服务未运行或崩溃(引用[4]) - 配置错误导致握手失败(引用[3]) 3. **资源冲突** - 端口22被其他进程占用(引用[2]) $$ \exists PID \ne sshd:\ \text{bind}(PID, 22) $$ 4. **超时设置不合理** - 默认握手超时时间过短(尤其在高延迟网络)(引用[3]) #### 系统化解决方案 ##### 步骤1:检查基础服务状态 ```bash # 检查SSH服务状态 sudo systemctl status sshd # 若未运行(显示inactive),启动服务: sudo systemctl start sshd sudo systemctl enable sshd # 设置开机自启 # 验证端口监听 sudo netstat -tuln | grep :22 # 正常应显示:tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN ``` ##### 步骤2:防火墙配置调整 ```bash # 虚拟机端防火墙处理(CentOS/RHEL) sudo systemctl stop firewalld sudo systemctl disable firewalld # Ubuntu/Debian sudo ufw disable # Windows主机需关闭防火墙或添加规则: netsh advfirewall firewall add rule name="SSH" dir=in action=allow protocol=TCP localport=22 ``` ##### 步骤3:排查端口冲突 ```bash # 查找占用22端口的进程 sudo lsof -i :22 # 终止冲突进程(替换<PID>为实际值) sudo kill <PID> # 强制终止(慎用) sudo kill -9 <PID> ``` ##### 步骤4:优化SSH配置 编辑`/etc/ssh/sshd_config`: ```bash sudo vi /etc/ssh/sshd_config ``` 关键参数调整: ```ini # 增加握手超时容错 LoginGraceTime 2m # 登录宽限期从默认2分钟延长 # 保持连接心跳(引用[3]) ClientAliveInterval 60 # 每60秒发送心跳包 ClientAliveCountMax 3 # 连续3次无响应才断开 # 确保监听所有接口 ListenAddress 0.0.0.0 Port 22 ``` 保存后重启服务: ```bash sudo systemctl restart sshd ``` ##### 步骤5:网络诊断 ```bash # 在主机测试网络连通性 ping <虚拟机IP> # 测试端口可达性 telnet <虚拟机IP> 22 # 或使用nmap nmap -p 22 <虚拟机IP> ``` ##### 步骤6:密钥问题处理 ```bash # 清除客户端旧密钥(解决密钥变更冲突) ssh-keygen -R <虚拟机IP> # 强制重新验证密钥 ssh -o StrictHostKeyChecking=no user@<虚拟机IP> ``` #### 补充诊断建议 当上述措施无效时: 1. 检查虚拟机网络模式(NAT/桥接需与物理网络匹配) 2. 查看详细错误日志: ```bash journalctl -u sshd --since "5 min ago" | grep -i error ``` 3. 使用调试模式连接: ```bash ssh -vvv user@<虚拟机IP> # 三个v显示最详细日志 ```
评论 4
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

witkey_ak9896

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值