Telnet作为一款经典的远程登录协议，虽然在现代网络环境中已被SSH取代，但在特定的网络调试、设备管理及内网运维场景下，它依然具有不可替代的轻量级优势，在Linux系统中配置Telnet服务，核心在于掌握软件包的安装、服务端口的监听设置以及防火墙策略的放行，同时必须深刻理解其明文传输的安全特性,将其严格限制在受信任的局域网环境中使用。
环境准备与软件包安装
在Linux系统中配置Telnet，首先需要区分客户端和服务端，大多数Linux发行版默认仅安装了Telnet客户端，若要将本机配置为Telnet服务器，必须手动安装服务端软件包，对于基于RedHat系列的系统（如CentOS、Fedora），通常使用telnet-server包；而对于基于Debian系列的系统（如Ubuntu），则对应为telnetd。
在CentOS 7或8系统中，由于软件源管理方式的变更，安装前需确认仓库是否可用，安装命令非常直接，通过yum或dnf即可完成。安装完成后，关键的一步是检查xinetd服务，因为Telnet通常作为一种由超级服务器xinetd管理的非独立服务运行，如果系统未安装xinetd，必须先行安装并启动它,否则Telnet服务无法正常监听网络请求。
对于Ubuntu用户，安装过程相对简化，通常通过apt-get install telnetd即可，但在某些新版本中，可能需要安装openbsd-inetd作为网络守护进程来管理Telnet的启动，安装过程不应仅停留在命令执行层面，更应关注安装后的日志输出,确保没有依赖包缺失的错误提示。
服务端配置与启动参数优化
Telnet服务的核心配置文件通常位于/etc/xinetd.d/目录下，文件名为telnet，在这个配置文件中，有几个关键参数直接决定了服务的运行状态，首先是disable参数，默认通常设置为yes，必须将其修改为no，以告知xinetd允许该服务启动，其次是flags参数，常用的设置包括REUSE，这允许TCP套接字在地址被占用时快速重用,有助于服务在高频重启后的快速恢复。
在配置文件中，only_from参数是一个重要的安全控制手段，默认情况下，该参数可能被注释掉，意味着允许任何IP地址连接，为了增强安全性，建议在此处明确指定允许访问的网段或IP地址，例如写为only_from = 192.168.1.0/24，这样即使用户账号泄露,外部网络也无法直接连接Telnet端口。
Linux系统出于安全考虑，默认不允许root用户直接通过Telnet登录，这是通过/etc/securetty文件控制的，该文件列出了允许root登录的终端设备，如果必须在紧急情况下通过Telnet使用root账号（极度不推荐），管理员需要在此文件中添加相应的pts设备（如pts/0、pts/1）。专业的运维建议是始终通过普通用户登录，再使用su -或sudo切换至root，这样既能满足管理需求,又能最大程度降低凭证泄露风险。
配置修改完成后，必须重启xinetd服务使配置生效，在Systemd管理体系下，使用systemctl restart xinetd命令即可，可以使用netstat -antp | grep 23或ss -lntp | grep 23命令验证23端口是否处于LISTEN状态。
防火墙与SELinux策略调整
在现代Linux发行版中，即使服务启动成功，默认的防火墙策略往往会阻断外部连接，配置防火墙是Telnet服务可用的必要环节，对于使用firewalld的系统，需要执行firewall-cmd --zone=public --add-port=23/tcp --permanent并重载防火墙，务必加上--permanent参数,否则重启后规则会失效。
SELinux（Security-Enhanced Linux）是另一个常见的“拦路虎”，如果SELinux处于Enforcing强制模式，它可能会阻止Telnet服务监听端口或写入日志，检查/var/log/audit/audit.log可以帮助定位SELinux相关的拒绝访问错误，临时解决方案是将SELinux模式调整为Permissive，但长期且专业的做法是使用audit2allow工具生成自定义策略模块，允许Telnet服务的特定行为,从而在保持安全性的前提下实现功能。
客户端连接测试与故障排查
配置完成后，测试应从本地开始，使用telnet localhost 23验证服务是否响应，如果本地连接失败，应优先检查服务状态和端口监听情况，本地成功后,再从局域网内的其他主机进行连接测试。
在故障排查过程中，常见的报错如“Connection refused”通常意味着服务未启动或端口被防火墙阻断；而“Connection timed out”则往往指向中间网络设备的ACL策略或主机防火墙丢弃了数据包。利用tcpdump抓包工具进行诊断是高效手段，例如执行tcpdump -i any port 23 -w telnet.pcap，通过分析抓包文件，可以清晰地看到TCP三次握手的过程是在哪一步中断的,从而精准定位问题。
安全风险与专业建议
必须强调，Telnet协议最大的缺陷在于其明文传输机制，所有的用户名、密码以及交互数据都以纯文本形式在网络中传输，极易被嗅探软件截获，在公网环境或生产环境中,严禁直接开启Telnet服务。
专业的解决方案是建立分层管理网络，将Telnet仅用于带外管理网络，该网络与生产业务网络物理隔离，或者，仅在系统出现网络故障导致SSH无法连接时，作为一种临时的应急救援手段启用，故障排除后立即关闭服务，结合TCP Wrappers（/etc/hosts.allow和/etc/hosts.deny）进行访问控制，可以提供比xinetd更灵活的主机级访问限制。
在实际运维中，Telnet的另一大价值并非远程登录，而是端口连通性测试，使用telnet ip port来检测目标服务的端口是否开放，是网络工程师必备的技能,这比单纯的Ping命令更能反映应用层的可达性。
相关问答
Q1：为什么在Linux系统中使用Telnet连接时，普通用户可以登录，但root用户登录失败？
A1：这是Linux系统的一种安全机制，系统通过/etc/securetty文件限制root用户只能在特定的安全终端设备上登录，Telnet使用的是伪终端（如pts/0），默认情况下不在该列表中，为了安全起见，建议不要修改此文件直接开放root登录，而是使用普通用户登录后通过su -切换权限。
Q2：配置完Telnet后，客户端提示“Connection closed by foreign host”，如何解决？
A2：这个错误通常意味着TCP连接建立成功，但在后续的握手或认证阶段断开了，常见原因包括：1. /etc/xinetd.d/telnet配置文件中的log_on_failure设置导致日志记录问题；2. 系统的PAM（Pluggable Authentication Modules）配置错误；3. /etc/securetty或/etc/hosts.deny拒绝了连接，建议检查/var/log/messages或/var/log/secure日志文件以获取具体的错误信息。
如果您在配置Telnet服务的过程中遇到关于特定发行版的依赖问题，或者有更复杂的网络环境需求，欢迎在评论区留言,我们将为您提供进一步的故障排查建议。
