企业官网建设流程全解析

说实话，现在再写一篇 linux安装telnet服务 的完整实操文章，多少有点"返祖"的感觉。我最近一次被问到 telnet，是帮一个同事排查内网老设备：管理口只开了 telnet，SSH 连不上，而他笔记本上连客户端都没装。那一刻我就意识到，telnet 虽然早就被 SSH 按在地上摩擦，但在设备调试、内网连通性测试、协议学习这些场景里，它依然是绕不开的工具。这篇就把 Linux 下安装 telnet 服务端和客户端的完整过程写出来，覆盖 Debian/Ubuntu 和 CentOS/RHEL 两条主流路线，也把我踩过的坑和排查思路一并交代清楚。适合需要在内网临时搭建 telnet 服务、给老设备做调试入口、或者纯粹想搞懂 telnet 工作机制的读者。

1. 为什么到今天还有人折腾telnet

1.1 它到底在哪些场景还管用

telnet 是上世纪诞生的远程终端协议，默认端口 23，原理非常朴素：建立 TCP 连接之后，直接以明文文本交换终端会话内容。SSH 普及之后，正经服务器默认装 SSH、不装 telnet，但在下面几类场景里 telnet 仍然是高频工具。

• 网络设备调试。很多交换机、路由器、IP 电话、嵌入式开发板，出厂默认开启 telnet 管理口。在没有 console 线、SSH 又没配置的情况下，telnet 往往是最后的登录通道。
• 内网服务连通性测试。telnet 客户端可以当成一把"端口小刀"，直接连到任意 TCP 端口，从响应情况判断服务有没有起、防火墙有没有放行。比起 nc，telnet 在更多最小化系统里更容易获得，交互也更直观。
• 学习 TCP 协议和网络编程。telnet 没有 TLS 握手、没有密钥交换，纯文本传输，连上就是裸的 TCP 会话，观察"连接建立、请求交互、连接断开"整个过程非常清晰。

我见过不少新同学问：既然 SSH 那么强，为什么还要装这个老古董？答案很简单：不是所有设备都支持 SSH，也不是所有场景都需要加密。telnet 适合"临时、内网、调试"三个条件同时满足的场景。只要这三个条件有一个不满足，就优先考虑 SSH。尤其是服务器管理，千万不要用 telnet 做日常运维，密码全部明文在网络上裸奔，和把家门钥匙贴在门牌号下面没有区别。

1.2 先分清楚服务端和客户端

很多人一上来就问"怎么安装 telnet"，其实要先想清楚自己的角色。

• 如果只是需要远程登录一台已经开了 telnet 的设备，装客户端就够了，不需要在本地 Linux 上装服务端。
• 如果是要让别的主机远程登录到这台 Linux，才需要装服务端。
• 如果只是测试某个 TCP 端口通不通，客户端也够用，而且这种用法在排障时比单独的工具更好使。

本篇文章服务端和客户端都会覆盖，顺序是先装服务端，再讲客户端，最后是排查思路和安全边界。

2. 装之前先把系统和网络底细摸清楚

2.1 识别发行版与软件源状态

安装第一步不是敲安装命令，而是确认发行版。telnet 服务端在不同发行版上的组件差异很大，命令用错就会卡在E: Unable to locate package这种报错上。

用下面这条命令看一下系统信息：

cat /etc/os-release

看到ID=ubuntu或ID=debian，走apt路线；看到ID="centos"或ID="rhel"，走yum路线。这个步骤不要跳过，我见过不止一个同事在 CentOS 上用apt install，结果自然是失败。

确认发行版后，先把软件源刷新一遍：

• Ubuntu/Debian：sudo apt update
• CentOS/RHEL：sudo yum makecache fast，或者直接sudo yum repolist

内网机器如果没有外网软件源，刷源会超时。这时候要改用本地镜像源或者离线 rpm 包，具体取决于你们内部的基础设施。可以先ping一下源地址看通不通，但能 ping 通不代表 HTTP 源可用，真正判断要等apt update或yum repolist的实际结果。

2.2 端口、防火墙和客户端角色的规划

telnet 服务端默认监听 23 端口。动手之前把三件事想清楚：

