According to JSA10734:

“Since version 5.4 (released on March 8, 2010), the OpenSSH client supports an undocumented feature called Roaming. If the connection to an SSH server breaks unexpectedly, and if the server supports roaming as well, the client is able to reconnect to the server and resume the suspended SSH session.

Although roaming is not supported by the OpenSSH server, it is enabled by default in the OpenSSH client, and contains two vulnerabilities that can be exploited by a malicious SSH server (or a trusted but compromised server): an information leak (memory disclosure), and a buffer overflow (heap-based).”

This article discusses workarounds for MX and EX platforms apart from the fix in PR1154016.

The information leak is exploitable in the default configuration of the OpenSSH client, and (depending on the client's version, compiler, and operating system) allows a malicious SSH server to steal the client's private keys. This information leak may have already been exploited in the wild by sophisticated attackers, and high-profile sites or users may need to regenerate their SSH keys accordingly.

All OpenSSH versions between 5.4 and 7.1 are vulnerable, but can be easily hot-fixed by setting the undocumented option ‘UseRoaming’ to ‘no’, as detailed in the Mitigating Factors section. OpenSSH version 7.1p2 (released on January 14, 2016) disables roaming by default.

Workaround for MX platform

OpenSSH roaming can be disabled manually as follows:

1. Disable the use of Roaming in ssh_config.
   Note: ssh_config contents are overwritten on boot. Instead, we should make use of .sys file.
   
   sh -c "echo -e 'Host *\nUseRoaming no' >> /etc/ssh_config.sys"


2. Perform commit full:
   
   user@junos> configure
   
   Entering configuration mode
   
   [edit]
user@junos# commit full
commit complete

user@junos> quit


3. Ensure the changes to ssh_config.sys are propagated to /var/etc/ssh_config:
   
   root@junos% cat /var/etc/ssh_config
Host *
UseRoaming no
   
   Note: It is good security practice to connect only to known, trusted, SSH servers from critical infrastructure networking equipment. Use outgoing access lists or egress firewall filters to limit access from sensitive network devices to only trusted administrative networks or hosts.

Workaround for EX platform