SSH Protocol Version 1 Session Key Retrieval: How to Disable SSHv1

SSH Protocol Version 1 Session Key Retrieval (Nessus plugin 10882) means an SSH server still accepts the obsolete SSHv1 protocol, whose cryptographic flaws can expose or alter session traffic. Fix it by allowing SSHv2 only: on Cisco IOS, generate a 2048-bit RSA key and set ip ssh version 2; on OpenSSH, upgrade or set Protocol 2.

What the scanner is actually detecting

This is a remote, unauthenticated check. Nessus does not log in; it looks at which SSH protocol versions the service on that port is willing to speak.

An SSH server announces its protocol version in the first line it sends. SSH-2.0- means SSHv2 only. SSH-1.5- (or 1.33) means SSHv1 only. The case you will see most often is SSH-1.99-: RFC 4253 section 5.1 defines 1.99 as the identifier of a server running in compatibility mode, accepting both SSHv2 and the old protocol. That still triggers the finding, because a client that asks for SSHv1 will get it.

Typical sources are Cisco IOS and IOS XE devices where ip ssh version was never set, embedded appliances with an old SSH stack, and servers running OpenSSH releases older than 7.4.

Real-world risk

SSHv1 has design flaws published in 2001 that were never fixed in the protocol itself. The CVEs Tenable attaches describe them:

• CVE-2001-0361: SSH 1.5 implementations, in certain configurations, let a remote attacker decrypt or alter traffic through a Bleichenbacher attack on PKCS#1 v1.5. This is the “session key retrieval” in the title.
• CVE-2001-1473: a malicious SSH-1 server can replay a client’s challenge response to another server by creating a matching session ID with a weaker key pair, then masquerade as the target.
• CVE-2001-0572: traffic analysis weaknesses (password lengths, shell command lengths) in SSH implementations of that era.

Keep it in proportion. These attacks need the attacker on the network path, or a client connecting to a hostile server, and the Bleichenbacher approach needs many connections. Clients matter too: OpenSSH removed client-side SSHv1 in version 7.6, so a modern admin workstation negotiates SSHv2 even with a 1.99 server, and a downgrade only works when the client still speaks SSHv1. The real exposure is legacy clients and scripts that still use v1, plus the fact that a device offering it is usually old and under-maintained in other ways. Treat it as a hardening item with a clear fix, prioritizing devices reachable from untrusted networks.

How to confirm it on the host

From another machine, read the identification string directly:

nc -w 5 <host> 22
# SSH-1.99-... or SSH-1.5-...  = SSHv1 accepted
# SSH-2.0-...                  = SSHv2 only

A verbose OpenSSH client prints the same thing, and Nmap’s sshv1 NSE script reports Server supports SSHv1 when protocol 1 is accepted:

ssh -v -o BatchMode=yes <host> exit 2>&1 | grep "Remote protocol version"
nmap -Pn -p22 --script sshv1 <host>

If the report lists a non-standard port, use that port instead. On Cisco IOS or IOS XE:

show ip ssh
show crypto key mypubkey rsa
show running-config | include ip ssh

SSH Enabled – version 1.99 means compatibility mode; version 2.0 means SSHv2 only. On a Linux or Unix server, check the OpenSSH package and any explicit Protocol line:

rpm -q openssh-server          # RHEL family
dpkg -l openssh-server         # Debian/Ubuntu
grep -nE '^[[:space:]]*Protocol' /etc/ssh/sshd_config

OpenSSH 7.4 removed server support for SSHv1, so a server at 7.4 or later cannot produce this finding by itself.

How to fix it

The goal everywhere is SSHv2 only, with a proper host key. On network devices, keep console or out-of-band access available while you work.

Cisco IOS and IOS XE

Cisco’s IOS XE configuration guides state that if ip ssh version is not configured, SSH runs in compatibility mode and honors both versions, so pin it explicitly. Cisco’s SSH guide recommends the strongest RSA modulus the platform supports: 2048 bits or higher, and 4096 where supported and the performance impact is acceptable. Key generation needs a hostname and a domain name.

As a safety net, schedule a reload that reverts to the saved configuration if you lock yourself out (do this in a maintenance window, since the device reboots if you forget to cancel):

reload in 15

Then configure SSH. Skip the key step if show crypto key mypubkey rsa already shows a key of 2048 bits or more, because regenerating it changes the host key fingerprint:

configure terminal
 hostname R1
 ip domain name example.local
 crypto key generate rsa modulus 2048
 ip ssh version 2
 end

Older releases spell the domain command ip domain-name. Open a new SSH session from a second terminal, confirm show ip ssh reports version 2.0, then cancel the reload and save:

reload cancel
copy running-config startup-config

Legacy OpenSSH on Linux and Unix