1. 这台机器是纯客户端还是也要当服务端。只是远程登录别人，装客户端就好，不需要引入服务端。
2. 23 端口要不要对整个内网开放。如果只给特定几台调试机用，最好只放行那几个 IP，不要全网可扫。
3. 23 端口有没有被其他进程占用。先跑一句sudo ss -tlnp | grep :23，如果已经有进程在监听，服务会起不来，后面排查会很绕。

还有一个经常被忽视的点：telnet 服务端通常不是独立常驻进程，而是由一个"超级服务"间接管理。Debian/Ubuntu 上是openbsd-inetd，CentOS/RHEL 上是xinetd。超级服务负责监听 23 端口，有连接进来时再拉起/usr/sbin/in.telnetd。所以排查故障时，重点看超级服务的状态，而不是找 telnetd 进程。

3. 服务端安装：Debian和CentOS两条路线一起讲

3.1 Ubuntu/Debian 走 openbsd-inetd

在 Ubuntu 或 Debian 上安装服务端非常省事：

sudo apt update sudo apt install -y telnetd

安装telnetd时，系统会顺便装上openbsd-inetd，并且自动往/etc/inetd.conf里写入 telnet 启动项。装完后先查看配置：

cat /etc/inetd.conf | grep telnet

正常会看到类似这样的一行：

telnet stream tcp nowait telnetd /usr/sbin/tcpd /usr/sbin/in.telnetd

拆开解释一下：telnet是服务名，stream tcp表示面向连接的 TCP 流套接字，nowait表示每个连接上来后立即启动子进程处理，telnetd是运行身份，/usr/sbin/tcpd是 TCP Wrapper 包装程序，最后才是真正的 telnet 守护进程/usr/sbin/in.telnetd。之所以套一层tcpd，是为了支持/etc/hosts.allow和/etc/hosts.deny做访问控制。

如果配置行不存在，可以手动加到/etc/inetd.conf末尾再重启服务。手动加的时候要小心空白字符：inetd.conf 按空白分段，用 Tab 还是空格不一致，服务可能不认。实际踩坑中，最常见的错误就是从网页复制配置时，多个连续空格被复制成了不同字符，导致服务端怎么都起不来。

3.2 CentOS/RHEL 走 xinetd

CentOS/RHEL 上经典做法是装telnet-server和xinetd：

sudo yum install -y telnet-server telnet xinetd

注意这里telnet是客户端包，telnet-server才是服务端，两个都要装。装完后配置文件不是自动生成的，通常在/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。网上很多老教程抄来抄去写的是disable = yes，装完怎么连都不通，最后才发现配置默认是禁用状态。如果你是从某个旧博客复制的配置，第一件事就把这一行改成no。

关于user = root，意思是 telnetd 进程以 root 身份运行。不建议为了安全改成普通用户，因为登录后涉及权限切换，容易产生各种奇怪问题。真正的安全措施应该放在防火墙和白名单上，而不是削弱进程权限。

3.3 启动服务与端口自检

Ubuntu/Debian 重启超级服务并确认状态：

sudo systemctl restart openbsd-inetd sudo systemctl status openbsd-inetd

CentOS/RHEL 启用并启动 xinetd：

sudo systemctl enable --now xinetd sudo systemctl status xinetd

CentOS 上如果只启动了 xinetd 而忘了设开机自启，下次服务器重启之后 telnet 会消失。enable --now一条命令同时解决启动和自启，比较省心。

然后确认端口已经处于监听状态：

sudo ss -tlnp | grep :23

如果看到类似0.0.0.0:23的监听记录，说明超级服务已经在替 telnet 站岗了。如果没有任何输出，先别急着连，直接跳到第 5 章的排查链路。

3.4 防火墙和 TCP Wrapper 的放行

系统防火墙按发行版区分：

• Ubuntu/Debian 多数用 ufw：sudo ufw allow 23/tcp
• CentOS/RHEL 7+ 多数用 firewalld：

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

如果习惯用纯 iptables，可以临时加一条规则验证：

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

但临时规则重启后会丢，长期使用请用iptables-save或写入持久化配置。

