Beim CNAME für www hast Du einen Fehler: Nach „s.eu“ soll ein Minuszeichen stehen, kein Punkt. Probier mal, ob es dann klappt.
P.S.: DNS ist ein öffentliches System. Das Überdecken mit gelber Farbe im Screenshot hättest Du dir sparen können.
Beiträge von Zierleiste
-
-
You have to do it vice versa: A pair of private and public keys is generated on your dev machine and the public key goes to your cloud server(s). The private key never leaves your dev machine.
There are so many tutorials out there, e.g. https://community.netcup.com/en/tutorials/login-per-ssh-key
-
Borgqueen Vielleicht möchtest Du auch mal einen Blick auf das Zertifikat deiner Homepage werfen. Es gilt derzeit nur für "www" und nicht für die Domäne selbst und es kommt entsprechend zu Zertifikatsfehlern beim Aufruf.
-
Another problem might be that your client is using a public key for authentication not suitable for this server.
You can avoid this by ssh root@yourserver -o PubkeyAuthentication=no -
Did you add root to the list of AllowUsers?
P.S.: I would not recommend root-login via ssh at all. It is preferred to login as non-privileged user and then using sudo to elevate privileges.
-
Die Source Ports darfst Du bei eingehenden Regeln nicht vorgeben, das externe System wählt diesen ja dynamisch aus der „ephemeral“ Port Range. Bei deinem chmk Dienst müsstest Du mal prüfen, ob das auch zutrifft, den kenne ich nicht.
-
Dann fehlt ziemlich sicher eine Regel für DNS - Du hast ja auch noch deine Docker Container - setze die analog zu deiner NTP-Regel auf, nur mit Port 53 statt 123.
-
Ja genau, von Smartphones, Laptops etc. Zum WireGuard Server bei Netcup, und über den dann ins Internet
Wenn Du die netcup-Firewall abschaltest, dann funktioniert dein VPN aber?
Was ist eigentlich mit DNS: Benutzt Du die netcup DNS-Server oder andere? Im zweiten Fall würden nämlich Regeln für DNS in deiner Firewall fehlen.
-
Also ich nutze OpenVPN und meine Konfiguration ist praktisch identisch mit deiner aus #7 bis auf die abweichene Portnummer (1194).
In welcher Richtung willst Du denn die VPN-Verbindung aufbauen: Von einem externen Client (PC, Smartphone) zu deinem Server bei netcup oder wie genau?
-
Standardmäßig sind ausgehend alle Verbindungen über implizite Regeln erlaubt (gilt für TCP und UDP separat). Sobald Du aber andere ausgehende UDP-Regeln anlegst, ändert sich die implizite Regel auf DROP und Du würdest auch eine ausgehende ACCEPT für WireGuard benötigen. Da eingehend schon eine Regel benötigt wird, sind es also 1 oder 2 Regeln.
Sehr hilfreich ist dieser Post RE: Ab sofort: Firewall für netcup vServer verfügbar
-
Also das Konzept verstehe ich nicht. Wenn man so einen Jump Host (beispielsweise "Pico") nicht ohnehin schon hat, dann verlagert man das Problem doch nur von einem Server zum anderen. Der Jump Host muss ja ebenso abgesichert werden (zzgl. Updates, Firewall, Kosten etc.) - was gewinnt man damit?
Wenn es nur um einen einzelnen Server geht, dann bleibt doch als Lösung nur, die Firewall dicht zu machen und über VPN zuzugreifen, wie bereits vorgeschlagen.
-
Oder brauche ich das nicht?
Doch - vermutlich für NTP- und DNS-Antworten (sofern Du nicht ausschließlich die netcup DNS-Server benutzt) und ggf. weitere von Dir benutzte Dienste, die per UDP arbeiten.
-
Das Verzeichnis .well-known existiert auch nicht im Dateisystem, sondern lediglich virtuell in der RewriteRule der Webserverkonfiguration. Es ist ein feststehender Pfad, der den Client zum Ort von dav.php führt. Die Standarddokumentation von Baikal geht davon aus, dass Baikal in einer eigenen Subdomain betrieben wird und der Pfad führt nach '/' (Rootverzeichnis). Wenn man das nicht will (oder kann), weil man beispielsweise kein passendes Zertifikat dafür bekommt, kann man Baikal auch in ein beliebiges Unterverzeichnis seines Webservers verschieben und muss das dann entsprechend in der Konfiguration nachziehen.
Nachtrag (auch an duck) Wenn man die URL vollständig ausschreiben muss, damit der Kalender funktioniert, deutet das darauf hin, dass die RewriteRule nicht richtig konfiguriert worden ist.
-
Hat von Euch wer Erfahrungen mit der Einbindung in einen iOS-Kalender?
Meinst Du die Verwendung mit der iOS Kalender App?
Über das Verzeichnis .well-known findet die iOS Kalender App automatisch den Kalender (gleiches gilt übrigens für Kontakte mit der Kontakte App). Daher musst Du zum Einrichten des Kalenders nur die URL deines Baikal-Servers eintragen, was ja bei Dir auch zu funktionieren scheint.
Die Fehlermeldung "Serveridentität kann nicht geprüft werden" liegt vermutlich am fehlenden (oder nicht zur Baikal-URL passenden) SSL-Zertifikat.
-
Keine IP Adressen zu hinterlegen würde bedeuten, dass jeder Rechner im Internet über Port 123 mit meinem Server kommunizieren könnte.
Dazu müsste er aber erst einmal Pakete mit Source Port 123 verschicken und könnte damit potentiell andere Dienste, die per UDP erreichbar sind, auf deinem System stören. Im Vergleich zum Betrieb ohne die SCP-Firewall wird die Angriffsfläche auch ohne Hinterlegung der IP-Adressen schon deutlich reduziert. Aber klar, die Adressen der Zeitserver werden sich in der Praxis eher selten ändern und daher kann man sie schon in der Firewall eintragen.
Wenns über IPv4 geht, braucht es ja imho nicht noch IPv6
Wenn auf deinem Server kein IPv6 läuft, ist das okay. Ansonsten wird aber IPv6 in der Regel gegenüber IPv4 bevorzugt und somit laufen die Anfragen bei NTP-Servern per Name ggf. auf Timeouts, weil die Antworten per IPv6 nicht durch die Firewall kommen. Alternativ könnte man - wie zuvor schon angesprochen wurde - die IPv4-Adressen explizit in der chrony-Konfiguration eintragen.
-
Ich hatte bislang davon abgesehen wegen des small impact on security of the client, der dort erwähnt wird.
Hier habe ich eine Erläuterung dazu gefunden: https://chrony-users.chrony.tuxfamily.narkive.com/3JOQnACZ/pros-…nport-directive
-
Aber dazu musst Du dann einen eigenen DNS-Server betreiben?
-
Ich hab mir meinen eigenen Pool definiert
Wie hast Du das DNS-technisch gelöst?
-
Schöne Beschreibung, aber ein paar Anmerkungen seien gestattet:
IPv6 wird nicht berücksichtigt. Die verwendeten Zeitserver haben alle auch IPv6-Adressen und die müsste man konsequenterweise ebenfalls in der Firewall zulassen.
Und das ist auch gleich ein weiterer Kritikpunkt: In der chrony-Konfiguration werden die DNS-Namen der Zeitserver verwendet, in der Firewall (notgedrungen) deren IP-Adressen. Bei einer eventuellen Änderung der im DNS hinterlegten IP-Adressen würden die Firewall-Regeln nicht mehr passen. Eine richtige Lösung zu diesem Dilemma kann ich leider auch nicht anbieten, ich habe daher keine IP-Adressen für NTP in meiner Firewall hinterlegt.
Die Einstellung für makestep würde ich nicht so wählen, wie vorgeschlagen. Im Betrieb will man in der Regel keine Zeitsprünge zulassen - man denke an eine Datenbank, in der die zeitliche Abfolge von Ereignissen dokumentiert wird - sondern das schleichende Angleichen der Zeit durch Bremsen oder Beschleunigen der Systemuhr.
P.S.: Kann es sein, dass systemd-timesyncd wegen fehlender Firewall-Regeln nicht funktioniert hatte?
-
ad #44: Nein, ich denke auch, dass das nichts Ungewöhnliches ist. Es handelt sich dabei ja wohl um das IPv6-Pendant zu den ARP-Broadcasts von IPv4.
