Telnet on purpose, and the credential leak that proved the split mattered

The decision to keep telnet was explicit and, on its own terms, sound. These cards’ SSH offering was not meaningfully better than cleartext: old ciphers, or a host key type modern clients refuse outright, on firmware that will never be updated again. The PDUs on the same segment have no SSH option at all. The real boundary was an isolated management network plus per-device access control, not the wire protocol. That reasoning still holds.

What it did not anticipate showed up a fortnight later. Rolling SNMPv3 out across the power hardware, it was convenient to use one credential set for everything that draws power in the rack. The UPS network cards speak SSH. The transfer switches and PDUs speak telnet. Using the same SNMPv3 secret on both meant that every time it was configured or verified on a telnet device, a credential built for a protected transport travelled the wire in clear text.

The insight worth keeping is a property statement: “acceptable to send in clear” belongs to the credential, not to the device you happen to be using it on today. A secret’s protection level has to match its weakest intended transport, and the moment one secret spans two transports, the weaker one sets the level for both.

The fix is cheap if you do it before the rollout rather than after. Define credential classes by transport, give them names that make the class obvious at a glance in your secrets store, and never let a member of one class cross into the other’s territory. Node0 rotated the exposed secret the day the overlap was found, which is the only other part of this that has to happen quickly.