TCP Wrapper 是另一个大坑。Debian/Ubuntu 的 telnet 默认经过/usr/sbin/tcpd，CentOS 的 xinetd 本身也支持访问控制。如果/etc/hosts.deny里写了ALL: ALL，那么即使防火墙放行了，telnet 连接也会被 tcpd 直接拒绝，表现是"能连一下马上断开"。排查方法：先把ALL: ALL注释掉再试一次，确认根源后，在/etc/hosts.allow里具体放行来源网段，而不是为了省事把安全策略全删了。

看一段示例，放行内网调试机：

in.telnetd: 192.0.2.15 in.telnetd: 192.0.2.0/24

保存后重启超级服务即可生效。

4. 客户端连接与顺手的端口探测技巧

4.1 客户端安装

客户端安装比服务端更简单：

• Ubuntu/Debian：sudo apt install -y telnet
• CentOS/RHEL：sudo yum install -y telnet

这里有个容易绕晕的点：CentOS 上telnet-server和telnet是两个包，服务端不包含客户端功能。以为装了服务端就能自己连自己，结果发现命令不存在，这种情况我见过太多次。

4.2 登录验证与 Telnet 控制序列

客户端装好后，连接服务端：

telnet 192.0.2.25

如果端口通了，会看到：

Trying 192.0.2.25... Connected to 192.0.2.25. Escape character is '^]'.

接着出现登录提示，输入用户名密码后进入 shell，说明整套服务已经正常。在 telnet 会话里，终端控制方式和 SSH 略有不同。按Ctrl+]会进入 telnet 命令提示符telnet>，输入quit才能干净利落地断开连接。很多新手卡在"怎么退出 telnet"上，直接按Ctrl+C会把终端搞乱，正确姿势是先按Ctrl+]，再输入quit。

4.3 用 Telnet 临时当端口探测工具

telnet 不只是登录终端，还可以测试任意 TCP 端口。比如想看某台机器 Web 服务是否在 8080 端口响应：

telnet 192.0.2.25 8080

连接后如果停留在黑窗口，大概率端口通；如果立刻提示Connection refused，说明服务没监听或者被防火墙拒绝。对 HTTP 服务还可以进一步验证，连接后手动输入一个请求：

GET / HTTP/1.0 Host: 192.0.2.25

然后按两次回车，如果服务端返回 HTTP 响应内容，说明 Web 服务本身正常。这个技巧在排查"防火墙到底放没放行""服务进程有没有真的监听"时特别高效，比临时写脚本快多了。

5. 安装后连不上的典型排查链路

5.1 从端口监听开始往外面查

遇到连不上，不要凭感觉乱改配置，按层级一层层查。第一步永远是在服务端确认端口在监听：

sudo ss -tlnp | grep :23

如果这里没输出，问题基本不在客户端和防火墙，而在服务本身。接着看超级服务状态：

sudo systemctl status openbsd-inetd # 或者 sudo systemctl status xinetd

服务状态显示inactive (dead)，启动它并看日志。Debian/Ubuntu 看journalctl -u openbsd-inetd，CentOS 看journalctl -u xinetd。日志里如果有配置语法错误，通常会直接指出哪一行。我遇到过的常见问题，就是手改/etc/inetd.conf时缩进和空白字符不对，单看眼睛发现不了，服务却始终不认。

5.2 监听正常但连不上的防火墙问题

如果ss已经看到 23 端口 LISTEN，但客户端连接超时或拒绝，绝大多数问题在防火墙。先看本机防火墙：

• CentOS/RHEL：sudo firewall-cmd --list-all，看ports里有没有23/tcp
• Ubuntu/Debian：sudo ufw status查看规则
• 纯 iptables：sudo iptables -L -n

本机防火墙看不出问题时，再查 TCP Wrapper。CentOS 的 xinetd 配置文件如果带only_from，来源网段写错也会导致连接被丢弃。Debian 系则多看看/etc/hosts.allow和/etc/hosts.deny。一个相对隐蔽的现场是：/etc/hosts.deny里有ALL: ALL，但/etc/hosts.allow没有单独放行 telnet，tcpd 会把所有来源拒之门外，表现就是"端口能通，登录提示一闪而过或直接断开"。

5.3 SELinux 导致的半通状态

CentOS/RHEL 机器如果开着 SELinux，telnet 可能出现"端口通、连接马上断"的诡异现象。排查思路不要一上来就关 SELinux，而是先看审计日志：

