简介使用telnet远程登陆虚拟机下的Linux是许多初学者的常见需求。这份参考文档以Red Hat Linux 9为例面向Linux入门与运维人员系统梳理了远程登录所需的环境检查与配置步骤。内容包括通过rpm -q telnet与rpm -q telnet-server检查服务是否安装缺失时从安装盘获取rpm包进行安装启动服务有两种方式既可用ntsysv勾选telnet也可编辑/etc/xinetd.d/telnet将disable改为no网络部分详细对比host-only、bridge、NAT三种虚拟机连接方式分别介绍如何设置IP、网关与DNS并建议用ping命令验证连通性防火墙配置可放行23端口或暂时关闭iptables同时给出修改PAM配置、注释securetty以允许root远程登录的方法。最后补充SSH Secure Shell Client的Quick Connect连接步骤便于在虚拟机与主机间远程控制和传输文件。资源为单个PDF文件大小仅34KB内容紧凑适合部署时快速查阅其中对常见登录失败原因也有排查建议目前已有150人学习。1. 用 telnet 远程登陆虚拟机下的 Linux这条老路为什么今天还得走一遍看到“使用 telnet 远程登陆虚拟机下的 linux”我猜你多半是在照着某份实验手册做练习Windows 宿主机上开着 VMware虚拟机里装着 CentOS 或 Ubuntu然后想从宿主机开一个命令行窗口telnet 到那台虚拟机的 23 端口输入用户名密码进入 Linux shell。这事听着复古但在教学、考证、离线内网调试这些场景里它依然是出现频率极高的操作而且特别适合拿来理解“客户端-服务端-端口”这条最基本链路。telnet 最大的价值在于两点一是协议简单几乎任何系统都自带客户端一行命令就能测端口通不通二是它能很直观地把问题拆成网络层和服务层出错了你知道该往哪查。很多初学者在虚拟机里装完 Linux第一步就卡在“怎么从外面连进去”这篇就按我平时排障的顺序把网络配置、服务安装、客户端使用、常见坑一次讲完过程可直接照抄参数我会逐个说明为什么这么设。2. 开连之前的网络底子让宿主机与虚拟机 Linux 先互相看得见telnet 能不能连上七成问题出在网络配置而不是 telnet 本身。我见过太多人装好 Linux 镜像后直接敲telnet 192.168.x.x结果不是超时就是拒绝连接最后发现虚拟机的网卡模式和宿主机根本不在一个网段。所以第一步先把两台机器之间的网络关系理清。2.1 三种虚拟网络模式telnet 登录该选哪一种VMware 的虚拟机网络设置里有三种常见模式NAT、桥接、仅主机。它们决定了宿主机能不能访问虚拟机、虚拟机能不能上网、外部机器能不能访问虚拟机。我在 VMware 虚拟机安装 Linux 时默认不改模式因为 NAT 对大多数实验场景够用。网络模式虚拟机访问外网宿主机访问虚拟机外部机器访问虚拟机适用场景NAT可以走宿主机共享可以不行单机实验、本机 telnet/ssh 调试桥接可以占用局域网 IP可以可以模拟真实服务器局域网多人访问仅主机不行可以不行完全隔离环境离线测试如果只是宿主机 telnet 进虚拟机里的 LinuxNAT 模式就够了这也是 VMware 的默认选项。NAT 模式下虚拟机的网卡会走 VMnet8 虚拟交换机宿主机这边对应出现一张叫“VMware Network Adapter VMnet8”的网卡只要两边 IP 在同一个网段就能直接通信。要注意的一点是NAT 模式并不是把虚拟机隐藏起来宿主机完全可以访问它只是外部局域网机器访问不到而已。很多人误以为 NAT 下宿主机也连不上于是在虚拟机里手忙脚乱改成桥接反而把局域网搞出 IP 冲突。改模式之前先在 VMware 虚拟机的“网络适配器”设置里确认当前是哪一种别凭感觉。2.2 在虚拟机里查 IP 的 Linux 常用命令模式确认后需要拿到虚拟机的 IP 地址。登录虚拟机用下面几条 Linux 常用命令之一查看# 查看所有网卡的 IP 地址最常用 ip addr show # 只显示 IPv4 地址输出更干净 hostname -I # 查看默认路由确认走哪张网卡上网 ip route逻辑说明这三条命令我一般按顺序用。ip addr show能看到网卡名称 ens33、eth0 之类、MAC 地址、IPv4 地址是排查网络问题的第一手信息hostname -I只把本机所有 IPv4 地址列出来适合快速抄 IPip route看默认路由能确认虚拟机上网走的是哪张网卡如果 NAT 模式下虚拟机本身上不了网问题多半出在 VMware 的 NAT 服务或宿主机防火墙。参数说明如果网卡没被正确识别可能是 VMware Tools 没装好或者网卡没启用。用ip link set ens33 up手动拉起网卡后再次查看。另外注意hostname -I的 I 是大写字母不是数字 1拼错会直接报“command not found”。拿到虚拟机 IP 后记下来。比如 NAT 模式下常见的是 192.168.xx.yy 这种地址xx 取决于 VMware 网络编辑器里 VMnet8 的子网设置。接着在 Windows 宿主机的命令行窗口里执行ipconfig找到“VMware Network Adapter VMnet8”那一栏看它的 IP 地址是否和虚拟机同网段若是网络层的通路就有了。2.3 宿主机与虚拟机互联互通验证拿 ICMP 当第一道探针网络配置类问题先用 ping 验证是最省事的。在 Windows 命令行窗口里执行:: 用虚拟机 IP 替换下面的地址 ping 192.168.66.128在虚拟机的 Linux 终端里反向 ping 宿主机 VMnet8 网卡的地址# 先看宿主机 VMnet8 的 IP再 ping 它 ping 192.168.66.1逻辑说明ICMP 是最低层的网络探针它能通说明 IP 层没问题它不通后面 telnet 也不必试了省得绕圈子。反向 ping 这一步很多人忽略实际上它很有价值如果虚拟机 ping 不通宿主机说明 VMnet8 网卡或 Windows 防火墙在拦截那你后面折腾服务端配置都是白费。参数说明ping 不通时按这个顺序查。第一确认虚拟机网卡模式确实是 NAT第二确认 Windows 的防火墙没有拦截 ICMP 回显请求第三打开 VMware 的“编辑-虚拟网络编辑器”看 VMnet8 的子网地址是否被改成过如果子网和真实局域网重复会出现路由混乱这种问题在办公室网络环境里特别常见我的经验是把 VMnet8 子网改成一个少用的私网段比如 192.168.88.0/24能避免大量冲突。注意这里我特意提到 VMware 虚拟网络编辑器里的子网配置因为很多人只改虚拟机的 IP不改 VMware 侧的子网结果怎么配对不成功。VMnet8 子网决定 DHPC 分配的网段虚拟机的 IP 要落在这个网段里才稳。3. 在 Linux 虚拟机里把 telnet 服务端跑起来安装、配置、开机自启网络层通了第二步是在虚拟机里把 telnet 服务跑起来。这一步的关键是明白一件事telnet 分客户端和服务端Linux 默认通常只带客户端服务端要单独装。很多人敲telnet发现只有客户端能进、连不上自己就是因为服务端压根没装。3.1 先确认系统里有没有 telnet 服务端ss 与 rpm 双检查不要急着安装先检查当前状态。我习惯在虚拟机里执行下面一组 Linux 常用命令判断 telnet 服务端是否已经存在# 查看 23 端口有没有进程在监听 ss -tlnp | grep :23 # 查看 telnet 相关的已安装软件包CentOS/RHEL 系 rpm -qa | grep telnet # 查看 telnet 相关的已安装软件包Ubuntu/Debian 系 dpkg -l | grep telnet逻辑说明ss -tlnp是查看端口监听的推荐命令老教程里常用的netstat -tlnp在现代发行版上可能要额外安装 net-tools 才能用所以我直接用 ss。如果 23 端口有监听说明服务端已经在跑直接跳到后面的宿主机会话部分如果没有输出说明服务端未安装或未启动。rpm -qa | grep telnet和dpkg -l | grep telnet分别对应红帽系和 Debian 系的包检查方式能确认你装的是 telnet 客户端还是服务端。参数说明这里我刻意把 ss 放在第一条是因为端口监听状态比包是否存在更接近事实。有时候包装了但服务没起来23 端口依然没有监听你光看 rpm 输出会被误导。另外提一句现在很多 Linux 镜像安装完后连 telnet 客户端都不带用which telnet就能验证。如果没有客户端也别慌服务端装好后通常会把客户端一起带上来。3.2 用包管理器安装 telnet 服务端CentOS 系与 Ubuntu 系两条命令CentOS/RHEL 7 及以上的系统telnet 服务端包名是telnet-server靠xinetd或 systemd 的 socket 机制托管Ubuntu/Debian 系的包名则完全不同叫做telnetd由openbsd-inetd这类 inetd 守护进程来接收外部连接。这两者的差异经常把跨发行版做实验的新人整懵明明按教程装了却起不来多半是包名和托管方式不对应。CentOS/RHEL 系的安装命令# 安装 telnet 服务端和客户端 yum install -y telnet-server telnet # 使用 systemd socket 方式启动并设置开机自启 systemctl enable --now telnet.socket # 查看监听端口是否就绪 ss -tlnp | grep :23Ubuntu/Debian 系的安装命令# 更新软件索引后安装 telnetd 与 inetd 守护进程 apt update apt install -y telnetd openbsd-inetd # 查看 inetd 是否在监听 23 端口 ss -tlnp | grep :23逻辑说明CentOS 7 起telnet-server 已经支持 systemd 的 socket 激活机制telnet.socket这个 unit 会在有连接进来时才拉起服务配置比 xinetd 简单得多。Ubuntu 的 telnetd 则依赖 inetd 框架openbsd-inetd 会在 23 端口收到连接时调用/usr/sbin/in.telnetd来处理。两条命令链的差别体现了两个发行版对“传统服务托管”的不同思路理解这一点比死记命令更重要。参数说明systemctl enable --now里的--now是让服务立即启动并同时设置开机自启一个参数干两件事别拆成两步。如果装完后 ss 里看不到 23 端口监听先systemctl status telnet.socket看 socket 状态再看是否被防火墙挡了这个问题在避坑章节细说。3.3 让服务监听 23 端口 systemd socket 方式与 xinetd 方式的取舍老教程里有一大批是基于 xinetd 的/etc/xinetd.d/telnet里面写disable no再重启 xinetd。这套方案在 CentOS 6 时代没问题但在 CentOS 7 以后就会出现“服务启动失败”或“端口已被占用”的怪象因为 systemd 的 telnet.socket 和 xinetd 都想管理 23 端口。我的取舍原则是能用 systemd socket 就不碰 xinetd尤其新手别两头都开。如果你用的是老发行版只能走 xinetd可以参考下面的配置# 编辑 xinetd 的 telnet 服务配置 vim /etc/xinetd.d/telnetservice telnet { flags REUSE socket_type stream wait no user root server /usr/sbin/in.telnetd log_on_failure USERID disable no }保存后重启 xinetdsystemctl restart xinetd systemctl enable xinetd逻辑说明这段配置里disable no是关键表示启用服务socket_type stream对应 TCP 流式连接telnet 必须这么写user root是让 telnetd 以 root 身份启动但这不代表客户端登录时能直接用 root登录权限是另一套 PAM 机制决定的后面避坑章节会讲。如果你之前启用了 systemd 的 telnet.socket建议先systemctl disable --now telnet.socket再启 xinetd避免两边打架。参数说明很多人在这个文件上犯一个低级错误——把注释行也照抄进去导致配置解析失败。disable no前面不要留多余的空格文件末尾留一个空行这是 xinetd 的老规矩。配置完不用重启虚拟机重启 xinetd 服务即可生效。3.4 放行防火墙与临时关闭 SELinux不推荐但要知道服务起来后宿主机还连不上十有八九是防火墙在拦 23 端口。CentOS 7 以上默认用的是 firewalldUbuntu 则是 ufw两条命令都列出来# CentOS/RHEL 系放行 23 端口并重载 firewall-cmd --permanent --add-port23/tcp firewall-cmd --reload # Ubuntu/Debian 系放行 telnet 服务 ufw allow 23/tcp # 老系统的 iptables 写法新系统不建议混用 # iptables -I INPUT -p tcp --dport 23 -j ACCEPT逻辑说明--permanent表示写入永久规则不加的话重启后防火墙规则会丢失这算是新手最常见的坑。--reload是在修改永久规则后让 firewalld 重新读取配置不需要重启防火墙服务。ufw 的allow 23/tcp是直接放行 TCP 23 端口ufw 默认支持端口加协议的写法别漏掉/tcp后缀。参数说明如果你的服务器在云上还需要在安全组里放行 23 端口但本文场景是本地虚拟机一般只涉及宿主机防火墙和虚拟机防火墙两层。SELinux 的问题在 CentOS 老版本上比较突出如果上面都配置好了还是登录异常可以临时setenforce 0验证。不过我明确说一句不建议为跑通 telnet 永久关闭 SELinux这只作为排障手段用完记得恢复。4. 从宿主机发起 telnetWindows 客户端开启与 telnet 命令的基本用法到这一步服务端已经在 23 端口等着了接下来从宿主机发起连接。先说一个很多人第一次栽跟头的地方Windows 10/11 默认没装 Telnet 客户端命令行里敲telnet会直接报“不是内部或外部命令”。这不是你操作错了是系统功能默认关闭了。4.1 Windows 上没有 telnet 命令先开启 Telnet 客户端开启方式有两种我建议先试图形界面不行再走命令行。按下 Win 键搜索“启用或关闭 Windows 功能”找到“Telnet 客户端”勾选确定后稍等片刻即可。如果这一步报“并非所有功能被成功更改”的错误改用下面这条命令在管理员终端里执行# 以管理员身份运行 Windows PowerShell dism /online /enable-feature /featurename:TelnetClient逻辑说明dism 是 Windows 官方的部署映像服务与管理工具/online表示对当前运行中的系统生效/enable-feature指定启用哪个功能/featurename:TelnetClient就是 Telnet 客户端功能项。这条命令比图形界面更可控失败时能看到具体错误代码适合批量或远程排障时的场景。参数说明dism 执行完毕后正常会提示“操作成功完成”。如果提示需要重启那就重启一次别嫌麻烦。重启后再打开一个全新的命令行窗口测试telnet如果还是提示不存在用where telnet查一下命令路径确认功能启用是否真的生效。4.2 一行命令发起登录telnet IP 与 telnet IP 端口 命令怎么看通不通开启客户端后在命令行窗口里发起连接。标准写法是这样:: 直接连接默认的 23 端口 telnet 192.168.66.128 :: 如果 23 端口被改过显式指定端口 telnet 192.168.66.128 2323连接成功后屏幕上会出现 Linux 的登录提示类似CentOS Linux release 7.9.2009 (Core) Kernel 5.10.0-136 on an x86_64 localhost login:输入用户名和密码密码默认不回显不要以为键盘坏了回车后进入 shell。注意telnet 窗口里没有图形界面所有操作都是基于终端的字符输入鼠标滚轮和复制粘贴的行为也和本地终端不同先有个心理准备。逻辑说明telnet IP默认连接 23 端口这是 telnet 协议的标准端口。telnet IP 端口的写法才是这个命令的灵魂——它不仅用来登录更常用来探测任意 TCP 端口是否开放。看到login:提示说明连接已经成功建立到了应用层如果看到的是“connection refused”说明目标端口没有服务在监听如果是长时间卡住不动那多半是防火墙丢弃了包这两种表现有着本质区别下面专门说。4.3 进入 telnet 交互界面后的常用命令open、close、quit 与 Ctrl]当你在 telnet 连接里按下Ctrl]会回到 telnet 的命令行提示符telnet在这里可以管理会话本身。新手第一次按到 Ctrl 组合键看到屏幕变成telnet会以为自己把连接搞坏了其实这只是退出了数据模式进入控制模式。telnet status Connecting to 192.168.66.128:23... Connected to 192.168.66.128. Escape character is ^]. telnet close Connection closed. telnet quit逻辑说明status显示当前连接状态和转义字符close关闭当前连接但保留 telnet 程序quit彻底退出。这组命令在调试时很有用连接挂死了可以先用Ctrl]回控制模式再用close优雅地断开而不是直接关掉窗口。从telnet再敲open 192.168.66.128 23可以直接发起新连接省去退出重开的动作。参数说明转义字符默认是^]也就是 Ctrl 加右方括号。如果在真实操作中这个转义字符不生效检查一下你的终端软件是否拦截了 Ctrl] 组合键Windows 自带的 conhost 和 Windows Terminal 行为不同后者在某些版本里需要额外设置键盘绑定。4.4 telnet 不只能登录它还是端口探测工具这一节单独拿出来讲因为它比“登录虚拟机”本身用得更频繁。运维和开发排查网络问题时经常说的“telnet ip 端口 命令怎么看通不通”指的就是用 telnet 判断一个 TCP 端口是否可访问不需要真登录进去。:: 探测 22 端口看 SSH 是否开放 telnet 192.168.66.128 22 :: 探测 80 端口看 Web 服务是否监听 telnet 192.168.66.128 80如果端口开放屏幕上会看到一段 banner 文本比如 SSH 服务会返回版本号字符串HTTP 服务会等你去发请求连接保持打开不退出如果端口没有监听提示“在端口 22 连接失败”如果被防火墙丢弃则是长时间无响应直到超时。这个差异就是判断“端口通不通”的关键依据。逻辑说明telnet 作为端口探测工具的价值在于它自带 TCP 客户端的全部能力且几乎所有系统都预装。Nmap 虽然功能更强但在受限环境里不一定有而 telnet 是“一定有”的那个。我日常排查“为什么连不上 X 服务”时第一件就是telnet 127.0.0.1 2181、telnet 127.0.0.1 3306这样逐个端口探测把问题快速锁定在“服务没起”还是“网络不通”。参数说明探测 HTTP 端口时连接成功后会静默等待此时可以手动输入 HTTP 请求头再按两次回车比如GET / HTTP/1.1加 Host 头加空行服务器会返回原始响应报文这是一个不装任何浏览器就能检查 Web 服务的技巧。探测完记得按Ctrl]再输quit退出不要让连接挂在那里。5. 避坑telnet 登录虚拟机 Linux 遇到过的 7 个典型问题这一章写的是我在虚拟机和真机上摸索 telnet 时实打实踩过的坑每一条都按“现象→原因→解决”的顺序写。你照着前四章操作如果哪一步不对多半能在这章里找到对应的症状。5.1 连接后立刻断开提示 Connection closing... socket close现象在宿主机敲telnet 192.168.66.128看到几行欢迎信息后马上断掉出现类似Connection closing...socket close.或Connection closed by foreign host的提示。 原因telnet 服务端虽然启动了但在认证或会话建立阶段选择了关闭连接。常见的有三种第一服务端配置里限制了连接来源第二PAM 配置不允许你的登录身份第三SELinux 或防火墙策略主动断开。 解决先用journalctl -u telnet.socket或/var/log/secure查看服务端日志看是否有关键的认证错误。如果是 root 登录被拒切到普通用户试试普通用户也断临时setenforce 0验证 SELinux 因素排除后恢复。5.2 宿主机提示 telnet 不是内部或外部命令现象在 Windows 命令行窗口输telnet系统提示“不是内部或外部命令也不是可运行的程序或批处理文件”。 原因Windows 10/11 默认状态下 Telnet 客户端功能是关闭的需要手动启用这和我第四章说的情况完全一致。 解决按 Win 键搜索“启用或关闭 Windows 功能”勾选“Telnet 客户端”或用管理员身份执行dism /online /enable-feature /featurename:TelnetClient。完成后开新的命令行窗口再试。这一步做完依然提示不存在干脆用虚拟机里的 Linux 客户端反连宿主机来验证服务端状态能绕开本机客户端缺失的问题。5.3 能 ping 通虚拟机但 telnet 端口连接超时或拒绝现象宿主机 ping 虚拟机 IP 正常但telnet 192.168.66.128 23要么一直卡住要么很快提示连接失败。 原因ping 通只说明 ICMP 可达不能证明 23 端口开放。这题要查三个层次虚拟机防火墙是否放行 23 端口、telnet 服务是否真的在监听、宿主机与虚拟机之间是否有中间设备拦截。 解决在虚拟机上执行ss -tlnp | grep :23确认监听存在再执行firewall-cmd --list-portsCentOS或ufw statusUbuntu确认放行规则。两项都正常回到宿主机检查 Windows 防火墙是否拦了到虚拟机的出站连接或者把虚拟机的网络模式从仅主机改成 NAT 再试。5.4 能输入用户名但密码死活提示 Login incorrect现象telnet 连接正常输入用户名后回显“Password:”输入密码回车提示Login incorrect反复确认密码没有打错。 原因第一telnet 是明文传输从宿主机到虚拟机的链路上任何跳板都可能看到密码但这不是“Login incorrect”的直接原因第二更常见的是 PAM 限制了某些用户的登录比如 root 在 telnet 上默认被拒第三键盘布局问题导致密码里的特殊字符被输错比如和的位置在不同布局下完全不同。 解决先切到普通用户登录能进则说明 root 被限制了。若普通用户也不行用 VMware 的控制台登录虚拟机执行tail -20 /var/log/secure看 PAM 具体拒绝原因。顺带检查一下是不是 Caps Lock 或键盘布局的问题telnet 窗口里按一次 Shift 再输入密码是有效的排障手段。5.5 root 登录被拒telnet 默认对 root 不友好现象普通用户能登录但用 root 登录时提示Login incorrect哪怕密码绝对正确。 原因为了安全较新版本的 Linux 在 PAM 配置里禁止 root 通过 telnet 直接登录/etc/pam.d/remote和/etc/securetty里通常有相关限制。这种设计从一开始就是不鼓励你用明文协议做特权操作。 解决实在需要 root 登录可以在/etc/pam.d/remote里注释掉拒绝 root 的行或者把pts/0加入/etc/securetty。但我给你一个更稳的做法先用普通用户登录登录后执行su -切换到 root这样既能避开 PAM 限制又能强制自己记住 root 切换这个标准操作。5.6 虚拟机重启后 IP 变了登录地址失效现象昨天telnet 192.168.66.128还能进今天同样地址连不上了在 VMware 里打开虚拟机一看IP 变成了另一个网段或另一个地址。 原因虚拟机默认走 DHCP 获取 IPVMware 的 NAT 模式每次租约到期或虚拟网络重启后分配的地址可能变化。这不算 telnet 的问题但它是 telnet 登录失败里最主要的网络层原因。 解决给虚拟机配置静态 IP。在 CentOS 系里改/etc/sysconfig/network-scripts/ifcfg-ens33把BOOTPROTOstatic并手动指定 IP、网关、DNSUbuntu 系则改/etc/netplan/00-installer-config.yaml把 DHCP 改成静态地址。配完后重启网络服务再顺手更新宿主机之后要用到的 IP 记录。 参数说明设置静态 IP 时务必把地址落在 VMnet8 子网范围里默认通常是 192.168.xx.0/24否则宿主机和虚拟机又不在一个网段了。我的经验是直接把 IP 设置为该网段的 128 或 200 这种靠后的地址避免和 DHCP 池前部地址冲突。5.7 telnet 窗口里中文乱码、退格键失效现象登录 Linux 成功执行命令时能看到中文输出但全是乱码按退格键删除字符时屏幕上没有反应或者出现^H这样的字符。 原因telnet 协议本身不协商字符编码Windows 命令行默认的代码页GBK 或 CP936和 Linux 端默认的 UTF-8 不一致中文自然乱码退格键失效则是因为终端类型TERM 环境变量没有正确设置Linux 侧默认的 erase 字符和 Windows 发送的键码对不上。 解决在 Linux 登录后先执行export TERMlinux可以改善部分终端控制问题乱码则建议把 Windows 命令行切到 UTF-8 编码执行chcp 65001后再发起 telnet。实在不行换个思路Windows 侧用 Xshell、MobaXterm 这类终端软件它们带的 telnet 客户端在字符编码和键盘映射上更完善能少折腾很多。6. 进阶用脚本把 telnet 登录自动化顺手验证一下它为什么不能上生产等到你能顺利 telnet 进虚拟机 Linux 之后多半会想比手工敲命令更进一步比如批量检查多台虚拟机的 23 端口状态或者自动登录执行一遍系统巡检。我把这两个实用场景在这里展开一是用 Python 写一个最小登录脚本二是在虚拟机里抓包看看 telnet 的明文本质。6.1 用 Python 的 telnetlib 写自动登录脚本Python 的标准库曾经自带一个 telnetlib 模块做自动化登录非常方便特别适合跑巡检任务。需要注意 Python 3.13 起这个模块已被移除建议在 3.8 到 3.12 的环境里运行下面是一个最小可用的脚本import telnetlib import time HOST 192.168.66.128 PORT 23 TIMEOUT 10 USER testuser PASSWORD your_password # 建立连接 tn telnetlib.Telnet(HOST, PORT, TIMEOUT) # 等待登录提示 tn.read_until(blogin:, TIMEOUT) tn.write(USER.encode(ascii) b\n) # 等待密码提示 tn.read_until(bPassword:, TIMEOUT) tn.write(PASSWORD.encode(ascii) b\n) # 等待 shell 提示符出现 tn.read_until(b$, TIMEOUT) # 执行一条命令 tn.write(bwhoami\n) time.sleep(1) output tn.read_very_eager().decode(utf-8, errorsignore) print(output) tn.write(bexit\n) tn.close()逻辑说明脚本流程和手工操作完全一致连接→等待 login 提示→发用户名→等待 Password 提示→发密码→等待 shell 提示符→执行命令→退出。read_until是阻塞等待指定字节串出现超时会抛异常它保证你不会在提示符还没出现时就发送内容write则把命令字节流发给服务端注意要手动拼接\ntelnetlib 不会自动补回车。read_very_eager是读取当前缓冲区里已有的输出配合time.sleep等一会再读是获取命令输出的通用方式。参数说明脚本里的blogin:和bPassword:必须和服务端提示文本完全匹配不同发行版的提示大小写可能不同如果匹配不上read_until会一直等直到超时。最稳妥的先连一次手工 telnet 看提示原文再改脚本里的字节串。这个脚本适合定时巡检把登录后的命令换成df -h、free -m、uptime之类就能批量收集多台虚拟机的系统状态。6.2 抓包验证为什么生产环境坚持用 SSH 而不是 telnettelnet 的最大问题是明文传输。我建议你自己动手验证一次印象会比看一百篇安全文章都深。在虚拟机的 Linux 上抓包然后从宿主机发起一次 telnet 登录# 在虚拟机 root 下抓包抓 23 端口流量 tcpdump -i ens33 -nn -X port 23在宿主机执行telnet 192.168.66.128并登录再回到虚拟机的 tcpdump 输出你会发现数据包里直接呈现用户名、密码以及你输入的所有命令它们是十六进制和 ASCII 文本一起展示的密码部分肉眼可读。把-X换成-A则只显示 ASCII 文本更直观。逻辑说明这个验证说明了一个现实telnet 适合在内网、虚拟机、实验室这种风险可控的环境里做连通性测试和轻量操作不适合承载任何生产环境的管理通道。用 telnet 登录生产服务器等于把 root 密码明文广播给你的所有网络监听者。SSH 才是生产环境的正解它的连接建立过程自带加密和完整性校验这也是几乎每个发行版默认装 OpenSSH 而不装 telnetd 的根本原因。 我的个人习惯是判断端口通不通先telnet IP 端口这是最快的手段真需要登录服务器操作直接 SSH。这两件事分得很清telnet 在我的工具链里永远是一种探针而不是管理通道。你把本文这套流程走完最大的收获不是会用 telnet 登录虚拟机而是建立了一张“网络层→服务层→认证层”的排查地图先 ping 通、再查端口、最后看认证日志一层一层来少了很多玄学。希望帮到你。本文还有配套的精品资源点击获取