Moin,
seit einigen Tagen fragt der Client (Linux, Ubuntu 22.10) bei jedem Start nach den Credentials für das Login. Ebenso der Browser.
Mein Mobiltelefon meckert nicht.
Hat sich da was in den Einstellungen beim Server (25.0.5) geändert? Ich bin mir nicht sicher, ob das jetzige Verhalten vor dem letzten Update auf 25.0.5 schon bestand. Ich habe auch meinen Desktop neu aufgesetzt, so dass es auch damit zusammenhängen kann. Da aber vor einigen Tagen das Update des Servers lief, möchte ich erst mal in diese Richtung suchen, denn an Client und Browser finde ich nichts, was als Ursache in Frage käme und die Release Notes zum Server sind doch etwas lang und unübersichtlich, so dass ich da leicht was übersehen haben könnte.
Mein Server läuft hier auf einem RaspPI 4 und wird von mir gewartet.
Schau mal auf deiner Nextcloud unter https://cloud.server.tld/settings/user/security und dort unter Geräte & Sitzungen. Dort sollten eigentlich die Sitzungen auftauchen. Wird aber wohl leider dein Problem nicht lösen. Vielleicht kannst du die Sitzungen dort mal löschen.
Für den Browser ja, wenn man z. B. die Cookies löscht und man sich daher neu anmelden muss. Bei Clients wie z. B. Android oder Windows Desktop ist es nicht der Fall, da nach der Anmeldung mit Benutzer/Passwort ein Session-Key verwendet wird. Eine erneute Anmeldung ist eigentlich nicht notwendig. Aber genau das ist ja dein Problem.
nein, da hatte ich keine Auffälligkeiten gesehen. Der letzte Eintrag mit “Error” ist von vorgestern und hat nix mit login zu tun. Da war der Datenbankserver down. Ansonsten keine Warnungen und keine Infos.
wenn keiner der parameter gesetzt ist dann ist ein auto logo out und ein
ablauf der session in der nc nicht konfiguriert, ggf. aber eher unwahrscheinlich ist ein wert in der php.ini f session lifetime zu gering gesetz (wenn überhaupt gesetzt)
ergo sollte auf NC seite alles in ordnung sein
kann es sein das am client das passwort nicht gespeichert wird, das würde das problem erklären …
eigentlich nicht …
ich hab hier zwar duplikate wenn ich auf 2 geräten gleichzeitig mit dem gleichen user angemeldet bin aber ok …
kannst mal nen screenshot machen und zeigen ist ja spannend
wie hast du NC in Ubuntu 22.10 eingebunden
wenn ich die hier auch am laufen hab teste ich das gleich mal durch, weil neugier
Server:
RaspPI 4 mit Apache2, NC 25.0.5. Dieser lauscht auf Port 443 für externen Zugriff und auf Port 80 für unverschlüsselten internen Zugriff.
Router: Port 443 freigegeben, Port 80 gesperrt
Client:
PC mit KUbuntu 22.10
Nextcloud Desktop Client aus dem Standardrepo, Zugriff auf Server mit http://servername
Browser, Zugriff ebenfalls über http://servername
Es sieht wirklich so aus, als ob keine Passwörter gespeichert würden. Dem entgegen spricht, dass das Problem beim Desktop-Client aber auch beim Browser auftritt. Früher blieb ich angemeldet, wenn ich mich nicht explizit abgemeldet hatte und beim nächsten Aufruf kam keine Passwortabfrage. Ich denke aber nicht, dass lokal ein Passwort gespeichert wird, sondern dass per Cookie eine SessionID gespeichert wird. Diese wird beim nächsten mal aber nicht mehr erkannt und daher eine neue Session angelegt. Daher die vielen Einträge in der Liste. Das ist allerdings eine Vermutung aufgrund meiner Beobachtungen. Wie es wirklich funktioniert, weiß ich nicht.
Mein Mobiltelefon hat aber offensichtlich keine Probleme. Da gehe ich aber über den gesicherten Port. Könnte es damit was zu tun haben? Soweit ich mich erinnere kamen die Probleme schon bevor ich vor einigen Tagen die lokalen Zugriffe auf unverschlüsselt umgestellt habe. Aber so richtig sicher bin ich mir mit meinem kaputten Kurzzeitgedächtnis nicht. Aber warum sollte das Auswirkungen haben? Die Konfiguration des Apachen für Port 443 und Port 80 sind identisch bis auf die SSL-Einstellungen natürlich.
Neuerliche Tests belegen, dass das “Problem” nur dann auftritt, wenn ich auf Port 80 gehe. Port 443 agiert wie erwartet. Die Sessions werden nicht direkt ungültig und nach Neustart des Browsers kann ich ohne Login die Seiten aufrufen.
Jetzt stellt sich die Frage, warum NC da Unterschiede macht.
Das Verhalten ist Browser unabhängig, ob Firefox oder Chrome. Da der Desktop-Client nicht über einen Broswer geht, bleibt nur NC selbst als Ursache.
Vermutlich, weil http (über Port 80) potentiell als “unsicher” gilt. Immer mehr werden diese unsicheren Verbindungen von Servern bemängelt. Auch Nextcloud fühlt sich mit https wohler. Entsprechende Meldungen und Empfehlungen solltest Du eigentlich besonders beim Systemcheck über die Weboberfläche erhalten.
Es gibt eigentlich keinen triftigen Grund, auch innerhalb des LAN nicht https zu verwenden.
Die Situation ist die, dass mein ssl-Zertifikat auf die Domain ausgestellt ist, mit der NC außerhalb erreichbar ist. Gehe ich intern über ssl, dann wird gemeckert, dass das Zertifikat nicht gültig sei. Der interne Rechnername ist anders als der über den externen DNS-Service. Diese Meldung wollte ich umgehen. Das ist alles. Auch wollte ich intern nicht über die externe Adresse gehen, denn für größere Transfers macht es keinen Sinn, die Datei über den halben Globus zu schicken, wenn beide Computer nur zwei Meter auseinander stehen.
Es geht also primär nicht um ssl sondern um das dahinterstehende Zertifikat, das für lokalen Zutritt nicht gültig ist.
Aktuell muss ich sagen, dass sich jetzt zwar die Browser “normal” verhalten, der Desktop-Client aber immer noch jedes mal eine neue Erlaubnis möchte. Nur ist das jetzt nicht mehr so lästig weil der Browser das Fenster zur Erteilung der Zugriffsberechtigung einfach aufmacht und man da keine Credentials mehr eingeben muss.
Vielleicht ist das deshalb, weil man in einem Browser angeben kann, dass man dem Zertifikat trotzdem vertraut, was beim Desktop-Client aber nicht so funktioniert.
Das Problem sollte sich im Router durch DNS-Rebind - Einstellung lösen lassen. Ursache ist, dass der Netzwerkinterne DNS einen anderen Hostnamen für Deinen Nextcloud-Server verwaltet.
Du solltest für intern und extern dieselbe Adresse und dieselbe DNS-Auflösung und somit auch dasselbe SSL-Zertifikat verwenden.
Die Daten gehen gar nicht um den halben Globus, wenn du es richtig machst. Such mal nach Hairpinning und NAT Loopback. Um genau zu sein, verlassen sie nicht mal dein LAN.
Aber hier führst du nur Symptome und nicht die eigentliche Ursache auf.
Zitat:
Ihre FRITZ!Box unterdrückt DNS-Antworten, die auf IP-Adressen im eigenen Heimnetz verweisen (DNS-Rebind-Schutz). Hier können Sie Ausnahmen angeben, für die der DNS-Rebind-Schutz nicht gelten soll. Tragen Sie dazu den vollständigen Hostnamen (Domainname inklusive Subdomain) in die Liste ein.
Zitat Ende.
heißt das, dass meine Fritzbox das automatisch gemacht hat, was ihr vorschlagt , als ich noch nicht über Port 80 ging?
Hier liegt der Fehler. Nutz doch einfach den externen Rechnernamen. Ich weiß gar nicht die interne IP-Adresse und den internen Namen (ok den wüsste ich schon) von meiner internen Nextcloud Sofern du kein CDN verwendest und die externe IP gleichtzeitig die externe IP deines Routers ist, sollte das funktionieren. Ruf einfach dazu im Browser https://ifconfig.me/ip auf und löse mal den DNS-Namen deiner Nextcloud (die DynDNS-Adresse) auf. Stimmen die überein?
Den Port 80 brauchst du nur (von außen), damit Lets Encrypt das Zertifikat erneuern kann. Du könntest dir maximal eine Umleitung von 80 auf 443 konfigurieren. Aber sonst nutzt niemand Port 80 mehr.
Sofern du kein CDN verwendest und die externe IP gleichtzeitig die externe IP deines Routers ist, sollte das funktionieren. Ruf einfach dazu im Browser