4.5 TFTP/FTP and Remote Access

File Transfer Protocols

Network engineers move two kinds of files constantly: IOS images (to upgrade or recover a device) and configuration files (to back up and restore). Three protocols cover the CCNA blueprint, differing sharply in security.

TFTP (Trivial File Transfer Protocol)

R1# copy running-config tftp:
Address or name of remote host? 10.0.0.200
Destination filename? R1-backup

R1# copy tftp: flash:
Address or name of remote host? 10.0.0.200
Source filename? c2900-universalk9-mz.SPA.bin

TFTP's simplicity (no directory listing, no auth, UDP) is exactly why it is the go-to for loading an image onto a router in ROMMON recovery — there is almost nothing to misconfigure.

FTP (File Transfer Protocol)

R1(config)# ip ftp username admin
R1(config)# ip ftp password Secure123
R1# copy ftp: flash:

FTP uses two channels: a persistent control connection on TCP 21 for commands and a separate data connection (TCP 20 in active mode) for the file bytes. That two-port behavior is a favorite exam contrast against TFTP's single UDP 69.

SCP / SFTP (Secure)

Both tunnel inside SSH on TCP 22, so authentication and the file itself are encrypted. SCP is the simplest secure option on IOS:

R1(config)# ip scp server enable
R1# copy scp: flash:

Remote Access — SSH over Telnet

Telnet (TCP 23) sends every keystroke, including the password, in clear text; anyone capturing the link reads it. SSH (Secure Shell, TCP 22) encrypts the whole session and is the only acceptable management protocol on a modern network.

Configuring SSH (memorize the order)

! 1. Hostname + domain — both required to name the RSA key
Router(config)# hostname R1
R1(config)# ip domain-name example.com

! 2. Generate the RSA key pair (2048-bit recommended)
R1(config)# crypto key generate rsa modulus 2048

! 3. Force SSH version 2
R1(config)# ip ssh version 2
R1(config)# ip ssh time-out 60
R1(config)# ip ssh authentication-retries 3

! 4. Lock the VTY lines to SSH and use the local user DB
R1(config)# line vty 0 15
R1(config-line)# transport input ssh
R1(config-line)# login local

! 5. Create a local account
R1(config)# username admin privilege 15 secret SecurePass123

The ordering is the exam's favorite trap. Hostname and domain name come first because IOS labels the RSA key as hostname.domain — generate the key before naming the device and the key has a meaningless label (or the command fails on default names). SSH itself cannot start until the key exists.

SSH vs Telnet

transport input ssh on the VTY lines blocks Telnet entirely; transport input ssh telnet would dangerously allow both. Pair it with login local (or AAA) so logins are authenticated against real accounts rather than a shared line password.

Why SSH Version 2 and 2048-Bit Keys

SSH version 1 has known cryptographic weaknesses, so ip ssh version 2 forces the stronger protocol and refuses v1 clients. The RSA key length also matters: IOS requires a modulus of at least 768 bits to enable SSHv2 at all, but 2048 bits is the recommended modern minimum for adequate strength. If you generate a 512-bit key, IOS will accept it but silently disallow SSHv2, a subtle reason "SSH won't come up" in a lab even though every command appears entered. Regenerating the key with a larger modulus, or deleting it with crypto key zeroize rsa, resets the state.

IOS Image and Config Management Workflow

These file-transfer protocols exist to support real device-maintenance tasks the exam describes in scenarios. A typical upgrade: verify free space with show flash: and the image integrity (Cisco publishes an MD5/SHA hash), copy tftp: flash: or copy scp: flash: the new image, set the boot variable with boot system flash:<image>, save with copy running-config startup-config, then reload. For backups, copy running-config tftp: (or to a secure server via SCP) captures the live config; restoring is the reverse, copy tftp: running-config.

Knowing the source-then-destination order of the copy command — copy <from>: <to>: — prevents the classic mistake of overwriting a good running config with an empty file.

Choosing the Right Transfer Protocol

When a question asks which protocol to use, weigh authentication, encryption, and reliability together. On an isolated management LAN where simplicity wins and there is nothing sensitive in transit, TFTP is acceptable and is the only option in ROMMON recovery. When you need accounts and directory listings but security is not paramount, FTP applies. Whenever the transfer crosses an untrusted segment or carries credentials, the answer is always SCP or SFTP because they ride encrypted SSH. The same encrypted-by-default logic that makes SSH beat Telnet makes SCP beat both FTP and TFTP.

On the exam: Know UDP 69 / no auth = TFTP, TCP 20-21 = FTP, TCP 22 = SSH/SCP, TCP 23 = Telnet. Reproduce the SSH steps in order — hostname/domain, RSA key (2048-bit, version 2), VTY transport input ssh + login local — recognize that allowing Telnet is the security defect, and remember copy is source-then-destination.