OpenSSH Infrastruktur + Management (private/ public keys, known hosts etc.)

ao

Aktives Mitglied
Mitglied seit
15 Aug 2005
Beiträge
2,158
Punkte für Reaktionen
2
Punkte
38
Hallo,

ich suche nach Möglichkeiten des Managements meiner diversen private (.ssh/id_rsa) und public (.ssh/id_rsa.pub) OpenSSH Keys auf verschiedenen Systemen (Fritzbox, PC, NAS).
Ich habe etliche Infos zu OpenSSH etc. gefunden, aber das manuelle Herumgeschiebe etc. ist mir zu mühselig.
Wie macht Ihr das? Hat jemand eine Idee, was es dazu an intelligenten Lösungen gibt? Vielen Dank!
 
Was genau verstehst Du unter Management, und wie viele Keys hast Du denn?

Außerdem, was ist an der Frage anders, als wenn es sich um gewöhnliche Server handeln würde?
 
Es handelt sich um "Server", richtig. Da ich aber (trotz meiner vielen Beiträge
icon11.gif
) diesbzgl. nicht wirklich sattelfest bin, wollte ich mal fragen, wie Ihr Profis das ohne große Klimmzüge einrichtet und hin und wieder auch einmal die public/ private keys wechselt.

Wie ich oben schrieb, habe ich prinzipiell 3-4 (1x virtuell) Server. Aus Gründen der Sicherheit nehme ich mal an, dass es sinnvoll ist, auf jedem Server einen anderen public key zu verwenden und nicht überall denselben.

Nun ist es so, dass ich mich von remote an meiner FB 7170 (Freetz + dropbear) mittels private key (RSA1) anmelde. Der passphrase-geschützte key (key.ppk) befindet sich auf einem USB-Stick, der wiederum PW-geschützt ist. Ja, ich bin paranoid. ;)

Nun habe ich festgestellt, dass bis auf die FB alle anderen Server per ssh ohne key (aber natürlich mit PW) zugänglich sind. Nun würde ich aber gerne alle auf key authentication umstellen. Dazu müssten natürlich die private keys auf dem jeweiligen Client liegen, die zugleich auch Server sind, da ich von jedem "Gerät" aus jedes andere erreichen will. Oder ist das schon ein schlechter Ansatz? Vielleicht ist es ja sinnvoller, alles zu verrammeln und nur den remote bzw. local Zugriff auf die FB (von allen Geräten) zuzulassen, aber den Zugang auf die anderen Geräte nur von der FB aus und nicht untereinander?

Zugriffe per ssh auf die Server (außer der FB, die auch von remote erreichbar ist) sollen nur aus dem lokalen Netz erlaubt sein.
Ich nehme mal an, dass hierzu in "/etc/hosts.allow" ein
Code:
sshd : LOCAL : allow
sshd : ALL : deny
und in "/etc/hosts.deny" ein
Code:
ALL : PARANOID
korrekt ist. Wobei damit ja nur sshd-Zugriff aus dem lokalen Netz erlaubt ist. Wenn ich das auch auf der FB so mache, geht ja (außer eben ssh) gar nichts mehr, und das wäre schlecht. Auch auf den anderen Servern werden ja außer ssh noch ein paar Dienste benötigt. Daher ist diese Idee evtl. doch nicht so gut und einfach nur "All : LOCAL" in "hosts.allow" und "ALL : PARANOID" in "hosts.deny" sinnvoller.

Für ssh speziell gibt es ja noch eine "from" pattern list in "~/.ssh/authorized_keys", die man verwenden kann, z.B.:
Code:
from="*.example.org" ssh-rsa AAAAC2KzbD3…
Die ".ssh" Verzeichnisse auf den Servern sind alle "drwx------". Sorry, ich schweife ziemlich ab...

Also mir geht es nun primär darum zu erfahren, wie man das alles möglichst elegant einrichtet; und zwar so, dass der Aufwand auch bei z.B. monatlichem Wechsel der keys noch im Verhältnis zur Sicherheit steht.

Kann man so eine Art zentrale Schlüsselstelle auf der FB einrichten? Wenn da mal einer eingebrochen ist, ist sowieso alles zu spät. Da würden dann von der FB verschiedene keys auf den anderen Servern wohl wenig nützen. Also doch überall denselben key verwenden?

Sorry, dass das evtl. Trivialitäten sind. Umso dankbarer bin ich für hilfreiche Hinweise.
 
Zuletzt bearbeitet:
Vielleicht kann ein Moderator dem Thema eine geeigneteren Platz spendieren.

Zunächst einmal muß man unterschieden zwischen dem Server Key und dem Client Key. Einen Server Key gibt es grundsätzlich (oder zwei, DSA und RSA). Der Client Key ist optional und ersetzt das Paßwort. Aus der Beschreibung oben gehe ich davon aus, daß es um den Client Key geht.

Auf dem Server gehört nicht der Client Key hin, sondern nur der öffentliche Teil davon, und zwar in dir Datei .ssh/authorized_keys. In dieser Datei können auch mehrere Schlüssel eingetragen werden. Es gibt aber eine relativ niedrige Obergrenze der Keys, die man zum Login ausprobieren kann. Diese Datei kann man einfach mit rsync übertragen. Beim ersten Mal braucht man dazu ein Paßwort, beim nächsten Mal sollte der Zugriff über den Key möglich sein.

Da der CLient Key Dich identifiziert, ist die Frage, warum Du verschiedene Keys für verschiedene Server nutzen willst. Wenn jemand auf dem Server den öffentlichen Teil des Keys findet, hast er nichts davon. Was ist also der Vorteil von verschiedenen Keys?

Wenn Du vom einen Server auf den anderen zugreifen willst, ist die Frage, ob Du wirklich dort den privaten Key eines anderen Servers ablegen willst. Einfacher ist es, einen Key-Agent zu verwenden und diesen zum Server weiterzuleiten. Einen solchen Agenten gibt es sowohl für Putty als auch für Linux. Wenn jemand die Kontrolle über den einen Server bekommt, ist das zwar trotzdem nicht gut, aber der Zugriff auf einen anderen Server ist nur möglich, während Du angemeldet bist.
 
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.