bigvic Geschrieben 11. Februar 2009 Geschrieben 11. Februar 2009 (bearbeitet) Hi, also ich hab bei meinem Cisco Switchen eine Authentifizerung via TACACS+-Server implementiert. Nun möchte ich eine Art "no password" Authentifikation für meine automatisierten Scripte machen. Die machen ein stinknormales ssh <command> zu den Switchen. Im Prinzip soll es so funktionieren wie mit privat/public Key bei einem ssh-server, aber eben gegen den Tacacs+-Server. Wenn User X von host Y kommt, dann darf er rein, ohne PW. Jetzt ist die Frage - wie mach ich das? Danke für Tipps und/oder Links. ciao, vic Bearbeitet 11. Februar 2009 von bigvic Zitieren
Crash2001 Geschrieben 12. Februar 2009 Geschrieben 12. Februar 2009 Hmmm.... also den User und Passwort kannst du ja auch mitgeben... sollte doch normal nicht das Problem sein, oder? einfach einen Tacacs-Account nehmen, der die benötigten Rechte besitzt auf den Switchen. Zugriff einschränken kannst du natürlich noch auf den Switchen per Access-Liste. Also z.B. nur von IP-Adresse a.b.c.d und/oder Netzwerk e.f.g.h/n erlauben. Eine Identifikation nur per Key ist mir nicht bekannt. Zitieren
bigvic Geschrieben 12. Februar 2009 Autor Geschrieben 12. Februar 2009 Hi, naja user+passwort will ich eben nicht mitgeben - wäre grob fahrlässig, dass irgendwo im Klartext zu hinterlegen. Aber ich habe herausgefunden, dass der "normale" sshkey Mechanismus funktioniert, obwohl in der aaa authentication "group" vor "local" kommt (anderstrum lässt das irgendwie das IOS nicht zu?!). Komisch, aber ok. Aergerlich ist so halt, dass ich auf allen Switchen einen user erstellen und das keyfile hinterlegen muss, anstatt es zentral am Tacacs-Server zu machen. Naja was solls, aber hauptsache es geht zumindest irgendwie. ciao, vic Zitieren
Crash2001 Geschrieben 12. Februar 2009 Geschrieben 12. Februar 2009 Also ich sehe keinen wirklichen Unterschied, ob nun ein Zertifikat lokal auf dem PC liegt und übergeben werden soll, oder User und Passwort. Beides ist sicherheitstechnisch betrachtet ziemlich unsicher und könnte ausgenutzt werden. Zitieren
bigvic Geschrieben 12. Februar 2009 Autor Geschrieben 12. Februar 2009 Also ich sehe keinen wirklichen Unterschied, ob nun ein Zertifikat lokal auf dem PC liegt und übergeben werden soll, oder User und Passwort. Beides ist sicherheitstechnisch betrachtet ziemlich unsicher und könnte ausgenutzt werden. Das ist ein Megaunterschied - in einem Fall ist das Passwort im Klartext irgendwo in einem Script abgespeichert und im anderen Fall hat man seinen privaten Schlüssel (ggf. mit Passphrase). Die Public-Key-Authentifizierung ist so ziemlich überall Standard auf der Welt und eines der sichersten Authentifizierungsverfahren. Wenn das zu unsicher ist, dann kannst automatisierte Steuerung/Verteilung/... von jeglichen Systemen abschalten. Einige unixoide Betriebssystem lassen Anmeldung als admin/root mit User/Kennwort defaultmässig garnicht mehr zu, sondern erlauben das nur noch mit dem PK-Verfahren. Anyway - ich bleib dran, ob ich das noch zentral abspeichern kann, aber ich glaub TACACS+ kann das wirklich nicht. Kann das vielleicht RADIUS? (Wobei icheigentlich keine Lust hab ein Radius-Server aufzusetzen ) ciao, vic Zitieren
Crash2001 Geschrieben 12. Februar 2009 Geschrieben 12. Februar 2009 Von der Übertragung übers Netz ist das ein Unterschied, das stimmt. Wobei auch nur der Username und nicht das Passwort im Klartext übertragen wird bei der Tacacs-Authentifizierung. wenn aber Zugang zum Rechner besteht, dann kommt das von der Sicherheit so ziemlich aufs gleiche hinaus. Ob man nun das Passwort vom tacacs-User, oder die Passphrase des Keys nicht kennt ist doch relativ egal. Wen man das Passwort vom Key manuell eingeben muss, kann man auch direkt die Tacacs-Authentifizierung nutzen und das Passwort dort raus lassen. wenns im Script mitgespeichert ist, kann man auch genauso User und passwort der Tacacs-Authentifizierung ins Script schreiben. Zitieren
Empfohlene Beiträge
Dein Kommentar
Du kannst jetzt schreiben und Dich später registrieren. Wenn Du ein Konto hast, melde Dich jetzt an, um unter Deinem Benutzernamen zu schreiben.