sudo grep -i telnet /var/log/audit/audit.log sudo audit2why < /var/log/audit/audit.log

如果日志中有denied关键字，可以先sudo setenforce 0临时放宽容许状态，验证是否为 SELinux 引起，确认之后再去找对应的布尔值或策略模块，处理完记得sudo setenforce 1恢复。直接永久关闭 SELinux 是很糟糕的做法，为一个小服务把整台机器的安全水位拉低，完全得不偿失。

5.4 登录被拒和回显异常的特殊情况

能连上但登录失败，最常见的是用户认证问题。Ubuntu/Debian 上 root 默认不能通过 telnet 直接登录，这是securetty和 PAM 的限制在起作用，属于安全机制。测试时建一个普通用户：

sudo useradd -m testuser sudo passwd testuser

然后用这个普通用户登录。如果连接后回显乱码或者退格键失效，通常是最初终端类型不匹配。连接前在本地执行export TERM=xterm，或者在 telnet 提示符下用set term vt100调整，能解决大部分终端问题。

5.5 故障症状与处理方式速查表

这张速查表基本覆盖了 90% 的 telnet 安装问题，每次帮人排查时我都会按这个链路走。

6. 安全边界：装完telnet之后别忘了这几件事

6.1 明文协议的真实风险

telnet 最大的问题不是功能少，而是所有通信都明文传输。用户名、密码、敲的每一条命令，在网络上以明文形式流动。任何能在链路上抓包的人，都能直接看到登录凭据。这个风险不是理论上的，用抓包工具在链路上抓一会儿就能看到完整的用户名和密码。所以 telnet 服务一旦暴露到不可信网络，等于把服务器登录凭据挂在门口。正因如此，生产环境里的 telnet 服务应当被限制到最小范围。

6.2 最小化暴露：白名单、临时启用、监控审计

如果确实必须开 telnet，我的建议是按这个顺序做：

1. 只监听在内网网卡上，修改超级服务配置把监听地址绑定到内网 IP，而不是0.0.0.0全监听。xinetd 配置里可以增加bind = 192.0.2.25。
2. 在防火墙只放行特定调试机 IP 访问 23 端口。用 firewalld 的富规则：

sudo firewall-cmd --permanent --add-rich-rule='rule family="ipv4" source address="192.0.2.15" port protocol="tcp" port="23" accept' sudo firewall-cmd --reload

3. 调试结束后立即停掉服务。Ubuntu/Debian 注释掉/etc/inetd.conf里的 telnet 行，重启openbsd-inetd；CentOS 上直接systemctl disable --now xinetd或改配置disable = yes。
4. 如果公司有日志审计系统，把 telnet 登录日志纳入监控，23 端口出现异常扫描时能第一时间发现。

6.3 长期使用的替代方案

如果需求是长期远程管理 Linux 服务器，请务必用 SSH，或者至少用 SSH 隧道把 telnet 流量保护起来。典型做法是先建立 SSH 隧道，再把 telnet 客户端连到本机端口，让明文流量走加密通道：

ssh -L 8023:目标服务器IP:23 跳板用户@跳板机IP

然后在本地执行：

telnet 127.0.0.1 8023

这样目标服务器仍然开 telnet，但 23 端口只暴露给跳板机和内网，SSH 隧道负责加密和认证，整体安全水位会好很多。这个方案适合那些只有 telnet 接口的设备，又不希望凭据在网络上裸奔的场景。

我自己实际运维中的习惯是：除非给网络设备做临时调试，否则 Linux 服务器上根本不长驻 telnet 服务端。真正需要装机时，装完后第一件事验证 23 端口监听和一个普通用户能正常登录，然后立刻把服务停掉或者把防火墙白名单收紧。因为 telnet 装起来太简单了，反而容易让人忽略它该有的约束。

还有一个小技巧：如果只是临时想测某个 TCP 端口通不通，系统里没有 telnet 也没有 nc，可以试试 Bash 的内建能力：

timeout 2 bash -c "</dev/tcp/192.0.2.25/8080"

命令正常返回说明端口可通，超时则说明被丢包或拒绝。平时多备几个这样的调试手段，等真在现场遇到问题时，就不至于手忙脚乱了。