开启 Linux Telnet 服务的核心上文归纳在于：正确安装 telnet-server 软件包、配置 xinetd 超级服务器或 systemd 服务，并精准调整防火墙与 SELinux 策略。 尽管在当前的网络环境中，SSH 协议因其加密特性已成为远程管理的绝对主流，但 Telnet 作为一种经典的网络协议，在排查网络连通性、调试特定端口状态以及维护某些无法使用 SSH 的老旧遗留系统时，依然发挥着不可替代的底层调试作用，本文将基于 CentOS/RHEL 及 Ubuntu/Debian 两大主流发行版，详细阐述 Telnet 服务的开启流程、安全加固方案及故障排查思路。
环境准备与软件包安装
在 Linux 系统中，Telnet 服务通常由两部分组成：客户端和服务器端，默认情况下，大多数 Linux 发行版仅预装了客户端，用于连接其他服务，若要将本机配置为 Telnet 服务器,必须手动安装服务端软件包。
对于 CentOS 7/8、RHEL 及 Rocky Linux 等基于 Red Hat 的系统，Telnet 服务通常由 xinetd（超级互联网守护进程）进行管理，需要确认系统是否已安装 telnet-server 和 xinetd，可以通过 rpm -qa | grep telnet 命令进行查询，若未安装,执行以下命令进行安装：
yum install -y telnet-server xinetd
对于 Ubuntu 20.04/22.04 及 Debian 系统，Telnet 服务通常由 inetd 或直接由 systemd 管理,安装命令如下：
apt-get update apt-get install -y telnetd xinetd
注意： 在现代 Ubuntu 系统中，有时仅安装 telnetd 即可，但为了保持配置的一致性和兼容性，建议同时安装 xinetd,因为它是管理按需启动服务的传统且高效的方式。
核心配置文件详解与启用
安装完成后，Telnet 服务默认处于禁用状态，这是出于安全考虑,开启服务的核心在于修改配置文件。
配置 xinetd 下的 Telnet
在 Red Hat 系列系统中，Telnet 的配置文件位于 /etc/xinetd.d/telnet，使用文本编辑器（如 vi 或 nano）打开该文件，你需要找到 disable = yes 这一行，将其修改为 disable = no，这一步至关重要，它告诉 xinetd 守护进程允许监听 Telnet 连接请求。
为了增强服务的可追溯性，建议在配置文件中增加日志记录选项，例如添加 log_on_success += USERID 和 log_on_failure += USERID，这样可以记录下成功或失败连接的源用户信息,便于后续的安全审计。
启动并设置开机自启
配置文件修改完毕后，需要重启 xinetd 服务以使配置生效。
systemctl restart xinetd systemctl enable xinetd
可以使用 netstat -antp | grep :23 或 ss -lntp | grep :23 命令检查系统是否已开始监听默认的 23 端口，如果看到 xinetd 进程正在监听 TCP 23 端口,说明服务端已成功启动。
防火墙与 SELinux 策略调整
即便服务已启动并监听端口，Linux 内核自带的防火墙和 SELinux 安全机制仍会阻断外部连接,这是运维中最容易被忽视的环节。
防火墙配置
对于使用 Firewalld 的系统（如 CentOS 7+），必须将 Telnet 服务添加至信任区域，或者直接开放 23 端口：
firewall-cmd --permanent --add-service=telnet firewall-cmd --reload
对于使用 UFW 的 Ubuntu 系统,执行：
ufw allow 23/tcp
如果是传统的 Iptables，则需要添加规则：iptables -A INPUT -p tcp --dport 23 -j ACCEPT,并记得保存规则。
SELinux 设置
在 CentOS/RHEL 系统中，SELinux 处于 Enforcing 强制模式，它会阻止 Telnet 服务访问关键的系统资源，可以通过 getenforce 命令查看状态，若需临时测试，可执行 setenforce 0 将其转为 Permissive 模式，若要永久开启 Telnet 支持,应使用管理工具调整布尔值：
setsebool -P telnetd_disable_trans 1
或者确保 SELinux 策略允许 telnet 监听网络,这通常需要安装特定的策略包或正确配置文件上下文。
安全风险与专业运维见解
必须强调的是，Telnet 协议采用明文传输数据。 这意味着用户的账号、密码以及传输的所有数据在网络上都是以纯文本形式发送的，极易被中间人攻击嗅探截获，在生产环境中开启 Telnet 存在极大的安全隐患。
专业的解决方案与独立见解：
- 严格限制访问来源： 不要将 Telnet 服务暴露在公网，应在防火墙中配置，仅允许内网特定的管理 IP 地址访问 23 端口，仅允许 192.168.1.0/24 网段连接。
- 利用 TCP Wrappers： 通过配置
/etc/hosts.allow和/etc/hosts.deny文件，在服务层面进一步限制访问权限，在hosts.allow中写入in.telnetd: 192.168.1.，在hosts.deny中写入in.telnetd: ALL。 - 仅用于调试，禁用于登录： 在很多现代运维场景中，开启 Telnet 仅仅是为了测试某台服务器的端口连通性（
telnet ip port），而非为了远程 Shell 管理，如果是为了连通性测试,建议在测试完成后立即关闭服务。 - 容器化隔离： 如果必须使用 Telnet 服务进行某些老旧设备的通信，建议将其部署在独立的容器或虚拟机中，与核心业务系统隔离,降低被攻破后的横向移动风险。
常见故障排查
在配置过程中，可能会遇到“Connection refused”或“Connection timed out”错误。
- Connection refused： 通常表示服务未启动，或端口被防火墙拒绝，且目标主机可达，此时应检查
systemctl status xinetd及防火墙规则。 - Connection timed out： 通常表示请求在传输途中被丢弃，可能是中间网络设备（如路由器、ACL）拦截，或者是目标主机的内核防火墙直接 DROP 了包,没有返回拒绝信息。
- 无法登录（Login incorrect）： 如果服务连接正常但无法登录，除了检查密码外，还应检查
/etc/securetty文件（在某些旧版系统中，它限制了 root 只能从物理终端登录），以及 PAM 模块配置。
相关问答
Q1：为什么在现代 Linux 系统中，Telnet 默认都是关闭的，使用它有什么替代方案吗？
A： Telnet 默认关闭是因为其明文传输机制存在严重的安全隐患，容易被黑客窃听账号密码，目前的标准替代方案是 SSH (Secure Shell) 协议，SSH 使用非对称加密进行身份验证，并对所有传输的数据进行加密，能够完美防御流量劫持、中间人攻击等威胁，在 99% 的远程管理场景下，都应优先使用 SSH。
Q2：我已经开启了 Telnet 服务，但无法使用 root 用户登录，提示“Login incorrect”，密码是正确的，这是为什么？
A： 这通常是由于系统安全策略限制导致的，在许多 Linux 发行版（如 Red Hat 系列）中，默认配置禁止 root 用户通过 Telnet 直接远程登录，以防止特权账号泄露，这是通过 /etc/securetty 文件或 PAM（Pluggable Authentication Modules）配置控制的。解决方案是： 先使用普通普通用户登录 Telnet，然后通过 su - 或 sudo -i 命令切换至 root 用户，如果必须允许 root 直接登录，需要修改 /etc/securetty（添加 pts/0 等伪终端）或调整 PAM 配置，但出于安全考虑,强烈不建议这样做。
互动环节：
您在日常运维工作中是否遇到过必须使用 Telnet 才能解决的特殊网络故障？或者您所在的团队是如何管理 Telnet 这种高风险服务的？欢迎在评论区分享您的实战经验和安全策略，欢迎关注本网站，获取更多 Linux 运维与网络技术干货。
