¿Cómo obtener scp a través de snmp para trabajar con enrutadores Cisco?

Tengo una configuración de laboratorio en la que intento usar SCP a través de SNMP en un enrutador Cisco. Encontré documentación en línea como: http://ccie20728.wordpress.com/2008/05/20/get-the-cisco- configuración-sobre-snmp /

Aquí está mi configuración de alto nivel. En el enrutador:

R1(config)# username cisco password cisco
R1(config)# ip domain-name somedomain.com
R1(config)# crypto key generate rsa general-keys modulus 1024
R1(config)# aaa new-model
R1(config)# aaa authentication login cisco local
R1(config)# aaa authorization exec cisco local
R1(config)# ip scp server enable
R1(config)# line vty 0
R1(config)# login authentication cisco
R1(config)# snmp-server community cisco RW

Para que el enrutador actúe como el servidor SCP, debe habilitarlo con el cmd anterior. En un servidor ubuntu, tengo openSSH instalado / ejecutándose y haciendo esto cmds:

snmpset -c cisco -v 2c <router ip addr> 1.3.6.1.4.1.9.9.96.1.1.1.1.2.111 i 4
snmpset -c cisco -v 2c <router ip addr> 1.3.6.1.4.1.9.9.96.1.1.1.1.3.111 i 4
snmpset -c cisco -v 2c <router ip addr> 1.3.6.1.4.1.9.9.96.1.1.1.1.4.111 i 1
snmpset -c cisco -v 2c <router ip addr> 1.3.6.1.4.1.9.9.96.1.1.1.1.5.111 a <svr ip addr>
snmpset -c cisco -v 2c <router ip addr> 1.3.6.1.4.1.9.9.96.1.1.1.1.6.111 s cisco.txt
snmpset -c cisco -v 2c <router ip addr> 1.3.6.1.4.1.9.9.96.1.1.1.1.7.111 s cisco
snmpset -c cisco -v 2c <router ip addr> 1.3.6.1.4.1.9.9.96.1.1.1.1.8.111 s cisco
snmpset -c cisco -v 2c <router ip addr> 1.3.6.1.4.1.9.9.96.1.1.1.1.14.111 i 1

Luego, para verificar cuál es el estado, hago un snmpget y / o snmpwalk a través de:

snmpwalk -c cisco -v 2c <router ip addr> 1.3.6.1.4.1.9.9.96.1.1.1.1.10.111

cuando ejecuto esto, obtengo el número entero (2), lo que significa que se está ejecutando, luego va al número entero (4), lo que significa que falló.

Luego verifico el motivo del fracaso:

snmpwalk -c cisco -v 2c <router ip addr> 1.3.6.1.4.1.9.9.96.1.1.1.1.13.111

y obtengo el entero (2), que significa "nombre de archivo incorrecto".

Así que probé diferentes permutaciones de un nombre de archivo para ".6.111 string" arriba, incluidas diferentes extensiones de archivo, con y sin guiones, el mismo nombre de archivo que ejecutando cmds de configuración, incluso el nombre de archivo de ruta absoluta especificado, pero ninguno parece funcionar.

Intenté depurar sshdcon varios niveles de registro y no obtuve ningún resultado del archivo syslog guardado / almacenado.

¿Alguien ha podido hacer que esto funcione?

Acabo de probar esto en mi CPE:

[ytti@lintukoto ~]% cat moi2.sh 
#!/bin/sh

snmp="snmpset -v2c -cfoo bu.ip.fi"

$snmp 1.3.6.1.4.1.9.9.96.1.1.1.1.2.9 i 4 \
      1.3.6.1.4.1.9.9.96.1.1.1.1.3.9 i 4 \
      1.3.6.1.4.1.9.9.96.1.1.1.1.4.9 i 1 \
      1.3.6.1.4.1.9.9.96.1.1.1.1.5.9 a 91.198.120.2 \
      1.3.6.1.4.1.9.9.96.1.1.1.1.6.9 s filename \
      1.3.6.1.4.1.9.9.96.1.1.1.1.7.9 s username \
      1.3.6.1.4.1.9.9.96.1.1.1.1.8.9 s password \
      1.3.6.1.4.1.9.9.96.1.1.1.1.14.9 i 4
sleep 10
$snmp 1.3.6.1.4.1.9.9.96.1.1.1.1.14.9 i 6
[ytti@lintukoto ~]% 

Que copia ejecutando config (4) a la red (1), intercambiando estos puede cambiar la dirección (de la red a la ejecución).

Al ejecutar el script anterior, mi directorio de inicio tendrá el archivo 'nombre de archivo', que contiene mi CPE running-config:

