We have some Cisco 2821, 2921 and 1921 routers in our shop. I can back up and restore the configurations by copying out or in the startup-config file, but what about the keys for ssh? I don't want them to change in case I have to swap in a new router. It's a long story, but basically I have some admin scripts that ssh into the router on an automated basis, and they will get mighty confused if they unexpectedly get that "man-in-the-middle" warning. So, in short, in need a way to configure a new router with exactly the same configuration as the one it is replacing, including ssh keys and passwords.
Asked
Active
Viewed 1.1k times
3 Answers
12
(Examples performed on ISR 1921 G2)
Before we get into the details, I would suggest that instead of backing up your key, you just pull the new key from the new router and update your scripts. You will need to get onto the router without SSH to load the config/enable SSH anyways. This can be done with a script and console cable... you can even pull the new SSH public key out and update your scripts automatically (router#sh ip ssh). I think this is a more secure option. However to answer the question of backing up SSH keys:
You need to generate exportable keys for use with SSH and then export them to a PEM file with a password. Unfortunately the only two options for encrypting them are des and 3des.
Generate the key:
home-1921(config)#crypto key generate rsa general-keys exportable label example modulus 4096
The name for the keys will be: example
% The key modulus size is 4096 bits
% Generating 4096 bit RSA keys, keys will be exportable...
[OK] (elapsed time was 658 seconds)
Jun 15 11:10:05.158: %SSH-5-ENABLED: SSH 1.99 has been enabled
home-1921(config)#
Assign to SSH if not already assigned:
home-1921(config)#ip ssh rsa keypair-name example
home-1921(config)#
Jun 15 11:11:22.467: %SSH-5-DISABLED: SSH 1.99 has been disabled
Jun 15 11:11:22.467: %SSH-5-ENABLED: SSH 1.99 has been enabled
Export the key:
This will export the key to the terminal which can be saved to a file via script or manually.
home-1921(config)#$export rsa example pem terminal 3des somepassword
% Key name: example
Usage: General Purpose Key
Key data:
-----BEGIN PUBLIC KEY-----
MIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEAsWwtMdoyj/LKPzXRf53z
8yhIkRAbODN6DXne8JH53PAwtgQ2FrPARvnjWsqWn2EgkHEMkZl5y5tZ0iLITCPf
bK8pXC/9kiLC2VDGQLbHD57AN/+6+0CoXxGW4FtV1dW4tVzo0YafL3L0rrNY8Snk
nPXUu89RxYu0rnJCJGv3VQ5DS/LMx7RcKdB0oKh5NxrzMGR5AXCtK0d5giHIu5o7
UAO8Q0JHYjHVHTtk8tnK5jhSMT68e4GxtsNSAaf5iA2qXY0E4KSZ+NCQJzM7RKa/
/Sj8wmSHRhGYwEzfVdh+Cp3SRjiNSF4nVcECSEsEo5XzhM+yMHUJWeXw18pVFfED
koen7IRw9Sj+uw0pegIwS4D/eniv/SMfPgjVd6RIm2k35GiH59Y73Bufu23+TOoB
siYsZcbQ3QFohe5ix08pTeyvNXl6d6WlZWsyUfl7B9qIf5dICOfxu22xsFkdd3UX
URyQum/oQPBLEGAaX01vto+oRW/DYXnIz4GXchTVnZMPxk5NGA3Li6advTWT3Vb8
rH0aDSdtybrg0wVyOhEPW9Kx5Kx8ycxisZ7dM9iryvxjNtmmhxn9FS2uSI6mnOmR
aQOG44Jyn/ihzaYuAsfbxHvDnKQKIJtQoJtrbrgjAh93GT/HIyHRLz1iRwGwNwlj
3GUBV1NsL+HVZN68GPOyHfkCAwEAAQ==
-----END PUBLIC KEY-----
-----BEGIN RSA PRIVATE KEY-----
Proc-Type: 4,ENCRYPTED
DEK-Info: DES-EDE3-CBC,0243F61FBCFF9FFD
i4lMwdfFZpC48ZFF3RnEOpLZzmv+vSgrHH6DGI/Gm1hB4KK+MC/a1TrrNbNzKPzY
HFs74jLpGvYGb0jL5PbqrCL435F92h+N9SAkp4Tz8x78y4hUnM/2I9X9MhcGXJqE
5U2r47KSYjUO+L41gWRDwwq7uZPXdJMEOr3JhJ6wv1UJx8BkxatmoZyeKMHIAcfQ
JcwHnFnVZP3bNRYSwaMGemrfhg8HiT/JT3gUFj5d8r2pAouY8Vs9j4fM7EIn+CHz
zGdZf9j3wIYOLjOhGLs7zABRmu4Ik7yv7iNqIOpZLMVegC9iQc6RMav8M3ivt+wU
eNBR7+VLOYAz1J7bKEx1ZMk9XR4zdNTJlw+4UuYtXDDlW3OOsBFq/05mKPvaQWCE
/NUrxSSEpgqaLJNJS5V4rgPKhSbg51GeIhkig+NkFIS7EtF/VCMXqaWd0lp7kYig
3arRF0BdZXLsMDhZKmi1JA+rcmCSQIYVaBDc29SMs/Wou99vVazQIs2e1Dkl06Ia
U7VeIwhEJykIl0MhBw+kwD3pNsiPth1xIg3DsDU+bq3gMNhcsl6Pj8FUP+PXdqaa
HSGOy2tnYB60xxFv4vfRiW7JaFse9+uaesRiPDOC5YUx47yP65xEhiCmKMXD+9xU
K/ZFYe9AvbJ4A65JjO/QQm5mg82cw5q4x/YQ1EC9T1w5kdjKJg9MkYoZmhHfttUZ
2zuGBFm9FUiW5SnRRp4Pil0aTAMgj8uZaxUdq1nGfyJo2p7TTNXKsE8YMkSwu93p
L914L64/bI2RLVQCciLZtVnVwAMffNpwtOJQzDDeUDI3i1ZItzehcsXXAWCN5xcQ
+0lF6Q3KlrDNGZCtO8vrbDioaFT25ikdAlF0B+pnadetQkXlLs8xdBxxF9lUZjgw
NqkbrYoY/c7Jf7dsWfC7fRqo3EjBxEFPwrdJJpvTtzgp4/Zk+dcHg0j4K2pFVMeT
sZZzDaWlCaRoKw+OSh2KyzWjGKSzh/mm+cdp/4T+bbhUseRF6eGb0Qk0lMyQv3ja
EE0GnyOYSlcavvIrqpx9v1iLEJLGWi58UiOASnzBlRh33nRqF+uoE5p6k/jgoUWC
CccW2SfyEfXJDOg6fqGyKw3XjAJQ0/t1qWbiIXxtNjH8haO9OgWUn3pKI6PjZwQk
6Eb5ow8WABZXb/pXJ/xjmLKjsmlxeqD31I2CaArV6hRCJoTKXkS2TWHCoHGRAPfL
jrDBiFJ1+KVnCtuGN1kxRG6fyIMMyFBG7qEzNnHmNnLGP19XHvgSJe0QYNdrkFpZ
iG+Kqz5bHcdEsucB0Efn/N7huu++R5XnSRYJnf6iPOTme6qwul3H1YQoaNNAbuch
u98JaciIiSGLesBU4P28FEC4kesslKWcM8Z4GfvX//9zqkB6T1E5/jUs+x6YtPhp
kMg9ZR195mP11E4MbgP9czk7HnK4Xgrns/DmXRdT1/d0dPtfng02jWjvOgNUQ1EJ
ZvFd9ZN67nV4ZiDtcVi3756m7UEI2p/2431ecpigy2OUA+d8YKYEbAreMDE7W4Iq
AlUalEiRmjwoerVIgQeB3oa2GElg2IN6llEa1UndI79ma13SJmgpLM+YUW+nS7k6
COiuKllSbLBSF9s4+ErEXciAAJCGFi7kfFDB59whv1IbmDEGNAamB6oibCewbF0T
xusyjhb2wA0KDq5C3ThlM5KU0g0ACSEuOl/A4AuubwxD7vvC6jiVFw/bCQrRJLJ6
UuEcBTp0vEecdF12NtQWPpg/+K2PYBi7Yzzc8DZcF97afFmZAtnF3EFLJltywjjK
qcGGCNyDj9MSBEnJigK7m0nYKjsOw5myt5LOhwWMr81OC7s6vgMBdf7qFCHiOUUB
5MwpAzjGgaR85uYqCpCOmW5pjRpRptEocJPxeW6Uy+aFPAEQu92HvFjHk/tvefGX
ttSsOPU5BC1J5xGZIoUfGPRFPYkjLauwQ34hGdQrbhJ3DrEe1pDAwd8/yIhzNp0o
N8uZDWKegLPrRg1B6CvmY3+Axiz0ZJZ86LOLa67ZsEkbWpQoy4F8D+z131JFrRcK
v0glY5b2GESUXtVxO668LqbmcO/eoDgBIhNvbrJT1QVgM/rr3poeeARGgff9OQ0i
FpsA4yk4uOqS/TS4OfpG6ymneGao1tJfktXmiR37cpGfkKjHPvI5kE8/KTOZSdSk
5RYjuCaWW363ysn7XA21Y9NiMYZesKCw8XdxVfVDZB6IphawYZ/a4cyvkYfD5HKw
QeLE7Rv7fGhlUPPWr1WQZOBgnnmAZoxNxkPhC4S62WvdiJNmiIeLrmD50n22zukH
aCj5S6sqXRuHdLB8FiZdi24s9tISBt0kAzK4bg3bvPoaqj3nSL8eirr1qWED/O+5
xxjJrR7fgY0BdzbqU5gXK22o6PLGzlOIpgFep12dnoYUVL2igRJfTAGSHyMPeJpv
e5mmAqxCz8FGgztZVP+v8MEkz/fDd/bIA0zkeA+0ugedbI/IkDkS25RdZkpvUpXH
2+SNL1RJyoYT/uoShAuVv6y9uyvoojX9XNDVmLX10ip8tSsTVbJx97MPzNSaTABe
Zbc5rgU4FJnUIIjb4igmccUrdW7ZknKk2cV9xRv7BHFYAl4hsitcsdKe8IPdX+2E
WOXl2i2+ndUkzoqGlr4q8nOgAcr53Msjnn1ljasWHXDpeXRW+kraX+88UUmv9zEf
T4gyl7shs/J24IlgHhJbqD5g10thG9esp8KvaxgeHyuBVpPniWWrecwajKFjfVKp
J9EcxDXRUZH3c4jDIWxpKsGQFFsx9e7p286tcUXwGDBFkYOao9NOcyllltRq+ECH
93Sc6hLp/Fd7hIAdZFbnjaemp2llA81cNKIVRUpJ4OyoVSOwhMp+j3m5SOmJdAxu
SWcMKENRU6RSjqZOt15acOktCRRrMbLSxZY+fW+1g5IvA1j6mFiK57F569ouYZeP
zvMgPgkDN/ATMd/RkHAWq5/EjeNmhey52XnHSqyAPmP4mX9qoaYtRYgBTGrKEFNo
05V14xLunvGz+FEsqZ/IwSZYbYkGCpfczQWlRLnLkb8X7gbL/esfKfb3tSsbOluZ
F/bAHniMg51uU2MmpspuWR+SzyWuabWiCkEq7lvXLTwdJGBYduaRH9u14bBCWUuA
-----END RSA PRIVATE KEY-----
home-1921(config)#
Login test:
demo-mac:~ demo$ ssh demo@<cleared>.205
The authenticity of host '<cleared>.205 (<cleared>.205)' can't be established.
RSA key fingerprint is af:6e:a0:fa:c3:45:ab:2d:a9:60:84:fe:0b:96:de:cc.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '<cleared>.205' (RSA) to the list of known hosts.
Password:
home-1921#
Ok so we know it works... time to erase the NVRAM and restart.
home-1921#erase nvram:
Erasing the nvram filesystem will remove all configuration files! Continue? [co]
[OK]
Erase of nvram: complete
home-1921#
Jun 15 11:16:19.268: %SYS-7-NV_BLOCK_INIT: Initialized the geometry of nvram
home-1921#reload
System configuration has been modified. Save? [yes/no]: no
Proceed with reload? [confirm]
Now we reconfigure the test router to allow SSH again:
Note: I am only generating a brand new key to demo that my terminal rejects the new key but then accepts the restored key. This step is unnecessary unless you're verifying that it works.
router>en
router#conf t
Enter configuration commands, one per line. End with CNTL/Z.
router(config)#int G0/0
router(config-if)#ip add <cleared>.205 255.255.255.0
router(config-if)#no shutdown
router(config-if)#exit
router(config)#ip domain-name example.com
router(config)#aaa new-model
router(config)#aaa authen log def loc
router(config)#aaa author exe def loc
router(config)#username demo priv 15 sec demo
router(config)#cry key gen rsa mod 4096
The name for the keys will be: router.example.com
% The key modulus size is 4096 bits
% Generating 4096 bit RSA keys, keys will be non-exportable...
[OK] (elapsed time was 117 seconds)
Jun 15 11:17:55.247: %SSH-5-ENABLED: SSH 1.99 has been enabled
router(config)#
Now the rejection of the key:
demo-mac:~ demo$ ssh demo@<cleared>.205
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a host key has just been changed.
The fingerprint for the RSA key sent by the remote host is
8c:62:d4:75:0f:4c:59:a8:81:d2:01:1b:68:9d:08:cb.
Please contact your system administrator.
Add correct host key in /Users/demo/.ssh/known_hosts to get rid of this message.
Offending RSA key in /Users/demo/.ssh/known_hosts:90
RSA host key for <cleared>.205 has changed and you have requested strict checking.
Host key verification failed.
demo-mac:~ demo$
Ok so lets restore the key and see what happens:
router(config)#$crypto key import rsa example-restored pem terminal somepassword
% Enter PEM-formatted public General Purpose key or certificate.
% End with a blank line or "quit" on a line by itself.
-----BEGIN PUBLIC KEY-----
MIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEAsWwtMdoyj/LKPzXRf53z
8yhIkRAbODN6DXne8JH53PAwtgQ2FrPARvnjWsqWn2EgkHEMkZl5y5tZ0iLITCPf
bK8pXC/9kiLC2VDGQLbHD57AN/+6+0CoXxGW4FtV1dW4tVzo0YafL3L0rrNY8Snk
nPXUu89RxYu0rnJCJGv3VQ5DS/LMx7RcKdB0oKh5NxrzMGR5AXCtK0d5giHIu5o7
UAO8Q0JHYjHVHTtk8tnK5jhSMT68e4GxtsNSAaf5iA2qXY0E4KSZ+NCQJzM7RKa/
/Sj8wmSHRhGYwEzfVdh+Cp3SRjiNSF4nVcECSEsEo5XzhM+yMHUJWeXw18pVFfED
koen7IRw9Sj+uw0pegIwS4D/eniv/SMfPgjVd6RIm2k35GiH59Y73Bufu23+TOoB
siYsZcbQ3QFohe5ix08pTeyvNXl6d6WlZWsyUfl7B9qIf5dICOfxu22xsFkdd3UX
URyQum/oQPBLEGAaX01vto+oRW/DYXnIz4GXchTVnZMPxk5NGA3Li6advTWT3Vb8
rH0aDSdtybrg0wVyOhEPW9Kx5Kx8ycxisZ7dM9iryvxjNtmmhxn9FS2uSI6mnOmR
aQOG44Jyn/ihzaYuAsfbxHvDnKQKIJtQoJtrbrgjAh93GT/HIyHRLz1iRwGwNwlj
3GUBV1NsL+HVZN68GPOyHfkCAwEAAQ==
-----END PUBLIC KEY-----
% Enter PEM-formatted encrypted private General Purpose key.
% End with "quit" on a line by itself.
-----BEGIN RSA PRIVATE KEY-----
Proc-Type: 4,ENCRYPTED
DEK-Info: DES-EDE3-CBC,0243F61FBCFF9FFD
i4lMwdfFZpC48ZFF3RnEOpLZzmv+vSgrHH6DGI/Gm1hB4KK+MC/a1TrrNbNzKPzY
HFs74jLpGvYGb0jL5PbqrCL435F92h+N9SAkp4Tz8x78y4hUnM/2I9X9MhcGXJqE
5U2r47KSYjUO+L41gWRDwwq7uZPXdJMEOr3JhJ6wv1UJx8BkxatmoZyeKMHIAcfQ
JcwHnFnVZP3bNRYSwaMGemrfhg8HiT/JT3gUFj5d8r2pAouY8Vs9j4fM7EIn+CHz
zGdZf9j3wIYOLjOhGLs7zABRmu4Ik7yv7iNqIOpZLMVegC9iQc6RMav8M3ivt+wU
eNBR7+VLOYAz1J7bKEx1ZMk9XR4zdNTJlw+4UuYtXDDlW3OOsBFq/05mKPvaQWCE
/NUrxSSEpgqaLJNJS5V4rgPKhSbg51GeIhkig+NkFIS7EtF/VCMXqaWd0lp7kYig
3arRF0BdZXLsMDhZKmi1JA+rcmCSQIYVaBDc29SMs/Wou99vVazQIs2e1Dkl06Ia
U7VeIwhEJykIl0MhBw+kwD3pNsiPth1xIg3DsDU+bq3gMNhcsl6Pj8FUP+PXdqaa
HSGOy2tnYB60xxFv4vfRiW7JaFse9+uaesRiPDOC5YUx47yP65xEhiCmKMXD+9xU
K/ZFYe9AvbJ4A65JjO/QQm5mg82cw5q4x/YQ1EC9T1w5kdjKJg9MkYoZmhHfttUZ
2zuGBFm9FUiW5SnRRp4Pil0aTAMgj8uZaxUdq1nGfyJo2p7TTNXKsE8YMkSwu93p
L914L64/bI2RLVQCciLZtVnVwAMffNpwtOJQzDDeUDI3i1ZItzehcsXXAWCN5xcQ
+0lF6Q3KlrDNGZCtO8vrbDioaFT25ikdAlF0B+pnadetQkXlLs8xdBxxF9lUZjgw
NqkbrYoY/c7Jf7dsWfC7fRqo3EjBxEFPwrdJJpvTtzgp4/Zk+dcHg0j4K2pFVMeT
sZZzDaWlCaRoKw+OSh2KyzWjGKSzh/mm+cdp/4T+bbhUseRF6eGb0Qk0lMyQv3ja
EE0GnyOYSlcavvIrqpx9v1iLEJLGWi58UiOASnzBlRh33nRqF+uoE5p6k/jgoUWC
CccW2SfyEfXJDOg6fqGyKw3XjAJQ0/t1qWbiIXxtNjH8haO9OgWUn3pKI6PjZwQk
6Eb5ow8WABZXb/pXJ/xjmLKjsmlxeqD31I2CaArV6hRCJoTKXkS2TWHCoHGRAPfL
jrDBiFJ1+KVnCtuGN1kxRG6fyIMMyFBG7qEzNnHmNnLGP19XHvgSJe0QYNdrkFpZ
iG+Kqz5bHcdEsucB0Efn/N7huu++R5XnSRYJnf6iPOTme6qwul3H1YQoaNNAbuch
u98JaciIiSGLesBU4P28FEC4kesslKWcM8Z4GfvX//9zqkB6T1E5/jUs+x6YtPhp
kMg9ZR195mP11E4MbgP9czk7HnK4Xgrns/DmXRdT1/d0dPtfng02jWjvOgNUQ1EJ
ZvFd9ZN67nV4ZiDtcVi3756m7UEI2p/2431ecpigy2OUA+d8YKYEbAreMDE7W4Iq
AlUalEiRmjwoerVIgQeB3oa2GElg2IN6llEa1UndI79ma13SJmgpLM+YUW+nS7k6
COiuKllSbLBSF9s4+ErEXciAAJCGFi7kfFDB59whv1IbmDEGNAamB6oibCewbF0T
xusyjhb2wA0KDq5C3ThlM5KU0g0ACSEuOl/A4AuubwxD7vvC6jiVFw/bCQrRJLJ6
UuEcBTp0vEecdF12NtQWPpg/+K2PYBi7Yzzc8DZcF97afFmZAtnF3EFLJltywjjK
qcGGCNyDj9MSBEnJigK7m0nYKjsOw5myt5LOhwWMr81OC7s6vgMBdf7qFCHiOUUB
5MwpAzjGgaR85uYqCpCOmW5pjRpRptEocJPxeW6Uy+aFPAEQu92HvFjHk/tvefGX
ttSsOPU5BC1J5xGZIoUfGPRFPYkjLauwQ34hGdQrbhJ3DrEe1pDAwd8/yIhzNp0o
N8uZDWKegLPrRg1B6CvmY3+Axiz0ZJZ86LOLa67ZsEkbWpQoy4F8D+z131JFrRcK
v0glY5b2GESUXtVxO668LqbmcO/eoDgBIhNvbrJT1QVgM/rr3poeeARGgff9OQ0i
FpsA4yk4uOqS/TS4OfpG6ymneGao1tJfktXmiR37cpGfkKjHPvI5kE8/KTOZSdSk
5RYjuCaWW363ysn7XA21Y9NiMYZesKCw8XdxVfVDZB6IphawYZ/a4cyvkYfD5HKw
QeLE7Rv7fGhlUPPWr1WQZOBgnnmAZoxNxkPhC4S62WvdiJNmiIeLrmD50n22zukH
aCj5S6sqXRuHdLB8FiZdi24s9tISBt0kAzK4bg3bvPoaqj3nSL8eirr1qWED/O+5
xxjJrR7fgY0BdzbqU5gXK22o6PLGzlOIpgFep12dnoYUVL2igRJfTAGSHyMPeJpv
e5mmAqxCz8FGgztZVP+v8MEkz/fDd/bIA0zkeA+0ugedbI/IkDkS25RdZkpvUpXH
2+SNL1RJyoYT/uoShAuVv6y9uyvoojX9XNDVmLX10ip8tSsTVbJx97MPzNSaTABe
Zbc5rgU4FJnUIIjb4igmccUrdW7ZknKk2cV9xRv7BHFYAl4hsitcsdKe8IPdX+2E
WOXl2i2+ndUkzoqGlr4q8nOgAcr53Msjnn1ljasWHXDpeXRW+kraX+88UUmv9zEf
T4gyl7shs/J24IlgHhJbqD5g10thG9esp8KvaxgeHyuBVpPniWWrecwajKFjfVKp
J9EcxDXRUZH3c4jDIWxpKsGQFFsx9e7p286tcUXwGDBFkYOao9NOcyllltRq+ECH
93Sc6hLp/Fd7hIAdZFbnjaemp2llA81cNKIVRUpJ4OyoVSOwhMp+j3m5SOmJdAxu
SWcMKENRU6RSjqZOt15acOktCRRrMbLSxZY+fW+1g5IvA1j6mFiK57F569ouYZeP
zvMgPgkDN/ATMd/RkHAWq5/EjeNmhey52XnHSqyAPmP4mX9qoaYtRYgBTGrKEFNo
05V14xLunvGz+FEsqZ/IwSZYbYkGCpfczQWlRLnLkb8X7gbL/esfKfb3tSsbOluZ
F/bAHniMg51uU2MmpspuWR+SzyWuabWiCkEq7lvXLTwdJGBYduaRH9u14bBCWUuA
-----END RSA PRIVATE KEY-----
quit
% Key pair import succeeded.
router(config)#
Now assign it to SSH again:
router(config)#ip ssh rsa keypair-name example-restored
router(config)#
Jun 15 11:25:36.619: %SSH-5-DISABLED: SSH 1.99 has been disabled
Jun 15 11:25:36.623: %SSH-5-ENABLED: SSH 1.99 has been enabled
router(config)#
And try logging in again:
demo-mac:~ demo$ ssh demo@<cleared>.205
Password:
router#
All set!
EDIT: Note: When importing the key, make sure there are no extra spaces around the key info. If you copy and paste from a console, this may put trailing spaces on every line and you need to remove those before importing.
some_guy_long_gone
- 3,052
- 1
- 19
- 30
-
1The private key is encrypted with 3des using the password "somepassword" in the example. However, 3des being what it is, I totally agree with you about protecting the data. I also would not recommend this choice, I would go with a scripted new key. Mostly wanted to figure out how to do it as I didn't know prior to writing the post. – some_guy_long_gone Jun 15 '13 at 12:02
-
1I like this idea, maybe extend it with another version where private key is never exported. Suppose control-plane is broken and you replace it with new and generate all new keys. It's sufficient that at this time new public key is exported and stored in central NMS location, directory where NMS box ssh checks for keys. This allows NMS to verify keys, while removed necessity to replace private key with previous private key. – ytti Jun 15 '13 at 12:05
-
sh ip ssh only shows the public key in the same format as known_hosts accepts. No private key is pulled out. So when you generate a new key, you just pull that public info out and update your known_hosts file. – some_guy_long_gone Jun 15 '13 at 12:09
11
Backing up the host keys to replace them is more trouble than it's worth.
If you don't want your scripts to barf on key changes (in *nix), run ssh like this...
ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no username@hostname
This tells the ssh client to use an empty Known Hosts file and do not force strict key checks.
As mentioned in the comments, you are removing protections associated with SSH key-checking by disabling host-key checking. You can mitigate this risk by running an IDS in the environment, or by using very strict Layer2 security features on that Vlan:
arpwatch- Dynamic ARP Inspection, or host-level static ARP practices
- DHCP Snooping
- Ethernet port-security
Mike Pennington
- 29,876
- 11
- 78
- 152
-
4I agree with Mike, backing them up is usually not worth the effort. My solution for when I ran into this issue with Rancid, was an alias called "fixrancid" which was simply: alias fixrancid='rm /var/lib/rancid/.ssh/known_hosts' Probably not the best way to go about it, but it works for those times when the SSH keys were re-generated on a box in the network. And it was easy to tell other engineers to simply run "fixrancid" on the box to resolve the issue. – Brett Lykins Jun 14 '13 at 14:30
-
5The flip side here is, that all security is lost. We're protecting the secret keys so carefully that we sacrifice whole ssh security model because of it. Clearly smaller sacrifice would be if secret key would be just visible in running-configuration. – ytti Jun 14 '13 at 15:05
-
4@ytti, it's not visible in the running config and it's an oversimplification to say that "all security is lost". Security is lost *if* there is a compromise... presumably people still manually ssh to the routers (which means host-key checking is enabled). Furthermore, let's not assume that backing up the host key is *more* secure... you now must protect the location where the keys are stored... those keys are *plain text* and are much more dangerous than a Type 5 enable secret. Once you know the private host key, you can decrypt all traffic for that host. – Mike Pennington Jun 14 '13 at 15:35
-
3If your systems don't verify the key just accept any key offered then anyone can be MITM. Clearly it would be more secure to have the key shown in configuration backups. – ytti Jun 14 '13 at 15:37
-
@ytti, in your subjective evaluation it's more secure to have the host key in the running config; however, not everyone would agree with that statement. Is it "more secure" to have your enable secret stored as plain-text in the running-config? If the answer is no, then consider that it might not be more secure to store an RSA private key for the control plane of the system in the running config. Bottom line, this is all an academic debate because Cisco isn't giving us another option anyway. – Mike Pennington Jun 14 '13 at 16:04
-
Option could be to always store publickey in central place when ever 'crypto key generate' is ran and keep verifying key. Not verifying key means whole world knows the key, having key in youtube comment means some people know it, not all. I think it's objectively more safe to store it insecurely than not verify it all. – ytti Jun 14 '13 at 16:07
-
Storing the key insecurely compromises all communication to the hosts to *passive* decryption attacks; therefore, it is not "objectively" more safe. – Mike Pennington Jun 14 '13 at 16:12
-
2Probability of leaking your config backups <1, probability of MITM:n when key is not verified 1. – ytti Jun 14 '13 at 16:23
-
1Both ytti and Mike have valid points. Security can be relaxed a bit if the environment is otherwise controlled, but at the cost of not knowing when the SSH fingerprint changed. Mike properly qualified his answer by stating how to mitigate with L2 security that should be coupled with access-list controls on the router to restrict where the SSH clients can originate. And having the keys in the backup config isn't necessarily a great option either. I'm more on the side of ytti on this, but Mike's answer looks valid to me given the question. **Further discussion should be taken into chat** – generalnetworkerror Jun 14 '13 at 21:24
-
3@ytti, I think you should consider a different way of calculating statistics, because the probability of MITM attack is not increased simply because a portion of ssh sessions dont verify keys. It means you cant detect a potential MITM attack with the scripts... that attack does not automatically occur (which is what we must assume to believe your assertion that probability of MITM==1 with ssh key checks off) – Mike Pennington Jun 15 '13 at 11:02
-
I guess we can assume probability of actual attack is same in both scenarios. The probability of success in MITM would be 1 the probability of success with insecurely stored private key would be <1, unless we assume that configuration backups are always leaked. – ytti Jun 15 '13 at 11:07
-
@ytti, we can assume the probability of a successful attack is close to zero if the countermeasures in my answer are implemented. – Mike Pennington Jun 15 '13 at 11:53
-
They are LAN specific measures. At least in my region access to fibres is rather easy to arrange, shared key gets trade people to many places and of course in the end, fibres run unguarded in the nature. You would experience potentially rapid loss of link (or if your carrier-delay >0ms you wouldn't experience it) when MITM box is installed, you wouldn't experience MAC changing at all. However your measures do protect from classic LAN attacks. – ytti Jun 15 '13 at 11:56
-
Anyone installing a router should put an OOB LAN access on it... you control the OOB port – Mike Pennington Jun 15 '13 at 11:59
-
Making it LAN does not remove the attack vector of putting MITM box on the wire, no ARP, no MAC changes. It removes the convenient attack of not needing any physical work though. So attacker needs more motivation. But at least in my neck of the woods accessing any operators physical infra is easy, provided you have multiple pops. – ytti Jun 15 '13 at 12:13
-
-
Then indeed we might as well use telnet, provided we solved the issue of replacing the IPsec box without losing trust. – ytti Jun 15 '13 at 12:24
-
1Use whatever suits your requirements... just understand that there are good solutions to the problems you mention, and it isnt a good idea to omit OOB mgmt in a remote DC anyway. – Mike Pennington Jun 15 '13 at 12:28
-
I can't comment on your scale perhaps, but our NMS saves and verifies the keys. In the unusual circumstance that we actually have to physically replace devices something simply pings me and says "wtf ssh key mismatch", I can clear out the old key for that device. Basically, I do the "fixrancid" (though not rancid) as above, but only removing a single SSH key for a single host. – Adam Jacob Muller Jun 15 '13 at 19:28
3
Simple answer... it's not possible to get at the keys directly. They're stored in the nvram private-config which is not user accessible. If the key was generated in the default fashion, then it wasn't set as exportable, and thus cannot be retrieved.
@legioxi has already provided the "long answer" (make they keys exportable and export/import them)
One other option is the use of a "secure usb token" (usbtoken#) for key storage. The token can be moved when replacing a router. However, that token is still a single copy. So the more involved export method may be needed.
On the plus side, the keys only need to be backed up once. (the whole point being the key never changes -- even when the hardware is replaced.)
[See also]
Ricky
- 31,438
- 2
- 43
- 84