Eigenen Server betreiben?

Was du sagst ist nicht falsch, aber das macht meine Aussage noch lange nicht zum Bullshit.
Ich bin nun schon häufiger über diese Anmerkung gestolpert und wollte sie auch hier einbringen, das Thema scheint zumindest schwer diskutiert zu werden (z.B. hier, hier, hier oder hier).

Für mich Grund genug, es in Betracht zu ziehen.
Du hast recht, der Hostkey sollte ein vollständiges Personifizieren als SSH-Server ausschließen, aber das wälzt die Sicherheit auf den Anwender ab, und so sollte Krypto mMn nicht gemacht werden.

Dieses Szenario ist bei einem fähigen Administrator nicht möglich
Und genau da liegt das Problem. Nicht jeder, nicht einmal die besten Administratoren, sind in jedem Fall immer fähig.
Was, wenn ich zwischenzeitlich meinen PC neu aufgesetzt habe und deshalb die KnownHosts nicht mehr existieren?
Oder wenn ich mich von einem anderen PC verbinde (klar, eigentlich sollte man eh auf PubKey Authentication setzen und das ist etwas, was man typischerweise von seinem eigenen Rechner aus macht, aber ich glaube nicht daran, dass das jeder tut).
Oder wenn ich eine neue Domain registriert habe, die auf den Server zeigt und mich jetzt mit der statt mit der IP einlogge? Für SSH ist das dann ein neuer Host.
Die allermeisten kennen den Fingerprint ihres Servers wohl nicht auswendig und würden ihn in dem Fall wohl akzeptieren.
Im Übrigen wollte ich eigentlich nur googeln, wie die Standardeinstellungen für StrictHostKeyChecking bei den verschiedenen Unixen so aussehen und bin dabei auf endlos viele Foreneinträge gestoßen, in denen Menschen nachfragen, wie sie dieses Feature abstellen können. Einfach aus dem Grund, weil sie in DHCP-Netzwerken arbeiten und ihre SSH-Maschinen häufig die IP wechseln. Klar ist das schlecht, aber bring das mal einem Entwickler bei, der jeden Tag wieder genervt feststellt, dass er sich nicht verbinden kann.

Zusammengefasst kann man denke ich sagen, dass ein Port >1024 wohl kein Sicherheitsproblem darstellt, wenn man alles richtig konfiguriert, und zwar von Client UND von Hostseite. Ein Port <1024 bereitet aber auch keine Probleme und ist meiner Meinung nach deshalb vorzuziehen.

Ursprünglich ist diese Problematik sogar (mit) verantwortlich dafür, dass es so etwas wie reservierte Ports für den Superuser überhaupt gibt. Warum sollte man die dann also nicht auch nutzen?
 
tiash schrieb:
Für mich Grund genug, es in Betracht zu ziehen.
Du hast recht, der Hostkey sollte ein vollständiges Personifizieren als SSH-Server ausschließen, aber das wälzt die Sicherheit auf den Anwender ab, und so sollte Krypto mMn nicht gemacht werden.


Und genau da liegt das Problem. Nicht jeder, nicht einmal die besten Administratoren, sind in jedem Fall immer fähig.
Was, wenn ich zwischenzeitlich meinen PC neu aufgesetzt habe und deshalb die KnownHosts nicht mehr existieren?
Oder wenn ich mich von einem anderen PC verbinde (klar, eigentlich sollte man eh auf PubKey Authentication setzen und das ist etwas, was man typischerweise von seinem eigenen Rechner aus macht, aber ich glaube nicht daran, dass das jeder tut).
Oder wenn ich eine neue Domain registriert habe, die auf den Server zeigt und mich jetzt mit der statt mit der IP einlogge? Für SSH ist das dann ein neuer Host.

Das sind alles Probleme, die existieren, wenn du dein Heimatverzeichnis verlierst. Das sollte nicht der Fall sein, da jeder fähige Anwender Backups haben sollte. Wer keine Backups hat und macht, der sollte sowieso kein Admin sein. Sobald der Anwender ein Backup hat, kann er seine known_hosts-Datei von dort beziehen.

