Exam Objective 4.2: Manage device configuration and software files using secure file transfer operations with SFTP/SCP.
Every network device eventually needs its configuration backed up, its IOS image upgraded, or a file copied to/from a central repository. Historically this was done with TFTP and FTP, both of which transmit everything — including credentials — in plaintext. This objective focuses on the modern, secure replacements: SFTP and SCP, both of which run over SSH and encrypt the entire transfer, including any authentication credentials involved. You're expected to know how to configure a device to use these protocols, execute the actual file transfers, and understand why the secure versions are preferred over their legacy counterparts.
Legacy file transfer protocols used for network device management have significant security weaknesses:
TFTP (Trivial File Transfer Protocol) — uses UDP port 69, has no authentication mechanism at all, and transmits everything in plaintext. Historically extremely common for IOS image transfers and configuration backups specifically because of its simplicity, but offers essentially no security.
FTP (File Transfer Protocol) — uses TCP ports 20/21, does support username/password authentication, but transmits both the credentials and the actual file contents in plaintext, making it vulnerable to interception.
Why this matters for network devices specifically: A configuration file transferred insecurely can contain sensitive information — local usernames, enable secrets (though hashed, still sensitive), SNMP community strings, pre-shared keys — all exposed in plaintext to anyone capturing the traffic. Similarly, credentials used to authenticate the file transfer itself are exposed if using TFTP (no auth at all, so less relevant) or FTP (auth exists but is sent in the clear).
The secure alternatives — SFTP and SCP — both operate over SSH (Secure Shell), meaning the entire session, including any authentication exchange and all transferred file content, is encrypted end-to-end.
Exam Alert: Know that TFTP has no authentication and FTP has authentication but no encryption — both are effectively insecure by modern standards, which is precisely the motivation behind this objective's focus on SFTP/SCP as the secure replacements.
Both SFTP and SCP depend on SSH already being properly configured and functional on the device, since they are built as subsystems/protocols riding on top of an established SSH session rather than being independent protocols of their own.
Prerequisites for SSH (and therefore SFTP/SCP) to function on a Cisco device:
A hostname and domain name must be configured (ip domain-name [domain]), since these are used to generate the device's RSA key pair
An RSA key pair must be generated (crypto key generate rsa), which is what SSH uses for its encryption
Local usernames (or AAA, per objective 4.1) must be configured for authentication
VTY lines must be configured to accept SSH (transport input ssh)
Basic SSH enablement sequence:
hostname Router1
ip domain-name example.com
crypto key generate rsa
(prompted for key modulus size, commonly 2048 bits or higher)
username admin privilege 15 secret Str0ngP@ss!
line vty 0 4
login local
transport input ssh
Exam Alert: Generating the RSA key pair (crypto key generate rsa) is what actually enables the SSH server process on the device — without a generated key pair, SSH (and by extension SFTP/SCP) will not function, even if every other piece of configuration looks correct.
SCP is a simple, secure file transfer protocol that copies files between hosts over an SSH connection, functionally replacing the plaintext rcp (remote copy) protocol it was originally derived from.
Key SCP characteristics:
Rides entirely over SSH (typically TCP port 22, the same port SSH itself uses)
Provides simple, straightforward file copy operations — get a file, or put a file — with less protocol overhead and fewer interactive features than SFTP
Widely supported and simple to configure, making it a common choice specifically for straightforward configuration backup and IOS image transfer tasks
Enabling the device to act as an SCP server (allowing an external device to initiate a copy to/from this router or switch):
ip scp server enable
This command allows the local device to serve as the SCP server side of a transfer — meaning an external SCP client (such as an administrator's workstation) can connect to this device and copy files to or from it, authenticated via the same local username/AAA credentials already configured for SSH.
Using the device as an SCP client (initiating a transfer from the device itself toward a remote SCP server):
copy running-config scp://admin@10.1.1.50/backups/router1-config
This example copies the router's running configuration to a remote SCP server at 10.1.1.50, authenticating as the user "admin" and storing the file in the specified remote path; the device will prompt for the remote user's password during the transfer unless key-based authentication has been separately configured.
Exam Alert: ip scp server enable is the specific command that allows the device itself to act as an SCP server, letting an external client initiate transfers to/from it — a frequently tested, easy-to-forget prerequisite, since SSH being enabled alone is not sufficient for SCP server functionality without this additional command.
SFTP (not to be confused with "Secure FTP," a different, less common protocol using a similar acronym) is a more full-featured file transfer protocol than SCP, also running entirely over SSH, but providing additional capabilities such as resuming interrupted transfers, listing remote directory contents, and more granular file management operations (renaming, deleting remote files, and so on) beyond simple copy operations.
Key SFTP characteristics:
Rides entirely over SSH (TCP port 22)
Provides richer, more interactive file management capability compared to SCP's simpler copy-only model
Increasingly the more modern, commonly recommended choice for file transfer where richer functionality (directory browsing, resuming transfers) is useful
Using the device as an SFTP client (initiating a transfer from the device toward a remote SFTP server):
copy running-config sftp://admin@10.1.1.50/backups/router1-config
The syntax closely parallels the SCP client example above, simply substituting sftp:// for scp:// in the destination URL — Cisco IOS handles both through a very similar copy command syntax, differing mainly in the protocol prefix used.
Relevant global configuration commands:
ip ssh source-interface [interface] — specifies which local interface's address should be used as the source for outbound SSH-based transfers (SCP/SFTP client operations), useful for ensuring transfers are sourced from a specific, predictable management interface rather than whatever interface happens to be selected by default routing behavior
Exam Alert: Know that SFTP offers richer file management functionality (directory listing, resuming transfers, file deletion/renaming) compared to SCP's simpler, more limited copy-only operation — this functional distinction is the most likely angle the exam tests between the two, beyond simply recognizing both as SSH-based secure alternatives to legacy protocols.
The Cisco IOS copy command is the universal tool for moving files both to and from a device, regardless of which protocol/transport is being used, following a consistent copy [source] [destination] syntax pattern.
Backing up the running configuration to a remote secure server:
copy running-config scp://admin@10.1.1.50/router1-running-backup
Backing up the startup configuration:
copy startup-config scp://admin@10.1.1.50/router1-startup-backup
Restoring/loading a configuration from a remote secure server back onto the device:
copy scp://admin@10.1.1.50/router1-running-backup running-config
Upgrading an IOS software image from a remote secure server:
copy sftp://admin@10.1.1.50/images/new-ios-image.bin flash:
Saving the running configuration to local flash/NVRAM (not remote, included for context/contrast):
copy running-config startup-config
Exam Alert: Recognize the general copy [source] [destination] pattern and that either side of the command can reference a remote SCP/SFTP location using the scp:// or sftp:// URL prefix — the exam is likely to show a specific copy command and ask what operation it performs (backup vs. restore vs. IOS upgrade) based on which side of the command references flash/running-config/startup-config versus the remote server.
Relevant verification commands:
show ip ssh — confirms whether SSH is enabled, which version is running, and current authentication timeout/retry settings
show crypto key mypubkey rsa — displays the device's generated RSA key pair details, confirming a key was actually successfully generated
show running-config | include scp|sftp|ssh — quickly audits relevant configuration lines related to secure file transfer and SSH
Common problems with SFTP/SCP file transfers:
No RSA key pair generated — SSH (and therefore SFTP/SCP) will not function at all until crypto key generate rsa has been successfully run
ip scp server enable missing — the device will not accept incoming SCP connections as a server, even though SSH itself is otherwise correctly configured and functional
Incorrect username/password or missing local user account — since SFTP/SCP authentication typically relies on the same local username database (or AAA) already configured for SSH access generally
Remote server unreachable — basic IP connectivity/firewall issues between the device and the remote SFTP/SCP server, unrelated to the secure-transfer configuration itself, exactly the kind of problem addressed by the systematic Layer 2/3 troubleshooting workflow from objective 2.4
Insufficient flash storage space on the device when attempting to copy a large IOS image inbound, causing the transfer to fail partway through
Domain name or hostname not configured before attempting to generate the RSA key pair — key generation itself will fail or be blocked if these prerequisites aren't already in place
Exam Alert: The dependency chain — hostname and domain name configured, then RSA key pair generated, then SSH functional, then (for server-side SCP specifically) ip scp server enable added — is a frequently tested ordered sequence; missing any one step earlier in the chain breaks everything that depends on it afterward.
Confirm the device has a configured hostname and domain name, both required before RSA key generation will succeed.
Generate the RSA key pair with crypto key generate rsa, confirming successful generation with show crypto key mypubkey rsa.
Confirm local usernames (or AAA, per objective 4.1) are configured for authentication, and that VTY lines are set to transport input ssh.
Verify SSH itself is functional using show ip ssh before attempting any SFTP/SCP-specific configuration or troubleshooting.
If the device needs to act as an SCP server (accepting inbound transfers initiated by an external client), confirm ip scp server enable has been configured.
For client-initiated transfers (the device pushing/pulling files to/from a remote server), use the copy command with the appropriate scp:// or sftp:// prefix, confirming correct syntax for source and destination.
If a transfer fails, isolate whether the problem is basic IP reachability to the remote server, an authentication/credential issue, insufficient local flash storage, or a missing prerequisite (RSA key pair, SCP server enablement) earlier in the configuration chain.
Q1. Which command must be successfully completed before SSH (and therefore SFTP/SCP) will function on a Cisco device?
A. ip scp server enable
B. crypto key generate rsa
C. login local
D. transport input ssh
Answer: B. Generating the RSA key pair with crypto key generate rsa is what actually enables the SSH server process on the device. Without a successfully generated key pair, SSH will not function at all, regardless of how correctly every other piece of related configuration (usernames, VTY transport settings, SCP server enablement) has been set up.
Q2. An administrator wants an external workstation to be able to initiate a file copy directly to a router using SCP. Which additional command is required on the router, beyond having SSH already configured and functional?
A. ip domain-name
B. ip scp server enable
C. crypto key generate rsa
D. transport input ssh
Answer: B. Even with SSH fully configured and functional, a Cisco device will not accept incoming SCP connections as a server until ip scp server enable has been explicitly configured. This is a distinct, additional requirement beyond basic SSH functionality.
Q3. Which of the following correctly describes a key functional difference between SFTP and SCP?
A. SFTP uses UDP while SCP uses TCP
B. SFTP provides richer file management functionality such as directory listing and resuming interrupted transfers, while SCP provides simpler copy-only operations
C. SCP is more secure than SFTP because it uses stronger encryption
D. SFTP does not require SSH, while SCP does
Answer: B. Both SFTP and SCP run entirely over SSH and provide equivalent underlying security, but SFTP offers a richer, more full-featured set of file management capabilities — including directory listing, resuming interrupted transfers, and file renaming/deletion — while SCP is a simpler protocol limited essentially to basic file copy operations.
Q4. Why is TFTP generally considered insecure for transferring network device configuration files or IOS images?
A. TFTP uses TCP instead of UDP, causing reliability issues
B. TFTP has no authentication mechanism and transmits all data in plaintext
C. TFTP requires an RSA key pair that most devices lack
D. TFTP is not supported on any modern Cisco device
Answer: B. TFTP was designed for simplicity and has no built-in authentication mechanism at all, and it transmits all file content in plaintext over UDP port 69. This means both the transferred files themselves and (since there's no authentication step at all) the overall transfer offer no confidentiality or access control, making it unsuitable for sensitive configuration or image files by modern security standards.
Q5. An administrator runs "copy running-config scp://admin@10.1.1.50/backups/router1-config" on a router. What does this command accomplish?
A. It restores a saved configuration from the remote server onto the router
B. It copies the router's current running configuration to a remote SCP server for backup
C. It upgrades the router's IOS image from the remote server
D. It enables the router to act as an SCP server
Answer: B. This command copies the source (the router's own running-config) to the specified destination, which is a remote SCP server location. Because running-config is the source and the scp:// URL is the destination, this operation is a backup — pushing the current configuration outward to a remote server — rather than a restore, which would have the scp:// URL as the source and running-config or startup-config as the destination.
Q6. A transfer using copy sftp://admin@10.1.1.50/images/new-ios-image.bin flash: fails partway through, even though SSH connectivity to the remote server was confirmed working correctly beforehand. What is a likely cause specific to this type of operation?
A. The RSA key pair was never generated
B. Insufficient available flash storage space on the device for the incoming IOS image
C. ip scp server enable was not configured
D. The username database was not configured with AAA
Answer: B. Since SSH connectivity itself was already confirmed working, the failure is more likely related to the specific nature of this operation — copying a (typically large) IOS image file into local flash storage. Insufficient available space in flash is a common cause of a transfer failing partway through specifically for IOS image upgrades, distinct from a general connectivity or authentication problem.