企业官网建设流程全解析

1. 项目背景与常见用途盘点

说实话，看到“linux安装telnet服务”这个标题，我的第一反应是：现在还用telnet的人不多了，但凡是写这篇文章，多半是因为实际工作里确实撞上了这个需求。我在日常运维和交付项目时遇到过几类典型场景，这里先说清楚，方便你对号入座。

第一类是调试老设备。有些网络设备、嵌入式板卡、老型号存储设备，管理接口只开放了telnet协议，你不得不装一个客户端去连；第二类是内网环境做端口连通性测试，很多团队在排查“两台机器之间某个端口到底通不通”时，第一时间想到的就是telnet命令；第三类则是某些特定合规或教学环境，需要提供telnet服务端，比如做协议分析、给学员演示明文协议的危害。

需要特别强调的是，生产环境里用telnet做远程登录我是不推荐的，密码和内容全部明文传输，抓包就能看到。但在受控的内网测试环境、临时调试场景里，它依然是个非常趁手的工具。这篇文章我会把服务端和客户端的安装、配置、启动、验证、排障全部走一遍，覆盖常见发行版，同时把我在实际环境中踩过的坑一并写给读者参考。

适合谁来读？如果是刚接触Linux的读者，跟着步骤操作可以完成基础安装；如果你已经有几年经验但没在内网环境专门配过telnet服务端，可以重点看配置细节和排障思路。内容围绕“装起来、跑起来、能登录、能测试、能排查”这条主线，不绕弯子。

2. 安装前准备与协议基础

2.1 telnet协议前世今生

telnet是一个非常古老的远程终端协议，从1969年诞生到现在已经跨越了半个世纪。它工作在TCP层，默认端口23，核心作用就是让用户通过网络连接到远程主机，以字符终端方式执行命令。因为是纯文本协议，所有交互内容不加密，这也是它被SSH取代的根本原因。

但从排障角度看，telnet客户端恰恰因为“简单到极致”而不可替代：它就是建立一个TCP连接，然后把键盘输入原样发给对方，把对方返回的字节原样显示出来。这个特性让它成为最直接的TCP端口连通性探测工具，没有TLS握手、没有协议封装、没有多余交互，你敲下一行命令就知道端口通不通。

2.2 服务端与客户端的区别

很多人第一次装telnet容易搞混：telnet-server是服务端，让你这台机器能被别人远程登录；telnet是客户端，让你这台机器能去连接别人的telnet服务。实际工作中，客户端用得频率更高，因为我们日常排障时经常拿它去连其他机器的22、80、443、3306等端口看通不通。

如果只是测试端口连通性，只需要装telnet客户端。如果要求别人能通过telnet登录这台机器，才需要装telnet-server，同时还需要一个守护进程来托管它，常见的是xinetd，在Debian系也有openbsd-inetd可选。

2.3 发行版差异对照

我在不同发行版上安装时，总结了下面这个对应关系，避免在错误的包管理体系里浪费时间：

还有一个容易被忽略的点：很多发行版默认是不带telnet-server的，需要额外配置软件源。比如Rocky Linux 9的AppStream源里虽然有，但要确认epel是否启用，我后面会专门讲。

3. 详细安装步骤与配置说明

3.1 基于CentOS / Rocky / AlmaLinux的安装

RHEL系的操作系统是最常见的目标环境，我以Rocky Linux 9为例，CentOS 7的差异会在括号里说明。

dnf install -y telnet-server telnet xinetd

先装这三个包，telnet-server提供服务端程序，telnet是客户端，xinetd负责把连接请求转发给telnet-server。安装完成后，需要配置xinetd来管理telnet服务，配置文件位置在 /etc/xinetd.d/telnet，示例内容如下：

service telnet { flags = REUSE socket_type = stream wait = no user = root server = /usr/sbin/in.telnetd log_on_failure += USERID disable = no }

这里重点看两个参数：disable必须为no表示启用服务；server指向in.telnetd，这个路径可以用rpm -ql telnet-server确认。配置完成后重启xinetd服务，并设置开机自启：

