Subnet Academy
CCNA v2.0
CCNA v2.0/Módulo 8 · Servicios de red

0% del curso completado

Lectura

Transferencia segura de archivos: SFTP/SCP y gestión de imágenes IOS (4.2)

📋 En esta lección

Mover archivos hacia y desde los equipos de red — configuraciones, imágenes de IOS, capturas — es tarea semanal, y hacerlo con protocolos de 1985 es regalar credenciales. Aquí comparas TFTP/FTP con sus sucesores seguros (SCP/SFTP), configuras el servidor SCP en IOS, y completas el ciclo profesional de actualización de una imagen IOS: copiar, verificar, apuntar el arranque y reiniciar con red de seguridad.

El catálogo de protocolos

ProtocoloPuertoTransporteAutenticaciónCifradoVeredicto
TFTPUDP 69UDP, sin sesiónNingunaNoSolo labs y redes de gestión aisladas
FTPTCP 21 (control) + 20/datosTCPUsuario/clave en claroNoLegado; evitar
SCPTCP 22Sobre SSHLa de SSHEl estándar para equipos de red
SFTPTCP 22Sobre SSHLa de SSHEl estándar general de archivos

Las dos lecturas importantes de la tabla:

  • TFTP no autentica a nadie: cualquiera que alcance el servidor puede leer o escribir. Su virtud histórica es la simplicidad (cabía en una ROM de arranque); su sitio actual, el lab de Packet Tracer y poco más.
  • SCP y SFTP no son "FTP con S": son protocolos distintos que viajan dentro de SSH (puerto 22) — heredan su cifrado, sus usuarios y sus claves. SCP es una copia simple (origen → destino); SFTP es un protocolo de gestión completo (listar, borrar, reanudar). Para copiar una imagen a un router, SCP; para un servidor de archivos de personas, SFTP. (FTPS — FTP sobre TLS — existe, pero apenas se usa en equipos de red.)

SCP en IOS: cliente y servidor

El router puede ser cliente (inicia la copia hacia/desde un servidor) o servidor (tú le empujas archivos con un cliente SCP desde tu PC).

Servidor SCP — la configuración se apoya en el SSH que ya montaste (lección 3.1):

! Prerrequisitos: hostname, dominio, clave RSA, SSHv2, usuario local (lección 3.1)
R1(config)# ip scp server enable
R1(config)# aaa new-model
R1(config)# aaa authentication login default local
R1(config)# aaa authorization exec default local

SCP exige AAA con autorización (a diferencia del SSH interactivo básico): sin las líneas aaa, el servidor SCP rechaza las conexiones aunque SSH funcione. Desde tu PC:

$ scp cat9k_lite-universalk9.17.09.05.SPA.bin admin@10.1.250.2:flash:/
$ scp admin@10.1.250.2:running-config ./backup-R1-20260918.cfg

Cliente desde IOS — el mismo copy universal de la lección 3.3, con URLs de protocolo:

R1# copy scp://admin@10.1.30.50/imagen.bin flash:
R1# copy running-config scp://admin@10.1.30.50/backups/R1.cfg
! (los equivalentes tftp:// y ftp:// existen — con sus miserias de seguridad)

El ciclo profesional: actualizar una imagen IOS

La operación de riesgo por excelencia: si sale mal, el equipo puede quedar sin sistema. El procedimiento completo, paso a paso:

1. Preparar

R1# show version                     ← versión actual y REGISTRO de arranque
R1# show flash: | include free       ← ¿cabe la imagen nueva?
R1# copy running-config scp://admin@10.1.30.50/pre-upgrade-R1.cfg   ← backup SIEMPRE

Si no hay espacio: borra imágenes viejas solo tras verificar cuál está en uso (show version dice desde cuál arrancó — borrar la imagen activa de flash no tumba el equipo en caliente, pero elimina tu red de seguridad).

2. Copiar y verificar

R1# copy scp://admin@10.1.30.50/cat9k_lite.17.09.05.SPA.bin flash:
R1# verify /md5 flash:cat9k_lite.17.09.05.SPA.bin
.....Done!
verify /md5 (flash:...) = 3f8a9c21b4de...   ← comparar con el hash oficial de Cisco

La verificación no es opcional. Una imagen corrupta (descarga truncada, flash defectuosa) descubierta después del reload es un equipo en ROMMON y tú con el cable de consola a las 2 AM. El hash publicado por Cisco en la página de descarga debe coincidir carácter a carácter — también valida que nadie manipuló la imagen por el camino (integridad y autenticidad en un solo gesto).

3. Apuntar el arranque

R1(config)# no boot system                                  ← limpia entradas viejas
R1(config)# boot system flash:cat9k_lite.17.09.05.SPA.bin   ← la nueva, primera
R1(config)# boot system flash:cat9k_lite.17.09.04a.SPA.bin  ← la vieja, de RESPALDO
R1# write memory                                            ← ¡o el boot no sobrevive al reload!

Las entradas boot system se procesan en orden: si la primera imagen falla o falta, el equipo intenta la siguiente — dejar la versión anterior como segunda entrada es tu red de seguridad. Y el write memory es crítico: el boot system vive en la startup-config (lección 3.3); sin guardar, el reload usará la configuración de arranque antigua.

(En plataformas modernas Catalyst 9k el flujo recomendado es el modo install — install add file ... activate commit — que gestiona paquetes y rollback automáticamente; el modelo boot-system que acabas de ver es el clásico universal y el del examen.)

4. Reiniciar y confirmar

R1# reload
...
R1# show version | include Software|uptime    ← ¿la versión nueva? ¿arranque limpio?
R1# show ip ospf neighbor / show standby brief ← ¿los servicios volvieron?

En ventana de mantenimiento, con consola a mano (si algo va mal, el acceso IP puede no volver — lección 3.1) y con el plan de vuelta atrás escrito antes de empezar: gracias a la doble entrada de boot, volver = restaurar el orden de los boot system y reload.

Backups de configuración: la rutina que salva carreras

El mismo copy ... scp:// aplicado con disciplina (lección 3.3): backup antes y después de cada cambio relevante, nombres con equipo y fecha, y almacenamiento central versionado. Las organizaciones maduras lo automatizan (RANCID, Oxidized, o los playbooks de Ansible que verás en la lección 11.4) — cada cambio de configuración queda commiteado con diff, como el código.

Relación con otros conceptos

  • SSH, sus claves y usuarios (lección 3.1) son la base de SCP/SFTP; el comando copy y las ubicaciones, de la 3.3.
  • Los puertos 21/22/69 completan el mapa de la lección 1.6 — y la pareja "FTP en claro vs SCP cifrado" rima con Telnet vs SSH.
  • La verificación por hash conecta con la integridad criptográfica que formaliza el Módulo 10 (lección 10.1).
  • La automatización de backups y upgrades a escala es territorio de Ansible e IaC — lección 11.4.

Resumen

Para archivos de red: SCP/SFTP sobre SSH (TCP 22) — cifrado y autenticación heredados; TFTP (UDP 69, sin autenticación) solo en labs, FTP (21, credenciales en claro) a extinguir. En IOS: ip scp server enable + AAA local para recibir, y copy scp://usuario@servidor/... como cliente. El ciclo de upgrade: backup de config → espacio en flash → copiar la imagen → verify /md5 contra el hash oficial de Cisco (innegociable) → boot system nueva primero y vieja de respaldo (se procesan en orden) → write memory → reload en ventana, con consola y plan de vuelta atrás → confirmar versión y servicios. Y los backups de configuración, antes y después de cada cambio — automatizados en cuanto la red crece.

Fuentes oficiales

Quiz

Comprueba lo que has aprendido

1.¿Qué relación tienen SCP y SFTP con SSH?

2.¿Por qué TFTP quedó relegado a laboratorios y redes de gestión aisladas?

3.Habilitas `ip scp server enable` y las copias SCP fallan, aunque el SSH interactivo funciona. ¿Qué falta?

4.¿Por qué `verify /md5` es un paso innegociable antes de arrancar con una imagen nueva?

5.¿Por qué se configuran dos entradas `boot system`, la nueva primero y la vieja después?

6.¿Cuál es la rutina profesional de copias de seguridad de configuración?

← Anterior
Syslog: severidades, facilities e interpretación de mensajes (5.6)