Network Security

CiscoSSH Stack SCP Issues on ASA 9.19+: The Fix

Upgraded your ASA to 9.19 or later. Tried to copy a config backup to your SCP server. Failed. Worked fine before the upgrade. Now you're staring at cryptic error messages wondering what changed.

This is the CiscoSSH stack. It has a behavior change that Cisco buried in the release notes, and it breaks SCP for everyone who missed it.

The Symptoms

You run a copy command to an SCP server:

copy running-config scp://user@192.0.2.100/backups/asa-config.txt

Instead of prompting for a password and completing, you get:

ssh client failed to register with lina lost connection Error: Upload failed

If you enable debug ssh, you'll see more detail:

SSH_EXT: No matching flow found SSH_EXT: Failed to get vPifNum SSH_EXT: Failed to register external sshd

The ASA is trying to initiate an SSH connection to your SCP server but failing to register the connection internally. This worked on 9.18 and earlier.

Root Cause

ASA 9.19 made CiscoSSH the default SSH stack. The legacy SSH stack still existed as a fallback, but CiscoSSH introduced a breaking change for SCP operations.

The documentation buries this requirement:

"To use the ASA copy command to copy a file to or from an SCP server, you have to: (CiscoSSH stack only) Enable SSH access on the ASA for the SCP server subnet/host using the ssh command."

In other words: the ASA now requires that your SCP server's IP address be permitted in the ssh configuration—even though the ASA is the one initiating the outbound connection, not receiving one.

Why? The CiscoSSH stack uses the ssh ACL to validate both inbound and outbound SSH-based connections. Without an entry for your SCP server, the stack refuses to establish the connection.

No Fallback Option

The ssh stack ciscossh disable command was deprecated and removed in 9.24. You cannot switch back to the legacy SSH stack. The fix below is the only path forward.

The Fix

Add your SCP server to the ssh allowed hosts on the interface the ASA will source from:

ssh 192.0.2.100 255.255.255.255 management

For IPv6:

ssh 2001:db8::100/128 management

Replace management with whichever interface has routing to your SCP server. The ASA sources SCP connections from the management interface by default.

Now your copy command will work:

copy running-config scp://user@192.0.2.100/backups/asa-config.txt Address or name of remote host [192.0.2.100]? Source filename [running-config]? Destination username [user]? Destination password: ******** ! 12345 bytes copied in 1.230 secs (12345 bytes/sec)

Security Consideration

Adding the SCP server to ssh doesn't let that server SSH into your ASA. It just permits the ASA to make outbound SSH/SCP connections to that host. You still need authentication credentials.

Additional Notes

Interface in Copy Command Is Ignored

You might try specifying an interface in the copy command:

copy /noconfirm OUTSIDE scp://user@192.0.2.100/backups/

CiscoSSH ignores this. It sources from management regardless of what you specify. Ensure routing exists from your management interface to the SCP server.

Strengthen SSH Ciphers

While you're touching SSH configuration, consider tightening cipher settings:

ssh cipher encryption high

This disables weak ciphers like 3DES and restricts to modern algorithms.

Bulk Server Configuration

If you have multiple SCP/backup servers, you can use a subnet:

ssh 192.0.2.0 255.255.255.0 management

Or add multiple specific hosts:

ssh 192.0.2.100 255.255.255.255 management ssh 192.0.2.101 255.255.255.255 management ssh 10.0.0.50 255.255.255.255 inside

References

We hit this on three customer ASAs during the same maintenance window. Added it to our pre-upgrade checklist: before any ASA upgrade past 9.18, add all SCP/backup server IPs to ssh. Two minutes of prep versus an hour of "why did backups stop working."

Managing Network Infrastructure?

We run managed WAN services across Europe. SD-WAN, site-to-site VPN, and network automation on our own backbone.