systemctl restart xinetd systemctl enable xinetd

CentOS 7上没有systemctl enable xinetd的需求时，用chkconfig xinetd on也是一样的效果。我个人的建议是直接用systemctl，因为RHEL 7之后service和chkconfig都只是兼容壳。

3.2 基于Ubuntu / Debian的安装

Debian系走另一套方案，用telnetyd加openbsd-inetd：

apt update apt install -y telnetd openbsd-inetd

安装完成后，openbsd-inetd服务会自动读取 /etc/inetd.conf 配置文件并启动telnet服务。可以检查一下配置文件里是否有一行：

telnet stream tcp nowait telnetd /usr/sbin/telnetd

这一行告诉inetd：如果收到TCP连接请求，就把连接交给/usr/sbin/telnetd处理。所以Ubuntu上启动telnet服务的方式是：

systemctl restart openbsd-inetd systemctl enable openbsd-inetd

如果你更喜欢xinetd而不是openbsd-inetd，也可以apt install xinetd，然后参考上一小节的配置方式，把disable设成no。我试过两种方式，openbsd-inetd更轻量，xinetd日志更丰富，看个人习惯。

3.3 验证安装结果

安装后先别急着连，用以下几条命令做基础验证：

rpm -qa | grep telnet dpkg -l | grep telnet ss -lntp | grep 23

rpm或dpkg两条命令确认软件包已安装。ss -lntp则是关键，一定要看到类似输出：

LISTEN 0 1 0.0.0.0:23 0.0.0.0:* users:(("xinetd",pid=...,fd=...))

如果ss没看到23端口监听，说明服务端没被正确拉起，这个问题在后面的排查章节展开。

3.4 防火墙与安全组放行

服务端启动但不代表外部能连接，很多新手装好之后发现本机可以连、跨机连不上，基本都是防火墙和安全组挡着。

RHEL系默认用firewalld，放行方式如下：

firewall-cmd --permanent --add-port=23/tcp firewall-cmd --reload

如果用iptables管理，加一条规则即可：

iptables -A INPUT -p tcp --dport 23 -j ACCEPT

Ubuntu/Debian系经常用ufw：

ufw allow 23/tcp

这里有个细节我想提醒一下：这台机器如果跑在云平台上，云安全组的入方向规则也要放行TCP 23端口。本地防火墙、云安全组、系统服务三层都要通，任何一层卡住都会表现为“连不上”。

4. 服务连接与登录验证

4.1 本机验证连接

配置完成，先在本机验证telnet服务端是否正常。本机验证可以排除防火墙干扰：

telnet 127.0.0.1 23

如果一切正常，会看到Trying 127.0.0.1...然后进入登录界面，看到“login:”提示符，输入一个系统里存在的账号和密码。如果出现下面这种提示，说明服务没起成功：

telnet: connect to address 127.0.0.1: Connection refused

本地都连不上，先别急着看防火墙，回查服务配置和监听状态。

4.2 跨机器远程连接

本机验证通过后，从另一台机器发起连接：

telnet 192.168.1.10 23

如果看到login提示符，说明跨机器链路已经通了。这里要注意：主机名解析、路由、防火墙都会影响连接，所以建议先直接用IP测试，避免DNS问题干扰判断。

4.3 登录失败的关键点

登录telnet服务时，最常见的问题就是账号密码明明正确，却提示Login incorrect。这种情况十有八九是PAM配置拦了路。

绝大多Linux发行版的telnetd在登录时会调用PAM认证，而有的系统默认策略会禁止root通过telnet登录，或者要求用户必须属于特定组。如果你想允许root登录（通常只在隔离测试环境中这么干，生产环境不推荐），需要改配置：

在 /etc/pam.d/remote 或 /etc/pam.d/login 文件中，找到类似下面这行注释掉或配置相应策略：

auth required pam_securetty.so

pam_securetty.so模块的作用是仅允许root在/etc/securetty列出的终端上登录，默认列出的tty里通常没有telnet对应的虚拟终端。我当时的做法是：如果非要用root登录，先查看/etc/securetty是否配置了pts/0或直接注释掉这行PAM检查。再次强调，这只是测试环境的临时做法，生产环境绝不能让root直接用明文协议登录。