[ytti@lintukoto ~]% ls -la filename
ls: cannot access filename: No such file or directory
[2 ytti@lintukoto ~]% ./moi2.sh      
iso.3.6.1.4.1.9.9.96.1.1.1.1.2.9 = INTEGER: 4
iso.3.6.1.4.1.9.9.96.1.1.1.1.3.9 = INTEGER: 4
iso.3.6.1.4.1.9.9.96.1.1.1.1.4.9 = INTEGER: 1
iso.3.6.1.4.1.9.9.96.1.1.1.1.5.9 = IpAddress: 91.198.120.2
iso.3.6.1.4.1.9.9.96.1.1.1.1.6.9 = STRING: "filename"
iso.3.6.1.4.1.9.9.96.1.1.1.1.7.9 = STRING: "username"
iso.3.6.1.4.1.9.9.96.1.1.1.1.8.9 = STRING: "password"
iso.3.6.1.4.1.9.9.96.1.1.1.1.14.9 = INTEGER: 4
iso.3.6.1.4.1.9.9.96.1.1.1.1.14.9 = INTEGER: 6
[ytti@lintukoto ~]% ls -la filename
-rw-r--r-- 1 ytti ytti 16172 Jun 11 00:35 filename
[ytti@lintukoto ~]% 

Además de lo que @daniel menciona también, su '14' o 'rowstatus' está mal, usa 1 'activo', mientras que debe usar 4 'createAndGo'.

De acuerdo con Cisco SNMP Object Navigator, el valor 4 no es compatible con 1.3.6.1.4.1.9.9.96.1.1.1.1.3. En cambio, el valor 2 significa la configuración de ejecución:

Object  ccCopySourceFileType
OID     1.3.6.1.4.1.9.9.96.1.1.1.1.3
Type    ConfigFileType
1:startupConfig
2:runningConfig
Permission  read-create

Probablemente por eso está recibiendo el error badFileName.

EDITAR:

En realidad parece que hay contradicción entre SNMP Object Navigator y la definición de MIB , como tipo para ccCopySourceFileTypey ccCopyDestFileTypees ConfigFileTypey según la definición de MIB:

ConfigFileType ::= TEXTUAL-CONVENTION

SYNTAX          INTEGER  {
                        networkFile(1),
                        iosFile(2),
                        startupConfig(3),
                        runningConfig(4),
                        terminal(5),
                        fabricStartupConfig(6) }

Y esto parece respaldado por la respuesta de ytti

He publicado esto antes: http://checkforbees.com/router-backup/

Creo que su problema es con los múltiples snmpset. Tienes que comenzar creando la entrada para hacer esto. [14.xxx = 5 (createAndWait)] Luego puede configurar la entrada según sea necesario antes de establecer el estado de la fila en "1" (activo).

[Nota: mis scripts tienen décadas de antigüedad, por lo que están ajustados para tftp.]

[root:pts/6{8}]debian1:/tmp/[01:32 AM]:./test.sh
CISCO-CONFIG-COPY-MIB::ccCopyProtocol.111 = INTEGER: scp(4)
CISCO-CONFIG-COPY-MIB::ccCopySourceFileType.111 = INTEGER: runningConfig(4)
CISCO-CONFIG-COPY-MIB::ccCopyDestFileType.111 = INTEGER: networkFile(1)
CISCO-CONFIG-COPY-MIB::ccCopyServerAddress.111 = IpAddress: 192.168.55.25
CISCO-CONFIG-COPY-MIB::ccCopyFileName.111 = STRING: cisco.txt
CISCO-CONFIG-COPY-MIB::ccCopyUserName.111 = STRING: cisco
CISCO-CONFIG-COPY-MIB::ccCopyUserPassword.111 = STRING: cisco
CISCO-CONFIG-COPY-MIB::ccCopyEntryRowStatus.111 = INTEGER: active(1)
..
Status: successful []
CISCO-CONFIG-COPY-MIB::ccCopyEntryRowStatus.111 = INTEGER: destroy(6)
[root:pts/6{8}]debian1:/tmp/[01:32 AM]:ls -l cisco.txt
-rw-r--r-- 1 root root 15790 Jun 12 01:32 cisco.txt

Estoy dando vueltas ... 10.111 (estado) mientras está "ejecutándose". Sospecho que nunca ha eliminado su entrada "111". De lo contrario, son su secuencia exacta de snmpsets contra un 2960S con el servidor ssh de una caja de Linux. (Como sugiere mi mensaje, una caja de Debian).

Consulte aquí: Cómo copiar archivos de configuración desde y hacia los enrutadores Cisco IOS que usan SNMP

Cambie ccCopyProtocola su método de transferencia deseado:

1. tftp
2. ftp
3. rcp
4. scp
5. sftp

Aquí hay un script bash para automatizar las copias de seguridad de la configuración.