Cisco 3560: SSH crypto issue bij restore?

[Verwijderd]

Ik ben bezig een disaster recovery plan te maken voor onze Cisco 3560 switches.

Dat gaat prima met behulp van een TFTP server waarmee ik de running configs van de machines download, die ik dan later kan restoren op een vervangende switch mocht de huidige het begeven.

Nu waarschuwde een oud collega mij om niet de SSH encryptie (die wij hebben op onze switches) op de vervangende switch te prakken omdat je de switch dan zou kunnen weggooien. De gegenereerde crypto key zou aan het mac adres gekoppeld zijn en dan dus de weg kwijt raken wanneer dat op een ander mac adres gezet wordt.
Klinkt plausibel, maar ik kan daar eigenlijk niets over terug vinden in de (zeeeeeer uitgebreide) cisco documentatie op het Inet.
Ook bij alle beschrijvingen van een restore van de running config wordt dit voor zover ik kan zien nooit te berde gebracht.

2 vragen:
a. klopt het wel wat hij zegt?
b. Indien ja, kan ik dan gewoon uit de running config het hele crypto verhaal verwijderen en dan pas die config laden?
(en daarna op de switch weer een crypto key generate... ) doen?

Cisco cracks, laat u horen!

[it0]

Met "show crypto key" zal er in de output staan of de key exportable is.

PS kijk ook eens naar het archive commando en gebruik iets anders dan TFTP als deze server publiek staat.

[ Voor 43% gewijzigd door it0 op 06-03-2017 14:29 ]

[ik222]

Running configs kan je gewoon terugzetten, alleen daarin zitten de RSA keys niet. Je zult op een nieuwe switch dus alsnog even een nieuwe RSA key moeten genereren alvorens je weer via SSH kan inloggen. Overigens als je SSH inlog het niet doet is je switch niet kapot, via een console kabel kan je alsnog inloggen en de keys fixen.

[Verwijderd]

ik222 schreef op maandag 6 maart 2017 @ 14:33:
alleen daarin zitten de RSA keys niet.

Toch zie ik in mijn running:


crypto pki certificate chain TP-self-signed-3816665728
certificate self-signed 01
30820251 308201BA A0030201 02020101 300D0609 2A864886 F70D0101 04050030
31312F30 2D060355 04031326 494F532D 53656C66 2D536967 6E65642D 43657274
69666963 6174652D 33383136 36363537 3238301E 170D3933 30333031 30303034
34375A17 0D323030 31303130 30303030 305A3031 312F302D 06035504 03132649
4F532D53 656C662D 5369676E 65642D43 65727469 66696361

en dan nog een hele riedel er achteraan, vervolgens quit !!!

Maar dat kan dus volgens jou geen kwaad als je die op andere hardware zet?

[Verwijderd]

it0 schreef op maandag 6 maart 2017 @ 14:27:

PS kijk ook eens naar het archive commando en gebruik iets anders dan TFTP als deze server publiek staat.

Thanks, ga ik even onderzoeken. (Al is die TFTP server een lokale management server maar goed.)

[ik222]

Ooh wacht bij die switches zie je dat nog wel in de running-config inderdaad. Maar dan nog ga je hier nooit je switch mee slopen, of een import zo daadwerkelijk werkt weet ik niet zeker (ik denk eigenlijk van wel) maar als je het niet werkt kan je altijd nog via de console kabel alsnog een nieuw keypair genereren.

[ Voor 4% gewijzigd door ik222 op 06-03-2017 15:07 ]

[Verwijderd]

ik222 schreef op maandag 6 maart 2017 @ 15:04:
Ooh wacht bij die switches zie je dat nog wel in de running-config inderdaad. Maar dan nog ga je hier nooit je switch mee slopen, of een import zo daadwerkelijk werkt weet ik niet zeker (ik denk eigenlijk van wel) maar als je het niet werkt kan je altijd nog via de console kabel alsnog een nieuw keypair genereren.

Klopt die staat daar in.

Net nog even gespard met mijn ex-collega: volgens hem kun je daarna GEEN SSH key meer generen en dus nooit meer via SSH in je switch kunnen komen. Je moet hem dan opsturen naar cisco schijnt.

En om nou iedere keer met een kabel erheen te wandelen daar word ik niet zo vrolijk van.

Dus dit is wel degelijk iets om rekening mee te houden bij dit type switches!

[ik222]

Verwijderd schreef op maandag 6 maart 2017 @ 15:46:
[...]


Klopt die staat daar in.

Net nog even gespard met mijn ex-collega: volgens hem kun je daarna GEEN SSH key meer generen en dus nooit meer via SSH in je switch kunnen komen. Je moet hem dan opsturen naar cisco schijnt.

En om nou iedere keer met een kabel erheen te wandelen daar word ik niet zo vrolijk van.

Dus dit is wel degelijk iets om rekening mee te houden bij dit type switches!

Dat je hem moet opsturen naar Cisco dan is onzin, je kant altijd via de console kabel de bestaande RSA key verwijderen en een nieuwe genereren.

code:

crypto key zeroize rsa

Daarna kan je gewoon een nieuw keypair genereren.

En nee je moet niet elke keer naar die switch met een kabel, alleen om je SSH toegang weer te fixen.

[ Voor 9% gewijzigd door ik222 op 06-03-2017 15:49 ]

[Verwijderd]

ik222 schreef op maandag 6 maart 2017 @ 15:48:
[...]

Dat je hem moet opsturen naar Cisco dan is onzin, je kant altijd via de console kabel de bestaande RSA key verwijderen en een nieuwe genereren.

code:

crypto key zeroize rsa

Daarna kan je gewoon een nieuw keypair genereren.

En nee je moet niet elke keer naar die switch met een kabel, alleen om je SSH toegang weer te fixen.

Dit is waardevolle input.
Eind van de week ga ik dit testen en dan zal ik dus gewoon de key meeplakken in de nieuwe config, vervolgens via de console die remove uitvoeren en daarna weer een nieuwe crypto key generate uitvoeren.

Ben wel benieuwd.

[winux]

Ik neem aan dat wanneer je een disaster recovery procedure opzet, je ook regelmatig een (automatische) backup van je switche(s) maak cq laat maken. En deze gebruik bij de recovery, en niet 1 config voor elke switch gebruik?

Gezien het een layer 3 switch is, neem ik aan dat je ook dynamische routing protocollen gebruik met verschillende neighbors, al dan niet met encrypted messages tussen de neighbors.

[ Voor 26% gewijzigd door winux op 06-03-2017 17:07 ]

[Verwijderd]

Op iedere switch wordt nu na een wijziging een kopie van de running config naar een tftp server geupload.

Deze switch routeert niet, er zijn wel switches die ook een routetabel hebben.

De enige encryptie is de SSH encryptie.

Ik ben nog even aan het nadenken over het vervolg, want aangezien de vlan tabel niet meegenomen wordt in de run wil ik ook een uitdraai van de vlan database hebben.
Dat is bij ons best belangrijk omdat wij op iedere switch verschillende klanten hebben zitten ipv gewoon een eindgebruiker per poort.
Dat zit hier dus even iets ingewikkelder in elkaar dan op een "gewone" kantoorswitch waarbij je gewoon de vlans gedefinieerd op je eigen LAN gebruikt bijvoorbeeld en de vlans verschillen dus per switch.
(een vlan per klant)

[winux]

Vlan information staat in de vlan.dat file.
Deze zou je mee kunnen exporteren naar de tftp server.

En eventueel kun je gebruik maken van VTP mechanisme.