还有一个容易踩的坑：telnet服务使用系统账号认证，那么用户必须拥有有效的shell，比如/bin/bash。如果账号的shell被改成了/sbin/nologin或/bin/false，即便密码正确也会被拒绝。可以用这个命令检查：

grep ^用户名 /etc/passwd

4.4 并发连接与超时限制

xinetd托管的telnet服务，并发连接数默认有限制。如果你遇到超过一定数量后无法连接的情况，可以调整/etc/xinetd.conf的instances参数，或者直接在xinetd.d/telnet里加一行：

instances = 50

表示允许同时最多50个telnet连接。调整后重启xinetd生效。当然，这只是并发限制，每个连接长时间挂着也会占用文件句柄和进程资源，onw参数可以设置空闲超时，比如：

onw = 300

空闲超过300秒会断开连接，这个配置在测试环境非常实用，防止有人连续开着终端浪费资源。

5. 端口连通性测试的高阶用法

5.1 测试常用服务端口

telnet客户端最实用的场景其实就是端口连通性测试。我平时排查架构里各组件之间网络通不通，第一反应就是用telnet去连对方的端口，判断是网络问题还是服务问题。

例如测试Web服务80端口：

telnet 192.168.1.20 80

连接成功后，直接输入：

GET / HTTP/1.1 Host: 192.168.1.20

按两次回车，如果对方返回HTTP协议头，说明Web服务网络层面是通的。想测试HTTPS的443端口也可以，连接后敲一行：

HEAD / HTTP/1.1

然后观察返回结果即可判断TLS端口是否可达。

测试数据库端口也很典型，比如MySQL的3306、Redis的6379、PostgreSQL的5432：

telnet 192.168.1.30 3306

如果端口通，MySQL通常会返回一个带特殊字符和版本信息的二进制头部，Redis则会返回一个错误提示，因为这些服务不会像telnet一样先把login界面给你。你不需要看懂全部内容，只要连接没有被拒绝、没有超时，就说明端口可达。

5.2 测试端口的返回码解读

用telnet测试端口，结果无外乎三种：

这个表是我建议新手收藏的，因为很多人看到Connection refused就以为是防火墙问题，实际上一半情况是服务根本没起来。

5.3 用telnet测试UDP端口行不行

这里提前打个预防针：telnet只能测试TCP端口。UDP协议没有连接概念，telnet不支持也不应该用来测UDP。检测UDP端口连通性需要另外找工具，比如nc（netcat）的 -u 参数：

nc -uvz 192.168.1.40 161

所以工作中注意分辨，别把telnet硬套在UDP场景。

6. 常见问题与排障实录

6.1 服务端已装好但端口未监听

这是最高频的问题，表现为ss -lntp看不到23端口。排查思路按顺序执行：

先确认xinetd或inetd服务有没有启动：

systemctl status xinetd systemctl status openbsd-inetd

没在运行就启动，并确认enable。然后在确认配置文件里disable=no有没有配错。有个细节值得注意：在RHEL系安装时如果只装了telnet-server而不装xinetd，你会发现ss里永远不会有23端口，因为telnet-server依赖xinetd来监听和转发，它本身不直接监听端口。这种情况不是服务坏了，是缺了托管进程。

6.2 本机连接正常但跨机器连不通

本机能连说明服务端没问题，问题出在网络链路上。从头到尾检查三层：

第一层，目标机器自身防火墙，确认firewalld/ufw放行23端口；第二层，云平台安全组或机房防火墙策略，确认入方向TCP 23端口已放行；第三层，中间是否有网络ACL、网关策略限制。从源机器执行命令验证：

ping 目标IP

如果ping通但telnet连不上，多半就是端口放行问题。还有一种不起眼但真遇到过的情况：源机器和目标机器在同一内网不同网段，中间路由设备的入方向策略把23端口挡了，这种需要网络管理员配合调整ACL。

6.3 登录提示Login incorrect但密码确实正确

