1. 检查本地Telnet服务状态

第一步，咱们得先确认Debian系统里到底有没有安装Telnet服务，包括客户端和服务端。打开终端，输入下面这行命令探探底：

telnet --version

如果系统已经装了Telnet，它会大大方方地告诉你版本号，比如“telnet 0.17-39”。要是没装，也别急，用下面这条命令就能搞定安装：

sudo apt update && sudo apt install telnet

装好之后，还得看看Telnet服务有没有在后台跑起来。在Debian系统里，这活儿通常由inetd或者systemd来管。你可以用下面的命令检查一下：

sudo systemctl status inetd
# 如果系统用的是inetd来管理
# 或者
sudo systemctl status telnetd
# 如果Telnet是作为独立服务运行的

2. 使用Nmap扫描目标主机Telnet端口

接下来，咱们请出网络扫描的“瑞士军刀”——Nmap。它能帮你探测目标主机开放了哪些端口，甚至能识别出服务的具体版本。当然，前提是你得先把它装上（命令：sudo apt install nmap）。

针对Debian系统检测Telnet漏洞，下面这个命令算是家常便饭：

nmap -p 23 example.com
# 扫描目标主机的23端口，也就是Telnet的默认端口

扫描结果怎么看？如果看到“23/tcp open telnet”这行字，那就意味着目标主机的Telnet大门敞开着。要是显示“filtered”，那多半是防火墙立了道墙，把连接给拦下了。

3. 测试Telnet端口连通性

理论扫描完了，还得实践出真知。最直接的办法，就是用Telnet命令亲自去敲敲那扇门，看看23端口到底通不通（记得确保telnet客户端已经安装）。

telnet example.com 23

连接之后，无非几种情况：

• 如果连接成功，终端要么会跳到一个空白屏幕，要么会显示服务的欢迎信息（比如“Linux telnetd”）。这说明端口开放，服务正在运行。
• 如果蹦出“Connection refused”（连接被拒绝），那基本可以断定端口没开，或者对应的服务根本没启动。
• 要是遇到“Timeout”（连接超时），问题可能就复杂点了，很可能是防火墙规则或者网络路径上的某个环节把连接请求给吞了。

4. 分析服务版本信息（可选）

如果想更深入地评估风险，搞清楚对面跑的是什么版本的Telnet服务会很有帮助。不同版本可能对应着不同的已知漏洞。这时候，Nmap的-sV参数就能派上用场了：

nmap -sV -p 23 example.com

扫描结果里会多出一个“Service version”字段，比如“Linux telnetd 1.8.0”。拿到这个版本号，你就可以去CVE这类漏洞数据库里查查，看看它有没有什么“案底”。

注意事项

最后，必须得提个醒。Telnet协议有个众所周知的“硬伤”：它传输的所有数据，包括用户名和密码，都是明文的。这就好比在熙熙攘攘的大街上用大喇叭喊你的银&行密码，非常容易被“中间人”窃听攻击。

因此，强烈不建议在生产环境中使用Telnet。检测工作完成后，一个良好的安全习惯是立即把它关掉。你可以用下面的命令禁用服务：

sudo systemctl stop inetd && sudo systemctl disable inetd

然后，用更安全的SSH协议来替代它。安装OpenSSH服务端很简单：

sudo apt install openssh-server

安全无小事，替换掉不安全的旧协议，才是治本之策。