tiash schrieb:
Die allermeisten kennen den Fingerprint ihres Servers wohl nicht auswendig und würden ihn in dem Fall wohl akzeptieren.
Im Übrigen wollte ich eigentlich nur googeln, wie die Standardeinstellungen für StrictHostKeyChecking bei den verschiedenen Unixen so aussehen und bin dabei auf endlos viele Foreneinträge gestoßen, in denen Menschen nachfragen, wie sie dieses Feature abstellen können. Einfach aus dem Grund, weil sie in DHCP-Netzwerken arbeiten und ihre SSH-Maschinen häufig die IP wechseln. Klar ist das schlecht, aber bring das mal einem Entwickler bei, der jeden Tag wieder genervt feststellt, dass er sich nicht verbinden kann.
Es gibt keine Gründe dafür, dass Entwickler Maschinen selbst warten oder aufsetzen. In jedem vernünftigen Firmennetz gibt es Teilnetze, die keinen DHCP-Server haben. Eine Alternative wäre ein statisches Lease, aber das wäre ja zu einfach.

tiash schrieb:
Zusammengefasst kann man denke ich sagen, dass ein Port >1024 wohl kein Sicherheitsproblem darstellt, wenn man alles richtig konfiguriert, und zwar von Client UND von Hostseite. Ein Port <1024 bereitet aber auch keine Probleme und ist meiner Meinung nach deshalb vorzuziehen.

Ursprünglich ist diese Problematik sogar (mit) verantwortlich dafür, dass es so etwas wie reservierte Ports für den Superuser überhaupt gibt. Warum sollte man die dann also nicht auch nutzen?

Primär machen abgeänderte Ports - falls es keinen triftigen Grund dafür gibt - nur Aufwand, sowohl in der Konfiguration, als auch im täglichen Leben, da es, wie in den von dir verlinkten Beiträgen erwähnt, Programme gibt, die versuchen sich nativ auf den Standardport zu verbinden oder die Konfiguration dafür mühselig ist. Das fängt schon bei Git an, wofür ich bereits ein Profil in der Config-Datei von ssh anlegen muss, um einen anderen Schlüssel als id_rsa für Public-Key-Authentication zu nutzen.

Privilegierte Ports gibt es aus dem Grund, dass beliebige Programme nicht den eigentlich dafür vorgesehenen die Ports stehlen. Es ist ein Sicherheitsfeature.

Grüße,
Thermi
 
Zuletzt bearbeitet:
Thermi schrieb:
Das sind alles Probleme, die existieren, wenn du dein Heimatverzeichnis verlierst. Das sollte nicht der Fall sein, da jeder fähige Anwender Backups haben sollte. Wer keine Backups hat und macht, der sollte sowieso kein Admin sein. Sobald der Anwender ein Backup hat, kann er seine known_hosts-Datei von dort beziehen.


Es gibt keine Gründe dafür, dass Entwickler Maschinen selbst warten oder aufsetzen. In jedem vernünftigen Firmennetz gibt es Teilnetze, die keinen DHCP-Server haben. Eine Alternative wäre ein statisches Lease, aber das wäre ja zu einfach.



Primär machen abgeänderte Ports - falls es keinen triftigen Grund dafür gibt - nur Aufwand, sowohl in der Konfiguration, als auch im täglichen Leben, da es, wie in den von dir verlinkten Beiträgen erwähnt, Programme gibt, die versuchen sich nativ auf den Standardport zu verbinden oder die Konfiguration dafür mühselig ist. Das fängt schon bei Git an, wofür ich bereits ein Profil in der Config-Datei von ssh anlegen muss, um einen anderen Schlüssel als id_rsa für Public-Key-Authentication zu nutzen.

Privilegierte Ports gibt es aus dem Grund, dass beliebige Programme nicht den eigentlich dafür vorgesehenen die Ports stehlen. Es ist ein Sicherheitsfeature.

Grüße,
Thermi

Zusätzlich, bringen geänderte Ports keine Mehrwert an Sicherheit! Warum?, weil bei einem Port Scan sofort der SSH Port aufgelistet wird. Ob das nun 22 oder 222 der 1021 ist, ist vollkommen egal. Scannt doch mal einfach eure Router/Server mit nmap :)
 
dalini, beim Port verlegen geht es ja nicht um das Verstecken, sondern darum die Logdateien etwas ruhiger zu halten. Die meisten automatisierten Angriffe machen keinen Portscan, das würde einfach zu lange dauern.
 
Wen kratzen die Logdateien? Um die kümmert sich Logrotate und archiviert bzw. entsorgt den alten Mist
 
Ich sag dir nur was der Grund dahinter ist, dass manche Leute ihren Port verlegen. Manche fühlen sich vielleicht auch wohler damit, wenn sie den Angriffssturm aus dem großen bösen Internet ein wenig reduzieren können.
 
Zurück
Oben