这种情况非常迷惑人。先检查 /var/log/secure 日志（RHEL系）或 /var/log/auth.log（Debian系），找到对应时间戳的认证失败记录。

我遇到过几次，因素各不相同：用户的shell不可用是一个原因；/etc/pam.d/remote的PAM策略禁止了某个用户组是第二个原因；还有一种是root的securetty限制，也就是前面讲的pam_securetty模块问题。最稳的临时排障办法是新建一个普通用户来测试登录：

useradd testlogin passwd testlogin

如果普通用户可以登录，说明系统账号策略问题；如果普通用户也登不进去，则大概率是PAM公共配置里某个模块拦截了。

6.4 连接被断开或瞬间退出

登录成功后立刻被踢出，这种情况往往跟limits或SELinux有关。排障优先看审计日志，RHEL系执行：

ausearch -m AVC -ts recent | grep telnet

如果看到SELinux拒绝记录，尝试给telnet服务开启对应布尔值：

setsebool -P telnet_connect_all 1

这个布尔值在部分版本上存在，如果提示不存在，用getsebool -a | grep telnet查看当前系统支持的布尔值列表，然后针对性调整。如果不想深究SELinux策略，临时调成permissive模式可以验证：

setenforce 0

但记住这只是验证手段，验证完要马上改回来。

7. 安全加固与生产环境建议

7.1 为什么生产环境不建议用telnet

回到这个老生常谈的问题。telnet协议明文传输，账号密码、命令输出、中间数据全程可被截获。在内网做测试没关系，但放到生产环境、公网环境，就等于把密码用明信片寄出去。所有做过网络抓包的人都懂，telnet会话里的每一个字节都能直接看到。

如果你的环境必须提供telnet服务，有几个底线建议：限制来源IP，只允许特定管理网段访问；不允许root直接登录telnet；配合防火墙做最小化授权；开启完整日志记录；强烈建议只在隔离网段或者临时使用时开启，用完后立刻关闭服务。

7.2 更安全的替代方案

日常运维中，远程登录一律用SSH（Secure Shell），数据加密传输，这是底线要求。如果只是为了端口连通性测试，除了telnet，还可以备选nc和nmap：

nc -vz 192.168.1.50 3306 nmap -p 3306 192.168.1.50

两个工具都能完成端口探测，其中nc可以快速判断TCP端口通断，nmap还能识别服务版本。如果在某台机器上只装了nc没有telnet，用nc替代测试完全没有问题。

7.3 加固已验证的访问策略

如果测试环境确实需要长期开着telnet服务，我建议至少做这几件事：第一，把默认的23端口迁移到高位端口，比如2323，通过xinetd的port配置实现，减少被扫描命中的概率；第二，在防火墙层写上源IP白名单，其他地址一律DROP；第三，建立telnet专用账号并限制其权限，不要给运维管理员级别的系统账号直接使用明文协议登录的权限；第四，记录好审计日志，定期检查/var/log/secure或auth.log里的登录记录。

8. 从零到可用的完整流程速查

这里把整个流程整理成一份速查清单，我每执行一次就会对照一遍，省时有条理。

这个表格适合新环境交付时拿来一条条对照，避免漏步骤。实际工作中我通常把1到4合并执行，然后直接跳到第6步做远程验证，有问题才回到前面逐步排查。

我个人的习惯是，每次在测试机配完telnet服务之后，顺手在客户端执行一遍telnet测试目标端口，把结果记录下来放进交付文档。这样做的好处是，后续别人排查问题时能快速判断当时网络基线状态，知道哪一段是通的、哪一段是后来断的。

写了这么多，其实核心就一句话：telnet安装本身不难，难的是理解它什么时候该用、什么时候坚决不用，以及出了问题怎么快速定位。如果你只是需要端口连通性测试，装个客户端就够；如果你需要完整的远程登录服务，装好服务端的同时一定要把防火墙、SELinux、PAM策略全部走一遍，才能确保从任意客户端都能顺利登入。希望这篇内容能帮读者把安装和排障的路走直一些。