还有一批设备只认 Telnet，自动化平台怎么接

结论先行：自动化平台接不进某台设备，多数时候不是品牌适配的问题，而是通道的问题。同一批资产里，SSH、Telnet、API 三种接入方式的可靠性与可做动作完全不同：SSH 能拿回显也能下发，Telnet 明文且易断，API 常常只读。纳管设计的起点应当是把资产按通道分类，而不是按品牌分类。

本文只谈存量设备通过哪条通道接进平台、各条通道能做与不能做什么，不谈平台上线之后策略怎么开通，也不谈品牌适配开发怎么报价。

三种通道，三种天花板

按品牌分类看不出这三条通道的差别，因为同一个品牌的不同代设备可能分别落在三条通道上。真正决定自动化能走多远的，是某条通道上到底有多少台设备、这些设备能不能写。

只认 Telnet 的那批设备，四个必须正视的问题

其一，口令是明文。Telnet 会话在网络上没有任何加密，账号口令会以可读形式经过中间的每一个环节。只要有一台设备的登录口令走的是这条通道，整个管理的账号体系就存在被旁听的可能。

其二，会话容易被意外中断。网络抖动、设备侧空闲超时、并发会话数上限，都会让一条正在执行的命令中途断掉。断在一个配置写了一半的位置，比没执行更麻烦。

其三，回显格式不统一。同一款设备的两个固件版本，分页提示、提示符、错误信息都可能不一样。解析规则要按固件版本分别维护，而不是按型号。

其四，很多老设备不支持并行。一次只能开一个管理会话，意味着批量操作只能串行，一次大批量任务的时间会被单台设备的会话排队拉长。

把风险关进三个约束里

这四条都消不掉，只能用约束把影响范围压小。

• 其一，跳板收口。所有 Telnet 会话从固定的管理网段发起，设备侧只允许这个网段登录。入口收敛之后，可被旁听的位置从「全网」缩到「一段」。平台侧不做例外放行。
• 其二，专用账号。给平台单独开一个账号，权限只覆盖需要自动化的命令集，不用日常运维账号，也不给配置级全权。这样即便某次会话出了问题，影响面也是可数的。
• 其三，会话全程留痕。每条命令、每次登录都记下来，落在平台自己的审计日志里，并同步到统一的日志平台。老设备本身往往不留痕，留痕只能由平台侧补。

顺带说一句：如果某个网段里只剩下少量 Telnet 设备，还值得评估一次设备替换的时机。用旧协议管理少量设备，成本不在授权，而在每一次故障排查都要多绕几层。

API 通道的两种形态要分开对待

API 看起来比命令行干净，但要把只读与可写分开。只读接口适合做盘点、做状态采集、做配置比对；可写接口才涉及变更。多数项目在起步阶段只接只读，把「看得见」做扎实，再逐步开放写操作。

开放写操作之前，至少要确认三件事：接口是否有幂等性、失败返回是否有明确错误码、以及变更之后能否回读校验。第三件最容易被忽略——下发成功不等于生效，没有回读校验，平台就只是把命令发出去了。

验收时怎么核这三件事

深圳市奇摩计算机有限公司在这类现场做的是服务端的活：先把三条通道各覆盖多少台盘清楚，再确定哪一批先接、哪一批只能读。支持 SSH、Telnet 与 API 三类管理通道是纳管的前提，具体到某个网络里各占多少，要以现场盘点结果为准。

边界与前提

其一，本文讨论的是管理通道这一层，不涉及设备侧的性能与容量。通道能通，不代表设备扛得住高频操作。

其二，Telnet 的三条约束能压小风险，但改变不了明文传输这个事实。对安全等级要求高的网络，正确做法是替换设备或增加一层加密代理，而不是接受明文长期存在。

其三，本文提到的通道能力为通用情况，具体设备的接口与权限以厂商文档和现场实测为准。可写接口的开放范围需要与设备负责人逐台确认。

落地清单

• 按通道给资产分类，不按品牌分类。
• 标出每条通道的台数与可写性，形成一张纳管地图。
• Telnet 设备执行三条约束：跳板收口、专用账号、会话留痕。
• API 先接只读，可写接口逐台确认，且必须做回读校验。
• 验收时按覆盖率、可写范围、留痕完整性三项逐条核。
• 只剩少量 Telnet 设备的网段，评估替换时机。

自动化的上限不取决于平台功能列表有多长，取决于最后那批接不进来的设备怎么处理。如果你正在盘存量的纳管通道，预约咨询，我们从一张通道清单开始对。