简介面向VMware等虚拟机环境下配置Telnet远程登录Linux的参考文档适合刚接触Linux远程管理的初学者及需要快速搭建实验环境的运维人员。文档以Red Hat Linux 9及Red Hat EL 5为例覆盖从检查telnet与telnet-server包、安装RPM包、修改xinetd配置到配置host-only、bridge、NAT三种虚拟机网络模式以及调整防火墙和允许root登录的完整流程。资源为单个PDF文件大小34KB共1个文件内容精炼、步骤清晰便于随时查阅。目前已有150人学习下载可作为Linux远程管理入门时的手边参考尤其能帮助解决“连不上、登录被拒”等常见问题。文档中还对SSH Secure Shell Client连接虚拟机做了简要介绍并整理了telnet-server安装与测试的实操记录适合跟着命令行逐步操作快速获得可复现的排错思路。1. 用 telnet 远程登录虚拟机里的 Linux先理清这条链路上的四个环节刚装完 VMware 的读者十有八九都干过这件事在 Windows 命令行里敲 telnet 加虚拟机 IP结果不是No route to host就是Connection closed by foreign host。我拆完这份 PDF 之后的感受是telnet 远程登录虚拟机下的 Linux 说穿了就四个环节——服务端包装没装、xinetd 启没启、网络通不通、防火墙放没放行 23 端口。这份资料把这四件事从头到尾记了一遍既讲了 host-only、bridge、NAT 三种网络模式的配法也写了 root 登录被禁时的处理办法中间还夹了不少真实翻车记录。适合做课程设计、实验环境以及需要在 Windows 和 Linux 虚拟机之间互传文件的场景。先把这条链路疏通后面再谈更安全的远程工具才有意义。2. 安装 telnet 服务端分清 client 与 server 两个包再激活 xinetd2.1 先分清两个包telnet 是客户端telnet-server 才是服务端很多人在第一步就搞混了。telnet这个 rpm 包是客户端程序用来发起连接真正对外监听 23 端口的是telnet-server。CentOS、Red Hat 系默认通常只装了客户端服务端要单独装所以rpm -qa | grep telnet之后看到telnet-0.17-39.el5这类结果并不代表服务已经能用了必须确认有没有telnet-server那一行。先做检查命令如下# 查询 telnet 相关包是否安装telnet 是客户端telnet-server 是服务端 rpm -qa | grep telnet # 如果只看到 telnet-xxx说明服务端没装如果两条都没有说明客户端也没装这一步的输出决定了后面的动作。只看得到telnet-0.17-39.el5就说明当前机器只具备发起连接的能力不具备被连接的能力需要补装telnet-server。另外需要留意telnet-server 服务在 RHEL 5、CentOS 5 这类系统里是挂在xinetd超级守护进程下面的所以安装顺序上要先有 xinetd再装 telnet-server反过来经常报依赖错误。2.2 三种安装姿势yum 在线装、光盘 RPM 装、装完直接改配置有网络的环境直接走 yum 最省事。CentOS 5.5 实测过下面的命令可以一次拉齐依赖# 先装 xinetd再装 telnet-server注意都切到 root 下执行 yum install -y xinetd yum install -y telnet-server-y参数表示安装过程中的交互提示全部默认 yes脚本化操作时不会卡在确认环节。xinetd 是 telnet 的宿主服务它的职责是监听端口、按请求拉起对应的后台程序所以必须先保证它存在。没有外网的环境就用光盘。常见做法是把安装盘挂载到/mnt/cdr再从光盘里把 rpm 包拷贝出来装# 建立挂载点并把光驱挂上去cdr 目录可以自己命名 mkdir -p /mnt/cdr mount /dev/cdrom /mnt/cdr # 进入光盘目录按名字找出 telnet 相关安装包 cd /mnt/cdr find . -name telnet* # 把找到的 rpm 包拷到根目录下自建的目录里方便统一安装 cp telnet-server-0.17-39.el5.i386.rpm /keith/ cd /keith rpm -ivh telnet-server-0.17-39.el5.i386.rpmrpm -ivh里的 i 是 installv 是显示详细信息h 是打印进度条。如果这里报依赖缺失基本就是没先装 xinetd把 xinetd 的 rpm 也用同样的方式装一遍再回头装 telnet-server 即可。装完之后可以用rpm -qa telnet-server验证能回显版本号就说明安装成功。2.3 修改 telnet 配置并重启 xinetdtelnet-server 装好之后/etc/xinetd.d/telnet这个配置文件才会出现。文件里默认有一行disable yes意思是服务处于禁用状态需要改成no# 编辑 telnet 的 xinetd 配置 vi /etc/xinetd.d/telnet进入 vi 后找到disable yes把 yes 改成 no然后按 ESC 输入:wq保存退出。如果不想进交互界面也可以用 sed 直接替换# 把 disable yes 替换成 disable no-i 表示直接写回文件 sed -i s/disable.*.*yes/disable no/ /etc/xinetd.d/telnet注意 sed 的匹配规则是整行替换如果已经有一行是disable no重复执行不会产生副作用这点比手改更稳。改完配置后必须重启 xinetd 才能生效# 重启 xinetd让新配置加载 service xinetd restart # 查看 23 端口是否处于监听状态 netstat -tunlp | grep 23netstat 输出里能看到tcp 0 0 0.0.0.0:23之类的行说明服务已经监听。接下来可以在本机做一次自测telnet localhost如果出现login:提示符说明服务端配置没问题可以进入网络和防火墙的排查环节了。3. 三种虚拟机网络模式host-only / bridge / NAT 的连通条件与验证方法3.1 host-only 模式的配置逻辑宿主机做网关host-only 模式下虚拟机只能和宿主机通信默认上不了外网。它的原理是 VMware 在宿主机上创建了一块虚拟网卡 vmnet1虚拟机的流量全部走这块网卡。要让虚拟机访问外部网络常见做法是把 vmnet1 在宿主机侧设置为共享然后以 vmnet1 的 IP 作为虚拟机的网关。具体配置时先在 Windows 的“网络连接”里找到 vmnet1 对应的网卡右键属性切到“高级”标签勾选 Internet 连接共享共享对象选 vmnet1。然后改虚拟机里的 Linux IP# 假设宿主机 vmnet1 的 IP 是 192.168.0.1 # 把虚拟机 IP 改成 192.168.0.100掩码 255.255.255.0网关指向 vmnet1 ifconfig eth0 192.168.0.100 netmask 255.255.255.0 route add default gw 192.168.0.1route add default gw的意思是添加一条默认路由所有去往非本网段的流量都会交给 192.168.0.1 转发。host-only 最容易犯的错是把虚拟机和宿主机配成不同网段两边都认为自己没走错实际数据包根本出不去。配置完先ping 192.168.0.1通了再继续。3.2 bridge 模式与 NAT 模式两者对 IP 的要求完全不同bridge 模式是把虚拟机模拟成局域网里的一台独立主机虚拟机的 IP、掩码、网关、DNS 都要和宿主机处于同一个网段。比如宿主机 IP 是 192.168.1.18那虚拟机可以配成 192.168.1.252网关指向 192.168.1.1DNS 按局域网实际配置填。这种模式最接近真实网络环境虚拟机和其他机器互访都不受限制。修改 IP 的常规做法是编辑网卡配置文件# RHEL 6 及之前的版本网卡配置文件是 ifcfg-eth0CentOS 7 后叫 ifcfg-ens33 vi /etc/sysconfig/network-scripts/ifcfg-eth0文件里需要保证这几行的值正确BOOTPROTOstatic表示静态 IPIPADDR填规划好的虚拟机 IPNETMASK填 255.255.255.0GATEWAY填局域网网关ONBOOTyes保证开机自动激活网卡。改完执行service network restart生效。bridge 模式下常见的 ping 不通现象十有八九是 IP 和网关不在同一网段或者网关写错。NAT 模式则相反虚拟机是 VMware 虚拟出来的私网地址通常不用手动配 IPDHCP 会自动分配。这种模式下虚拟机访问宿主机通常没问题但宿主机想直接 ping 虚拟机私网地址反而经常不通因为流量走的是 vmnet8 而不是普通网卡路径很多人第一次在 NAT 模式下被这个现象坑到实际上不需要纠结直接测虚拟机到宿主机的连通性即可。3.3 网络连通性验证从本机到网关再到对端不管是哪种模式网络是否打通只能靠实测。我在实际排查时固定用一套顺序不会一上来就 ping 对端# 第一步确认虚拟机网卡是否激活并拿到了 IP ifconfig eth0 # 第二步查看路由表确认默认网关存在 route -n # 第三步先 ping 网关 ping -c 4 192.168.1.1 # 第四步再从宿主机 ping 虚拟机 IP ping 192.168.1.252ping -c 4表示只发 4 个 ICMP 包就结束避免 CtrlC 中断的麻烦。第三步能通说明虚拟机出得去第四步能通说明宿主机进得来。两者都通telnet 连接在网络上就没有障碍了。如果第三步通而第四步不通问题在宿主机侧优先查主机防火墙是否拦了 ICMP如果第三步就不通问题在虚拟机侧回过去查网关和网卡配置。4. iptables 放行 23 端口与 root 登录限制两道最隐蔽的坎4.1 防火墙放行 23 端口从临时 stop 到持久规则网络通了之后telnet 连接大概率会卡在防火墙这一关。CentOS 5、RHEL 5 时代默认的防火墙策略比较严格只放行了 SSH22 端口23 端口默认拒绝。最直接的验证办法是暂时关闭防火墙再试一次# 临时关闭防火墙重启后失效适合快速定位问题 service iptables stop如果关掉防火墙后 telnet 能通说明问题确定在 iptables 规则上这时候再决定是开放端口还是关防火墙。实验室环境临时用可以service iptables stop但重启后规则会回来需要配合chkconfig iptables off才能永久关闭。不过我不建议一上来就关防火墙正确的处理方式是放行 23 端口# -I INPUT 表示把规则插到 INPUT 链最前面-p 指定协议--dport 指定目标端口 iptables -I INPUT -p tcp --dport 23 -j ACCEPT iptables -I INPUT -p udp --dport 23 -j ACCEPT # 保存规则重启 iptables 后仍然有效 service iptables save service iptables restart-j ACCEPT表示匹配到的包直接放行。telnet 服务用的是 TCP 协议其实只放行 TCP 就够了加 UDP 那条是为了避免某些系统里 telnet 相关探测误伤。手改/etc/sysconfig/iptables文件也能达到同样效果但规则链的顺序、链名在不同系统版本里略有差异文件里插错位置会导致规则不生效我在这上面栽过跟头所以更推荐先用命令行插入规则再用service iptables save落盘。4.2 root 登录被拒pam_securetty.so 才是真凶telnet 默认禁止 root 用户直接登录这是初学者最容易误判的一步。明明账号密码都正确连接却被断开错误信息又不够直白。原因是 PAM 认证模块里的pam_securetty.so会检查 root 登录的终端是否被允许而 telnet 对应的伪终端不在默认安全列表里。解决办法有两个。第一个是注释掉/etc/pam.d/login里的对应行# 编辑 PAM 配置文件找到下面这行并在前面加 # 注释 vi /etc/pam.d/login # auth required pam_securetty.so第二个更粗暴直接把/etc/securetty文件改名让 PAM 检查落空# 备份 securetty 文件使 root 登录不受终端限制 mv /etc/securetty /etc/securetty.bak两种方法都能让 root 远程登录进去但我要多说一句telnet 本身是明文传输root 权限一旦被截获风险极大建议不要为了一时方便改掉这个限制。稳妥的做法是用普通用户登录再执行su -切换到 root密码即使被截获也只是普通用户权限风险等级完全不同。以下表格整理了涉及的文件和各自作用文件作用处理方式/etc/pam.d/login登录认证规则注释 pam_securetty.so 行/etc/securetty定义 root 可登录的终端列表改名备份谨慎操作/etc/xinetd.d/telnettelnet 服务开关disable 改为 no/etc/sysconfig/iptables防火墙持久规则加入 23 端口放行4.3 /etc/hosts 与 hosts.allow、hosts.deny访问控制的最后一层防火墙和 PAM 都过了telnet 连接还有可能被/etc/hosts和 TCP Wrapper 拦下来。/etc/hosts文件里如果没有客户机的 IP 映射telnet 连接建立后反向解析主机名就可能失败表现出来就是连上了又被立刻断开错误信息里带着Temporary failure in name resolution。处理方法是在/etc/hosts里追加客户机 IP 和主机名的映射# 把客户机的 IP 和主机名写进 hosts 文件注意不要删掉原有的 localhost 行 echo 192.168.1.88 client1 /etc/hosts另外/etc/hosts.allow和/etc/hosts.deny这两个文件由 TCP Wrapper 机制控制如果 deny 文件里有类似ALL: ALL的规则所有 telnet 连接都会被拒。检查的方式很简单# 查看 deny 文件里有没有非注释规则grep -v ^# 用来过滤掉注释行 grep -v ^# /etc/hosts.deny如果输出为空白说明没有默认拒绝规则如果有内容逐条确认是否覆盖了客户机 IP。这三个文件属于“配置没问题时感觉不到、出了问题又很难想到”的类型每次排查 telnet 我都会顺手看一遍不是玄学是真踩过。5. telnet 排错避坑五个真实故障记录与处理思路5.1 故障一No route to host连接被直接拒绝执行telnet 192.168.1.87后提示No route to host。按字面理解是路由不可达但实际上最常见的原因是宿主机防火墙丢弃了发往 23 端口的包或者虚拟机 IP 与宿主机不在同一网段。处理顺序是先确认两端 IP 是否同网段再检查防火墙规则。同网段的情况下直接service iptables stop临时关闭防火墙测试能通就说明是防火墙拦的回到第 4 章用 iptables 放行 23 端口。这条经验帮我省了很多次来回折腾。5.2 故障二Temporary failure in name resolution连上又被断开telnet 已经显示Connected to紧接着报getnameinfo: localhost: Success和Temporary failure in name resolution: Illegal seek然后连接被关闭。这种表现很容易让人误以为是认证问题实际是/etc/hosts文件缺少客户机 IP 映射导致服务端做反向域名解析时失败。在/etc/hosts中补上客户机的 IP 和主机名即可比如192.168.1.88 client1。这个坑的隐蔽之处在于它只影响有连接建立动作的协议ping 完全正常让人根本想不到是 DNS 解析的问题。从那以后我配任何远程服务都会先确认 hosts 文件。5.3 故障三Windows 端 Telnet 拒绝访问提示不是 TelnetClients 组成员这个故障不在 Linux 侧而是 Windows 的 Telnet 服务有自己的用户组限制。Windows 开启 Telnet 服务后默认只允许 TelnetClients 组的成员登录管理员在服务器上也需要先加入该组否则提示“指定用户不是 TelnetClients 组成员”。另外 Windows 的 Telnet 服务不允许空密码没有设置密码的用户会被直接拒绝。解决方式是在 Windows 的“计算机管理 - 本地用户和组”里把目标用户加入 TelnetClients 组并确保设置了非空密码。这个案例提醒我telnet 排错不要只盯着 Linux 侧两端服务的用户策略都可能成为瓶颈。5.4 故障四手改 iptables 配置文件不生效修改/etc/sysconfig/iptables文件、在末尾加上放行 23 端口的规则后重启 iptablestelnet 仍然不通。反复试了几次都失败最后发现是规则链名与系统版本不匹配旧版本默认链叫RH-Firewall-1-INPUT新版本是INPUT手写规则时用错了链名规则被静默丢弃。解决方式是优先使用命令行工具而非直接编辑文件。iptables -I INPUT -p tcp --dport 23 -j ACCEPT这条命令由内核解析不会出现链名不匹配的问题然后再用service iptables save把规则写入配置文件。如果确实需要手动编辑文件务必先用iptables -L -n查看当前实际使用的链名。5.5 故障五虚拟机网络时好时坏宿主机上的虚拟网卡软件干扰路由宿主机上安装了第三方虚拟网卡类软件后Linux 虚拟机出现无法上网、ping 不通外部地址的现象但虚拟机与宿主机之间的通信又正常。根因是第三方软件在宿主机上创建了新的虚拟网络适配器抢占了默认路由导致虚拟机的流量没有走 VMware 的网卡通道。处理方式是在 Windows 的“网络连接”中找到对应的虚拟网卡适配器并禁用禁掉之后立即恢复。这类问题在虚拟机网络排查中很容易被忽略因为 VMware 自身的网卡配置完全正确问题偏偏出在宿主机侧的第三方设备上。我在处理这类故障时养成了一个习惯先看宿主机当前活跃的网络适配器列表再决定要不要深入排查虚拟机内部配置。6. telnet 通了之后用 SSH 接管远程操作与文件传输telnet 链路打通只是第一步实际使用中我通常只在验证网络和应急场景下用 telnet日常远程操作优先切到 SSH。telnet 的数据包全部明文传输包括用户名和密码在虚拟机和宿主机之间调试还能接受一旦涉及真实服务器就必须换 SSH。在 CentOS 5 这类老系统上启用 SSH 服务的步骤很简单# 查看 sshd 服务在哪些运行级别下启用 chkconfig --list | grep sshd # 如果只在运行级别 3 启用保持即可确保防火墙放行 22 端口 iptables -A INPUT -p tcp --dport 22 -j ACCEPT iptables -A OUTPUT -p tcp --sport 22 -j ACCEPT service iptables save service sshd restart虚拟机网卡建议设为桥接模式这样宿主机和虚拟机处于同一网段SSH 连接更直观。Windows 侧可以使用 SSH Secure Shell Client 这类工具点击 Quick Connect输入虚拟机 IP、用户名端口选择 22Authentication 选 Password点击 Connect 后输入密码即可。也可以用命令行直接验证# 一行命令登录远程主机并执行两个命令注意 IP 换成自己的虚拟机地址 ssh root192.168.1.252 uptime; last -5这种方式适合写脚本做巡检不需要进入交互式 shell。文件传输则用 scp 解决它基于 SSH 通道比 telnet 时代传文件的方式安全得多# 把本地的 tar 包推送到虚拟机的 /root 目录下 scp /tmp/backup.tar.gz root192.168.1.252:/root/关于远程登录的权限策略我的习惯是坚持不开放 root 直连telnet 和 SSH 都只允许普通用户登录需要管理员权限时再 su 切换。telnet 阶段的 root 限制其实是在保护你明文通道加 root 权限是最危险的组合。从那以后我每次配完虚拟机远程登录都强制走一遍端口监听检查、防火墙放行确认、hosts 文件校验、root 登录策略核对这四步telnet 通了再上 SSH顺序不乱问题就好定位。希望这份记录帮你在虚拟机远程登录这条路上少踩几个坑。本文还有配套的精品资源点击获取 telnet远程登录Linux虚拟机：配置、网络模式与防火墙排错实践
简介面向VMware等虚拟机环境下配置Telnet远程登录Linux的参考文档适合刚接触Linux远程管理的初学者及需要快速搭建实验环境的运维人员。文档以Red Hat Linux 9及Red Hat EL 5为例覆盖从检查telnet与telnet-server包、安装RPM包、修改xinetd配置到配置host-only、bridge、NAT三种虚拟机网络模式以及调整防火墙和允许root登录的完整流程。资源为单个PDF文件大小34KB共1个文件内容精炼、步骤清晰便于随时查阅。目前已有150人学习下载可作为Linux远程管理入门时的手边参考尤其能帮助解决“连不上、登录被拒”等常见问题。文档中还对SSH Secure Shell Client连接虚拟机做了简要介绍并整理了telnet-server安装与测试的实操记录适合跟着命令行逐步操作快速获得可复现的排错思路。1. 用 telnet 远程登录虚拟机里的 Linux先理清这条链路上的四个环节刚装完 VMware 的读者十有八九都干过这件事在 Windows 命令行里敲 telnet 加虚拟机 IP结果不是No route to host就是Connection closed by foreign host。我拆完这份 PDF 之后的感受是telnet 远程登录虚拟机下的 Linux 说穿了就四个环节——服务端包装没装、xinetd 启没启、网络通不通、防火墙放没放行 23 端口。这份资料把这四件事从头到尾记了一遍既讲了 host-only、bridge、NAT 三种网络模式的配法也写了 root 登录被禁时的处理办法中间还夹了不少真实翻车记录。适合做课程设计、实验环境以及需要在 Windows 和 Linux 虚拟机之间互传文件的场景。先把这条链路疏通后面再谈更安全的远程工具才有意义。2. 安装 telnet 服务端分清 client 与 server 两个包再激活 xinetd2.1 先分清两个包telnet 是客户端telnet-server 才是服务端很多人在第一步就搞混了。telnet这个 rpm 包是客户端程序用来发起连接真正对外监听 23 端口的是telnet-server。CentOS、Red Hat 系默认通常只装了客户端服务端要单独装所以rpm -qa | grep telnet之后看到telnet-0.17-39.el5这类结果并不代表服务已经能用了必须确认有没有telnet-server那一行。先做检查命令如下# 查询 telnet 相关包是否安装telnet 是客户端telnet-server 是服务端 rpm -qa | grep telnet # 如果只看到 telnet-xxx说明服务端没装如果两条都没有说明客户端也没装这一步的输出决定了后面的动作。只看得到telnet-0.17-39.el5就说明当前机器只具备发起连接的能力不具备被连接的能力需要补装telnet-server。另外需要留意telnet-server 服务在 RHEL 5、CentOS 5 这类系统里是挂在xinetd超级守护进程下面的所以安装顺序上要先有 xinetd再装 telnet-server反过来经常报依赖错误。2.2 三种安装姿势yum 在线装、光盘 RPM 装、装完直接改配置有网络的环境直接走 yum 最省事。CentOS 5.5 实测过下面的命令可以一次拉齐依赖# 先装 xinetd再装 telnet-server注意都切到 root 下执行 yum install -y xinetd yum install -y telnet-server-y参数表示安装过程中的交互提示全部默认 yes脚本化操作时不会卡在确认环节。xinetd 是 telnet 的宿主服务它的职责是监听端口、按请求拉起对应的后台程序所以必须先保证它存在。没有外网的环境就用光盘。常见做法是把安装盘挂载到/mnt/cdr再从光盘里把 rpm 包拷贝出来装# 建立挂载点并把光驱挂上去cdr 目录可以自己命名 mkdir -p /mnt/cdr mount /dev/cdrom /mnt/cdr # 进入光盘目录按名字找出 telnet 相关安装包 cd /mnt/cdr find . -name telnet* # 把找到的 rpm 包拷到根目录下自建的目录里方便统一安装 cp telnet-server-0.17-39.el5.i386.rpm /keith/ cd /keith rpm -ivh telnet-server-0.17-39.el5.i386.rpmrpm -ivh里的 i 是 installv 是显示详细信息h 是打印进度条。如果这里报依赖缺失基本就是没先装 xinetd把 xinetd 的 rpm 也用同样的方式装一遍再回头装 telnet-server 即可。装完之后可以用rpm -qa telnet-server验证能回显版本号就说明安装成功。2.3 修改 telnet 配置并重启 xinetdtelnet-server 装好之后/etc/xinetd.d/telnet这个配置文件才会出现。文件里默认有一行disable yes意思是服务处于禁用状态需要改成no# 编辑 telnet 的 xinetd 配置 vi /etc/xinetd.d/telnet进入 vi 后找到disable yes把 yes 改成 no然后按 ESC 输入:wq保存退出。如果不想进交互界面也可以用 sed 直接替换# 把 disable yes 替换成 disable no-i 表示直接写回文件 sed -i s/disable.*.*yes/disable no/ /etc/xinetd.d/telnet注意 sed 的匹配规则是整行替换如果已经有一行是disable no重复执行不会产生副作用这点比手改更稳。改完配置后必须重启 xinetd 才能生效# 重启 xinetd让新配置加载 service xinetd restart # 查看 23 端口是否处于监听状态 netstat -tunlp | grep 23netstat 输出里能看到tcp 0 0 0.0.0.0:23之类的行说明服务已经监听。接下来可以在本机做一次自测telnet localhost如果出现login:提示符说明服务端配置没问题可以进入网络和防火墙的排查环节了。3. 三种虚拟机网络模式host-only / bridge / NAT 的连通条件与验证方法3.1 host-only 模式的配置逻辑宿主机做网关host-only 模式下虚拟机只能和宿主机通信默认上不了外网。它的原理是 VMware 在宿主机上创建了一块虚拟网卡 vmnet1虚拟机的流量全部走这块网卡。要让虚拟机访问外部网络常见做法是把 vmnet1 在宿主机侧设置为共享然后以 vmnet1 的 IP 作为虚拟机的网关。具体配置时先在 Windows 的“网络连接”里找到 vmnet1 对应的网卡右键属性切到“高级”标签勾选 Internet 连接共享共享对象选 vmnet1。然后改虚拟机里的 Linux IP# 假设宿主机 vmnet1 的 IP 是 192.168.0.1 # 把虚拟机 IP 改成 192.168.0.100掩码 255.255.255.0网关指向 vmnet1 ifconfig eth0 192.168.0.100 netmask 255.255.255.0 route add default gw 192.168.0.1route add default gw的意思是添加一条默认路由所有去往非本网段的流量都会交给 192.168.0.1 转发。host-only 最容易犯的错是把虚拟机和宿主机配成不同网段两边都认为自己没走错实际数据包根本出不去。配置完先ping 192.168.0.1通了再继续。3.2 bridge 模式与 NAT 模式两者对 IP 的要求完全不同bridge 模式是把虚拟机模拟成局域网里的一台独立主机虚拟机的 IP、掩码、网关、DNS 都要和宿主机处于同一个网段。比如宿主机 IP 是 192.168.1.18那虚拟机可以配成 192.168.1.252网关指向 192.168.1.1DNS 按局域网实际配置填。这种模式最接近真实网络环境虚拟机和其他机器互访都不受限制。修改 IP 的常规做法是编辑网卡配置文件# RHEL 6 及之前的版本网卡配置文件是 ifcfg-eth0CentOS 7 后叫 ifcfg-ens33 vi /etc/sysconfig/network-scripts/ifcfg-eth0文件里需要保证这几行的值正确BOOTPROTOstatic表示静态 IPIPADDR填规划好的虚拟机 IPNETMASK填 255.255.255.0GATEWAY填局域网网关ONBOOTyes保证开机自动激活网卡。改完执行service network restart生效。bridge 模式下常见的 ping 不通现象十有八九是 IP 和网关不在同一网段或者网关写错。NAT 模式则相反虚拟机是 VMware 虚拟出来的私网地址通常不用手动配 IPDHCP 会自动分配。这种模式下虚拟机访问宿主机通常没问题但宿主机想直接 ping 虚拟机私网地址反而经常不通因为流量走的是 vmnet8 而不是普通网卡路径很多人第一次在 NAT 模式下被这个现象坑到实际上不需要纠结直接测虚拟机到宿主机的连通性即可。3.3 网络连通性验证从本机到网关再到对端不管是哪种模式网络是否打通只能靠实测。我在实际排查时固定用一套顺序不会一上来就 ping 对端# 第一步确认虚拟机网卡是否激活并拿到了 IP ifconfig eth0 # 第二步查看路由表确认默认网关存在 route -n # 第三步先 ping 网关 ping -c 4 192.168.1.1 # 第四步再从宿主机 ping 虚拟机 IP ping 192.168.1.252ping -c 4表示只发 4 个 ICMP 包就结束避免 CtrlC 中断的麻烦。第三步能通说明虚拟机出得去第四步能通说明宿主机进得来。两者都通telnet 连接在网络上就没有障碍了。如果第三步通而第四步不通问题在宿主机侧优先查主机防火墙是否拦了 ICMP如果第三步就不通问题在虚拟机侧回过去查网关和网卡配置。4. iptables 放行 23 端口与 root 登录限制两道最隐蔽的坎4.1 防火墙放行 23 端口从临时 stop 到持久规则网络通了之后telnet 连接大概率会卡在防火墙这一关。CentOS 5、RHEL 5 时代默认的防火墙策略比较严格只放行了 SSH22 端口23 端口默认拒绝。最直接的验证办法是暂时关闭防火墙再试一次# 临时关闭防火墙重启后失效适合快速定位问题 service iptables stop如果关掉防火墙后 telnet 能通说明问题确定在 iptables 规则上这时候再决定是开放端口还是关防火墙。实验室环境临时用可以service iptables stop但重启后规则会回来需要配合chkconfig iptables off才能永久关闭。不过我不建议一上来就关防火墙正确的处理方式是放行 23 端口# -I INPUT 表示把规则插到 INPUT 链最前面-p 指定协议--dport 指定目标端口 iptables -I INPUT -p tcp --dport 23 -j ACCEPT iptables -I INPUT -p udp --dport 23 -j ACCEPT # 保存规则重启 iptables 后仍然有效 service iptables save service iptables restart-j ACCEPT表示匹配到的包直接放行。telnet 服务用的是 TCP 协议其实只放行 TCP 就够了加 UDP 那条是为了避免某些系统里 telnet 相关探测误伤。手改/etc/sysconfig/iptables文件也能达到同样效果但规则链的顺序、链名在不同系统版本里略有差异文件里插错位置会导致规则不生效我在这上面栽过跟头所以更推荐先用命令行插入规则再用service iptables save落盘。4.2 root 登录被拒pam_securetty.so 才是真凶telnet 默认禁止 root 用户直接登录这是初学者最容易误判的一步。明明账号密码都正确连接却被断开错误信息又不够直白。原因是 PAM 认证模块里的pam_securetty.so会检查 root 登录的终端是否被允许而 telnet 对应的伪终端不在默认安全列表里。解决办法有两个。第一个是注释掉/etc/pam.d/login里的对应行# 编辑 PAM 配置文件找到下面这行并在前面加 # 注释 vi /etc/pam.d/login # auth required pam_securetty.so第二个更粗暴直接把/etc/securetty文件改名让 PAM 检查落空# 备份 securetty 文件使 root 登录不受终端限制 mv /etc/securetty /etc/securetty.bak两种方法都能让 root 远程登录进去但我要多说一句telnet 本身是明文传输root 权限一旦被截获风险极大建议不要为了一时方便改掉这个限制。稳妥的做法是用普通用户登录再执行su -切换到 root密码即使被截获也只是普通用户权限风险等级完全不同。以下表格整理了涉及的文件和各自作用文件作用处理方式/etc/pam.d/login登录认证规则注释 pam_securetty.so 行/etc/securetty定义 root 可登录的终端列表改名备份谨慎操作/etc/xinetd.d/telnettelnet 服务开关disable 改为 no/etc/sysconfig/iptables防火墙持久规则加入 23 端口放行4.3 /etc/hosts 与 hosts.allow、hosts.deny访问控制的最后一层防火墙和 PAM 都过了telnet 连接还有可能被/etc/hosts和 TCP Wrapper 拦下来。/etc/hosts文件里如果没有客户机的 IP 映射telnet 连接建立后反向解析主机名就可能失败表现出来就是连上了又被立刻断开错误信息里带着Temporary failure in name resolution。处理方法是在/etc/hosts里追加客户机 IP 和主机名的映射# 把客户机的 IP 和主机名写进 hosts 文件注意不要删掉原有的 localhost 行 echo 192.168.1.88 client1 /etc/hosts另外/etc/hosts.allow和/etc/hosts.deny这两个文件由 TCP Wrapper 机制控制如果 deny 文件里有类似ALL: ALL的规则所有 telnet 连接都会被拒。检查的方式很简单# 查看 deny 文件里有没有非注释规则grep -v ^# 用来过滤掉注释行 grep -v ^# /etc/hosts.deny如果输出为空白说明没有默认拒绝规则如果有内容逐条确认是否覆盖了客户机 IP。这三个文件属于“配置没问题时感觉不到、出了问题又很难想到”的类型每次排查 telnet 我都会顺手看一遍不是玄学是真踩过。5. telnet 排错避坑五个真实故障记录与处理思路5.1 故障一No route to host连接被直接拒绝执行telnet 192.168.1.87后提示No route to host。按字面理解是路由不可达但实际上最常见的原因是宿主机防火墙丢弃了发往 23 端口的包或者虚拟机 IP 与宿主机不在同一网段。处理顺序是先确认两端 IP 是否同网段再检查防火墙规则。同网段的情况下直接service iptables stop临时关闭防火墙测试能通就说明是防火墙拦的回到第 4 章用 iptables 放行 23 端口。这条经验帮我省了很多次来回折腾。5.2 故障二Temporary failure in name resolution连上又被断开telnet 已经显示Connected to紧接着报getnameinfo: localhost: Success和Temporary failure in name resolution: Illegal seek然后连接被关闭。这种表现很容易让人误以为是认证问题实际是/etc/hosts文件缺少客户机 IP 映射导致服务端做反向域名解析时失败。在/etc/hosts中补上客户机的 IP 和主机名即可比如192.168.1.88 client1。这个坑的隐蔽之处在于它只影响有连接建立动作的协议ping 完全正常让人根本想不到是 DNS 解析的问题。从那以后我配任何远程服务都会先确认 hosts 文件。5.3 故障三Windows 端 Telnet 拒绝访问提示不是 TelnetClients 组成员这个故障不在 Linux 侧而是 Windows 的 Telnet 服务有自己的用户组限制。Windows 开启 Telnet 服务后默认只允许 TelnetClients 组的成员登录管理员在服务器上也需要先加入该组否则提示“指定用户不是 TelnetClients 组成员”。另外 Windows 的 Telnet 服务不允许空密码没有设置密码的用户会被直接拒绝。解决方式是在 Windows 的“计算机管理 - 本地用户和组”里把目标用户加入 TelnetClients 组并确保设置了非空密码。这个案例提醒我telnet 排错不要只盯着 Linux 侧两端服务的用户策略都可能成为瓶颈。5.4 故障四手改 iptables 配置文件不生效修改/etc/sysconfig/iptables文件、在末尾加上放行 23 端口的规则后重启 iptablestelnet 仍然不通。反复试了几次都失败最后发现是规则链名与系统版本不匹配旧版本默认链叫RH-Firewall-1-INPUT新版本是INPUT手写规则时用错了链名规则被静默丢弃。解决方式是优先使用命令行工具而非直接编辑文件。iptables -I INPUT -p tcp --dport 23 -j ACCEPT这条命令由内核解析不会出现链名不匹配的问题然后再用service iptables save把规则写入配置文件。如果确实需要手动编辑文件务必先用iptables -L -n查看当前实际使用的链名。5.5 故障五虚拟机网络时好时坏宿主机上的虚拟网卡软件干扰路由宿主机上安装了第三方虚拟网卡类软件后Linux 虚拟机出现无法上网、ping 不通外部地址的现象但虚拟机与宿主机之间的通信又正常。根因是第三方软件在宿主机上创建了新的虚拟网络适配器抢占了默认路由导致虚拟机的流量没有走 VMware 的网卡通道。处理方式是在 Windows 的“网络连接”中找到对应的虚拟网卡适配器并禁用禁掉之后立即恢复。这类问题在虚拟机网络排查中很容易被忽略因为 VMware 自身的网卡配置完全正确问题偏偏出在宿主机侧的第三方设备上。我在处理这类故障时养成了一个习惯先看宿主机当前活跃的网络适配器列表再决定要不要深入排查虚拟机内部配置。6. telnet 通了之后用 SSH 接管远程操作与文件传输telnet 链路打通只是第一步实际使用中我通常只在验证网络和应急场景下用 telnet日常远程操作优先切到 SSH。telnet 的数据包全部明文传输包括用户名和密码在虚拟机和宿主机之间调试还能接受一旦涉及真实服务器就必须换 SSH。在 CentOS 5 这类老系统上启用 SSH 服务的步骤很简单# 查看 sshd 服务在哪些运行级别下启用 chkconfig --list | grep sshd # 如果只在运行级别 3 启用保持即可确保防火墙放行 22 端口 iptables -A INPUT -p tcp --dport 22 -j ACCEPT iptables -A OUTPUT -p tcp --sport 22 -j ACCEPT service iptables save service sshd restart虚拟机网卡建议设为桥接模式这样宿主机和虚拟机处于同一网段SSH 连接更直观。Windows 侧可以使用 SSH Secure Shell Client 这类工具点击 Quick Connect输入虚拟机 IP、用户名端口选择 22Authentication 选 Password点击 Connect 后输入密码即可。也可以用命令行直接验证# 一行命令登录远程主机并执行两个命令注意 IP 换成自己的虚拟机地址 ssh root192.168.1.252 uptime; last -5这种方式适合写脚本做巡检不需要进入交互式 shell。文件传输则用 scp 解决它基于 SSH 通道比 telnet 时代传文件的方式安全得多# 把本地的 tar 包推送到虚拟机的 /root 目录下 scp /tmp/backup.tar.gz root192.168.1.252:/root/关于远程登录的权限策略我的习惯是坚持不开放 root 直连telnet 和 SSH 都只允许普通用户登录需要管理员权限时再 su 切换。telnet 阶段的 root 限制其实是在保护你明文通道加 root 权限是最危险的组合。从那以后我每次配完虚拟机远程登录都强制走一遍端口监听检查、防火墙放行确认、hosts 文件校验、root 登录策略核对这四步telnet 通了再上 SSH顺序不乱问题就好定位。希望这份记录帮你在虚拟机远程登录这条路上少踩几个坑。本文还有配套的精品资源点击获取