The durable fix is to upgrade. OpenSSH 5.4 disabled protocol 1 by default, 7.0 disabled it at compile time by default, and 7.4 removed server support entirely. A host still shipping an older OpenSSH usually needs an OS upgrade anyway.

Until then, pin the server to protocol 2. Back up the file, then make sure /etc/ssh/sshd_config has exactly one Protocol line with the value 2, replacing any Protocol 1, 2,1 or 1,2 (the old man page notes that 2,1 and 1,2 are identical). Builds older than 5.4 included protocol 1 by default, so add the line even if none exists:

cp -p /etc/ssh/sshd_config /etc/ssh/sshd_config.bak
# edit /etc/ssh/sshd_config so it contains:
Protocol 2

You can also remove any HostKey /etc/ssh/ssh_host_key line, since that file is the protocol 1 host key. Test the syntax and restart while keeping your current session open:

/usr/sbin/sshd -t
service sshd restart        # RHEL/CentOS family
service ssh restart         # older Debian and Ubuntu

Log in from a second terminal before closing the original session.

Network appliances and embedded devices

Firewalls, storage controllers, UPS and PDU cards, printers and industrial gear usually expose the SSH version as a management setting. Find the SSH or remote access settings and select SSHv2 only; menu names differ by vendor, so follow that vendor’s hardening guide. If the firmware cannot disable SSHv1, update it, or restrict management access to a dedicated management network and record a documented exception. Before rescanning these devices, read our notes on scanning fragile OT devices so the verification scan does not cause an outage of its own.

How to verify the fix and rescan

1. Run nc -w 5 <host> 22 again. The first line must start with SSH-2.0-.
2. Run nmap -Pn -p22 –script sshv1 <host>. The Server supports SSHv1 line should be gone.
3. On Cisco, show ip ssh should report version 2.0, and the saved config should contain ip ssh version 2.
4. Log in with the accounts and tools your team actually uses, including backup and configuration collectors.
5. Rescan with the same Nessus scanner and policy, covering any non-standard SSH port from the report.

What can break and how to roll back

• SSHv1-only clients: very old terminal emulators, network management systems, config backup tools and embedded clients may only speak SSHv1 and will fail to connect. Update or replace them rather than re-enabling v1.
• Host key change: regenerating the RSA key on a Cisco device triggers “host identification has changed” warnings. Remove the old entry with ssh-keygen -R <host> and update automation that pins host keys.
• Lockout: a missing key, missing domain name or broken login method can leave you with console access only. The scheduled reload in protects you on IOS; on Linux, the open second session does.

To roll back on Cisco IOS, no ip ssh version returns the device to its default (compatibility mode on releases that behave as Cisco’s guide describes). On OpenSSH, restore sshd_config.bak and restart the daemon. Treat any rollback as temporary while you fix the client that needed SSHv1.

Common false positive reasons

Because the check reads what the server offers, it is rarely wrong about the service that answered. Apparent false positives are usually one of these:

• A different device answered. NAT, a port forward or a load balancer sent the scanner to an older box behind the reported address.
• A second SSH listener. Another SSH service on a different port, often a vendor management daemon, still offers v1. Check the port in the report.
• Stale result. The report predates the change, the device rebooted before the config was saved, or sshd was not restarted.
• Reading config instead of behavior. Current OpenSSH releases accept and ignore a leftover Protocol line, and a Cisco running config may not show every default. Trust the banner and show ip ssh.

FAQ

Does “version 1.99” mean the server is using SSHv1?

No. It means compatibility mode: a client that speaks 2.0 uses SSHv2. It is still flagged because a client that asks for SSHv1 will get it.

Is ip ssh version 2 enough on a Cisco switch?

For this finding, yes, provided the device has a suitable RSA key. Confirm that show ip ssh reports version 2.0 and save the configuration.

Do I need to change anything on a current Ubuntu or RHEL server?

No. OpenSSH 7.4 and later have no SSHv1 server code. If plugin 10882 fires against such a host, find out which service actually answered on that port.

What RSA key size should I use?

Cisco recommends 2048 bits or higher when the platform supports it, and 4096 where supported and the performance impact is acceptable.

Tracking this finding across many hosts

SSHv1 findings tend to cluster on old switches, routers and appliances that sit outside normal patching. SITEY can launch Nessus scans directly or import .nessus exports you upload, and because plugin 10882 is a Nessus finding, it can re-test that individual finding after a change to confirm closure. For Linux servers running its agent, it can also draft a host-specific fix that runs only after human approval.

Sources

• Tenable: SSH Protocol Version 1 Session Key Retrieval (plugin 10882)
• Cisco: Configure SSH on Routers and Switches
• Cisco: Security Configuration Guide, IOS XE 17.15.x (Catalyst 9300), Secure Shell Version 2 Support
• RFC 4253: The SSH Transport Layer Protocol, section 5.1
• OpenSSH 7.4 release notes (server support for SSH v.1 removed)