Moving configurations and images securely with SFTP and SCP

Why this matters

A network device holds two kinds of file that someone must move on and off it: its configuration, and the software image it boots. A network technician backs up configurations before every change, restores one when a change goes wrong, and copies new images onto routers and switches when a security advisory says to upgrade. For years the usual tool was TFTP, because it is simple and every device supports it. TFTP has no login and no encryption, so anyone on the path can read a configuration full of password hashes, SNMP strings and VPN keys, and anyone on the network can push a file to the server.

SCP and SFTP do the same job inside an SSH session. Auditors now ask for them by name, and many firewalls between the management network and the devices allow SSH and nothing else. Getting them to work needs a few prerequisites that are easy to miss, and getting the copy command backwards can overwrite the thing you meant to save. This lesson covers the setup, the copy syntax, checking an image, and making the device boot from it.

The lesson

Backing up configurations and moving images with SFTP and SCP

Three file transfer protocols matter here, and they differ in exactly the ways the exam probes:

SCP (Secure Copy Protocol) and SFTP (SSH File Transfer Protocol) both run inside SSH, so both use TCP port 22, both require the user to authenticate, and both encrypt the whole transfer, login included. Moving configuration backups from TFTP to SCP adds authentication and encryption. It does not add speed, compression or change tracking.

The difference between the two is scope. SCP only copies a file. SFTP is a full file management protocol: besides copying, it can list a remote directory and rename or delete files on the server. Telnet, on TCP 23, is a remote shell, not a file transfer protocol, and plays no part in either.

If a firewall between a router and its backup server permits only TCP 22, an SCP copy, or an SFTP copy, will succeed. TFTP, FTP and HTTP copies will be blocked.

Step 1: SSH must work first

SCP and SFTP ride on SSH, so the device needs a working SSH setup before either can run. SSH needs an RSA key pair, and IOS names the default key pair from the hostname and the IP domain name. If either is missing, key generation refuses:

Router(config)#crypto key generate rsa modulus 2048
% Please define a hostname other than Router.
Router(config)#hostname R1
R1(config)#crypto key generate rsa modulus 2048
% Please define a domain-name first.
R1(config)#ip domain name corp.example
R1(config)#crypto key generate rsa modulus 2048
The name for the keys will be: R1.corp.example
% The key modulus size is 2048 bits
% Generating 2048 bit RSA keys, keys will be non-exportable...
[OK] (elapsed time was 2 seconds)
R1(config)#ip ssh version 2
R1(config)#username netops privilege 15 secret N3tOps!
R1(config)#line vty 0 15
R1(config-line)#login local
R1(config-line)#transport input ssh

Check the result with show ip ssh:

R1#show ip ssh
SSH Enabled - version 2.0
Authentication methods:publickey,keyboard-interactive,password
Authentication timeout: 120 secs; Authentication retries: 3

If this reports version 1.99, the router accepts both SSH version 1 and version 2. Version 1 has known weaknesses, and ip ssh version 2 removes it. Do not confuse this with crypto key zeroize rsa, which deletes the keys and switches SSH off entirely. Local accounts and the login local line command are covered in lesson 17.

Step 2: the router as an SCP server

Often an administrator wants to push a file from a laptop into the router's flash, for example with scp from a terminal. That makes the router the SCP server, which is off by default. Turning it on takes one command, but the IOS SCP server also relies on AAA: it needs aaa new-model, a login authentication list and exec authorisation that places the user at privilege level 15.

R1(config)#aaa new-model
R1(config)#aaa authentication login default local
R1(config)#aaa authorization exec default local
R1(config)#ip scp server enable

A common fault: SSH works, ip scp server enable is in the configuration, the same account can open an SSH session, and still every SCP copy from the laptop fails. If that account lands at privilege level 1, the missing piece is exec authorisation to level 15. transport input ssh cannot be the problem, because the SSH session already works. So for inbound SCP, two items must be present beyond the hostname and domain: SSH enabled with an RSA key pair, and ip scp server enable, with AAA placing the user at level 15. Telnet settings, a TFTP source interface and service password-encryption have nothing to do with it.

From the laptop, the push looks like this:

admin@laptop:~$ scp new.bin netops@10.1.1.1:flash:/new.bin

Step 3: copying from the router, the router as client

More often the router pulls or pushes files itself, acting as the client to an SCP or SFTP server. Both use the copy command, which always takes the source first and the destination second.

Back up the running configuration to the file r1.cfg on SCP server 192.0.2.10, logging in as netops:

R1#copy running-config scp://netops@192.0.2.10/r1.cfg
Address or name of remote host [192.0.2.10]?
Destination username [netops]?
Destination filename [r1.cfg]?
Writing r1.cfg
Password:
!
5821 bytes copied in 1.204 secs (4835 bytes/sec)

Reverse the two arguments, copy scp://netops@192.0.2.10/r1.cfg running-config, and you pull the old file into the running configuration instead of saving it. Writing startup-config as the source backs up the saved configuration, which may not match what is running.

SFTP uses the same shape with a different scheme:

R1#copy running-config sftp://netops@192.0.2.10/backups/r1.cfg

Pull a new image from SCP server 10.1.1.50 into flash, logging in as admin:

R1#copy scp://admin@10.1.1.50/new.bin flash:

The equivalent copy tftp://10.1.1.50/images/new.bin flash: would also fetch the file, but with no login and no encryption, so it is not a secure transfer. An image belongs in flash:, never in nvram:, which holds the startup configuration.

What happens when a file is copied into running-config

Copying a configuration file into running-config does not replace the running configuration. IOS executes the file's commands as if they were typed, and merges them with what is already there. Lines that exist on the router but not in the file stay in place. So restoring a backup this way can leave an unwanted ACL entry or interface setting behind.

To make the running configuration exactly match a file, removing anything the file does not contain, use configure replace:

R1#configure replace flash:r1-known-good.cfg

Copying a file to startup-config is different again: it overwrites the saved configuration, which takes effect at the next reload.

A safe restore after a bad change, step by step:

1. Pull the known-good backup into flash first, so the restore does not depend on the network staying up: copy scp://netops@192.0.2.10/r1.cfg flash:r1-known-good.cfg.
2. Replace the running configuration with it: configure replace flash:r1-known-good.cfg. IOS works out which lines to remove and which to add.
3. Check that the device behaves as expected, then save with copy running-config startup-config.

Checking space and verifying an image

Before copying a large image, check that flash has room. dir flash: lists the files and ends with the total and free bytes:

R1#dir flash:
Directory of flash:/

    1  -rw-     712311234  Oct 1 2026 08:20:05 +00:00  current.bin
    2  -rw-          5821  Oct 15 2026 17:02:11 +00:00  r1-backup.cfg

7194652672 bytes total (6481100800 bytes free)

A 900 MB image (about 944,000,000 bytes) fits comfortably here. show ip ssh, show users and show clock say nothing about storage.

After the copy, check that the file arrived intact and is the one Cisco published. A listing only proves the file is present and its size. verify /md5 computes the file's hash, which you compare with the value on Cisco's download page:

R1#verify /md5 flash:new.bin
.........................................................Done!
verify /md5 (flash:new.bin) = 4b1e9c27d05f6a83e2c4917ab5d06e3f

If the hashes differ, the file was corrupted in transit or is not the genuine image, so do not boot from it. Newer releases also offer verify /sha512, and Cisco publishes both values.

Making the device boot the new image

A router that boots from an image file needs to be told which file to load. Copying the image to flash and verifying it changes nothing on its own; at the next reload the router may load the old image again.

R1(config)#no boot system
R1(config)#boot system flash:new.bin
R1(config)#end
R1#copy running-config startup-config
R1#reload

boot system points the router at the new image, and saving the configuration keeps that instruction for the reload. After the reload, show version reports the image file it booted from. Never copy an image into running-config or startup-config; those hold configuration text, not software.

Catalyst 9000 switches running IOS XE usually operate in install mode, where the upgrade is a single command instead of a boot statement:

SW1#install add file flash:new.bin activate commit

What the exam is really asking

• Port 22 for both. SCP and SFTP run inside SSH on TCP 22. TFTP is UDP 69 with no security; FTP is TCP 21 with clear-text logins; Telnet is TCP 23.
• What SCP adds over TFTP. Authentication and encryption. Not speed, not compression.
• SFTP versus SCP. Both encrypt and authenticate. Only SFTP can list, rename and delete remote files.
• Inbound SCP prerequisites. Hostname, domain name, RSA keys, SSH, ip scp server enable, and AAA exec authorisation to level 15.
• Source then destination. copy running-config scp://... backs up; the reverse restores.
• Merge versus replace. A copy into running-config merges. configure replace replaces.
• Present is not intact. dir flash: shows presence and free space; verify /md5 proves integrity.
• Copied is not booted. Set boot system, save, then reload; on Catalyst 9000 install mode, use install add file ... activate commit.
• SSH version 1.99 means both versions are accepted; ip ssh version 2 fixes it.