zugang zu SVN funktioniert nicht mehr

[rudolfkoenig]

Vorschlag:
Martin erstellt einen neuen RSA Schluessel mit 2048 Bit laenge, und schickt mir den oeffentlichen Teil (public key).
Ich ersetze damit seinen Alten auf svn.fhem.de.

[Prof. Dr. Peter Henning]

Ich habe auch das Problem, dass mein SVN-Client nichts mehr schreiben darf. Das war es also offenbar noch nicht.

[ 06:59:52] - svn commit -m "95_Shares.pm: Erweitert um alternative Symbole für jedes Wertpapier" 1 packet
[ 06:59:52] - Skipped 'null'
[ 06:59:52] - Vorgang ist fehlgeschlagen: svn: E170001: Commit failed (details follow):
svn: E170001: MKACTIVITY of '/fhem/!svn/act/8a06e0f9-8e01-0010-a6a2-a5635337f4c2': 403 Forbidden (https://svn.fhem.de)

LG

pah

[CoolTux]

Aber auch unter Windows kann man Dateirechte prüfen und setzen.

stimmt, kann man:

Code Auswählen Erweitern

C:\Users\heinz>cacls .ssh
C:\Users\heinz\.ssh NT-AUTORITÄT\SYSTEM:(OI)(CI)F
                    VORDEFINIERT\Administratoren:(OI)(CI)F
                    LUKW11\heinz:(OI)(CI)F
C:\Users\heinz>cacls .ssh\id_rsa
C:\Users\heinz\.ssh\id_rsa VORDEFINIERT\Administratoren:F
                          NT-AUTORITÄT\SYSTEM:F
                          LUKW11\heinz:C
Ich hatte letztens erst hier einen Fall wo die Verzeichnisrechte auf dem %HOMEDRIVE%%HOMEPATH%\.ssh verbogen waren.
Aber das spielt wahrscheinlich keine Rolle, wenn man unter Windows mit putty arbeitet.

Ich meine, dass OpenSSH ab der Version 7.6 eine RSA Schlüssellänge mit 1024 oder kürzer als unsicher einstuft. Es kann in der Tat sein, dass dies am alten Server noch nicht so war, der hat die OpenSSH Version 7.2 .
Siehe auch https://www.openssh.com/releasenotes.html

* Refuse RSA keys <1024 bits in length and improve reporting for keys
  that do not meet this requirement.

Laut Anleitung auf svn.fhem.de soll ein RSA Key mit einer Länge von 4096 erzeugt werden
Wir sollte die Beschreibung mal kritisch überarbeiten und ed25519 Keys nach vorne bringen? Zumal ich lese, dass in OpenSSH der Support für RSA irgendwann eingestellt wird?

Ich finde es sollten diejenigen welche sich hier gerade wegen nicht Funktion melden ein neues Schlüsselpärchen erstellen. Default wird unter Linux mittels ssh-keygen als Schlüssellänge ed25519 verwendet.

[Otto123]

Martin erstellt einen neuen RSA Schluessel mit 2048 Bit laenge,

Das würde unsere Anleitung auf svn.fhem.de widersprechen. RSA Keys sollten 4096 Bit lang sein um Zukunftssicher zu sein.

Ich würde auch besser ed25519 empfehlen.

@pah hast Du mal das probiert?

Code Auswählen Erweitern

ssh -v svn.fhem.deDas liefert mehr an Informationen.

[Prof. Dr. Peter Henning]

OpenSSH_8.9p1 Ubuntu-3ubuntu0.6, OpenSSL 3.0.2 15 Mar 2022
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: include /etc/ssh/ssh_config.d/*.conf matched no files
debug1: /etc/ssh/ssh_config line 21: Applying options for *
debug1: Connecting to svn.fhem.de [2a01:4f8:221:1b5a::2] port 22.
debug1: connect to address 2a01:4f8:221:1b5a::2 port 22: Connection refused
debug1: Connecting to svn.fhem.de [188.40.131.57] port 22.
debug1: connect to address 188.40.131.57 port 22: Connection refused
ssh: connect to host svn.fhem.de port 22: Connection refused

Also gut, ich habe jetzt meinen ed25519 public key an Rudi geschickt. Mal sehen, ob es dann klappt.

LG

pah

[betateilchen]

Code Auswählen Erweitern

debug1: connect to address 188.40.131.57 port 22: Connection refused
ssh: connect to host svn.fhem.de port 22: Connection refused

Ist das nicht der falsche port?
Müsste da nicht 55522 stehen?
Wo hast Du denn die Konfigurationsdaten für den FHEM svn-server abgelegt?


udo@mac-mini-LAN ~ % ssh -v svn.fhem.de
OpenSSH_9.6p1, LibreSSL 3.3.6
debug1: Reading configuration data /Users/udo/.ssh/config
debug1: /Users/udo/.ssh/config line 4: Applying options for svn.fhem.de
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 21: include /etc/ssh/ssh_config.d/* matched no files
debug1: /etc/ssh/ssh_config line 54: Applying options for *
debug1: Authenticator provider $SSH_SK_PROVIDER did not resolve; disabling
debug1: Connecting to svn.fhem.de port 55522.
debug1: Connection established.

[rudolfkoenig]

Hab den Schluessel fuer den Benutzer phenning ausgetauscht.

SSH Port fuer SVN ist (wie von betateilchen geschrieben) 55522.
Port 22 wird fuer die Alexa Authentifizierung verwendet (wenn ich mich recht erinnere), und landet auf einem anderen VM.

Etwas off-topic:
Auf dem SVN Server hatten wir heute bis 11:30 7407 "Anklopfer", hier ist die Top 20:

Code Auswählen Erweitern

  1443 root
    85 admin
    69 test
    59 postgres
    58 user
    58 ubuntu
    43 demo
    36 deploy
    34 oracle
    27 git
    21 hadoop
    18 jenkins
    18 ftpuser
    17 es
    15 mysql
    15 bin
    15 app
    14 guest
    13 nagios
    13 gpadmin


[Prof. Dr. Peter Henning]

Ist das nicht der falsche port?
Müsste da nicht 55522 stehen?

Das ist wohl wahr, mein Fehler - betrifft aber nur den Versuch direkt mit dem Kommandozeilen-Aufruf.

Mit meinem SVN-Client (Sychro SVN Client) hat es am 3. März jedenfalls noch geklappt.

Etwas schlauer bin ich auch:

1. Die Verbindung auf der Kommandozeile mit

Code Auswählen Erweitern

ssh -v svn.fhem.de -p 55522 klappt jedenfalls jetzt. Danke Rudi, für das Einstellen des Keys.
2. Die Verbindung des Client jedoch nicht. Ich habe jetzt mal in dessen abgelegten Authentifizierungsdaten nachgesehen und festgestellt, dass dessen Verbindung noch am 3. März 2024 unter https://svn.fhem.de:443 erfolgreich war.

Könnte es sein, dass auf dem Server bis vor wenigen Tagen noch eine Port-Umleitung 443->55522 eingerichtet war?

LG

pah

[Otto123]

Könnte es sein, dass auf dem Server bis vor wenigen Tagen noch eine Port-Umleitung 443->55522 eingerichtet war?

Ich behaupte: die gab es nie. Das ist der öffentliche Link zur Webseite https://svn.fhem.de/

Oder machst Du die Synchronisation über die Browser Schnittstelle ? https://svn.fhem.de/trac/browser/trunk/fhem/ 

[Prof. Dr. Peter Henning]

Wo Du mich so fragst, ja, sieht so aus.

LG

pah

[rudolfkoenig]

Ueber https ist nur checkout moeglich.
Hoffe ich

[betateilchen]

Ueber https ist nur checkout moeglich.
Hoffe ich

Ja, das Fehlschlagen  des commit hat Peter ja oben per https:// erfolgreich (im Sinne von "nicht erlaubt") verprobt:

[ 06:59:52] - Vorgang ist fehlgeschlagen: svn: E170001: Commit failed (details follow):
svn: E170001: MKACTIVITY of '/fhem/!svn/act/8a06e0f9-8e01-0010-a6a2-a5635337f4c2': 403 Forbidden (https://svn.fhem.de)

Edit:

@pah: was ergibt denn "svn info" im Verzeichnis Deiner genutzten svn working copy?
Bei "URL" und "Repository Root" sollte besser nicht https:// stehen

Code Auswählen Erweitern

udo@mac-mini-LAN fhem % svn info               
Path: .
Working Copy Root Path: /Users/udo/Development/svn/fhem
URL: svn+ssh://svn.fhem.de/trunk/fhem
Relative URL: ^/trunk/fhem
Repository Root: svn+ssh://svn.fhem.de
Repository UUID: 2b470e98-...
Revision: 28810


[Prof. Dr. Peter Henning]

So, ich habe jetzt mal den SVN-Client außen vor gelassen. Mit dem neuen ed25519 key funktioniert ein Checkout ebenso wie ein Commit - die neue Version von 95_Shares.pm ist also eingecheckt, Haken dran.

Bleiben drei Fragen offen:
1. Was wurde geändert, warum funktionierte heute nicht mehr, was noch vor kurzem funktionierte?
2. Wieso funktionierte über lange Zeit ein commit mit dem alten RSA-Schlüssel und https:// ?
3. Eher nur für mich relevant: Wie kriege ich den Synchro-Client dazu, einen ed25519-Schlüssel zu akzeptieren

Denn:

Bei "URL" und "Repository Root" sollte besser nicht https:// stehen

Aber doch. Funktioniert(e) seit Jahren schon so. Das letzte Mal im März...

Pfad: .
Wurzelpfad der Arbeitskopie: /home/phenning/Sync/Projekte/FHEM/fhemsvn/fhem
URL: https://svn.fhem.de/fhem/trunk/fhem
Relative URL: ^/trunk/fhem
Basis des Projektarchivs: https://svn.fhem.de/fhem
UUID des Projektarchivs: 2b470e98-0d58-463d-a4d8-8e2adae1ed80
Revision: 28810
Knotentyp: Verzeichnis
Plan: normal
Letzter Autor: fhemupdate
Letzte geänderte Rev: 28810
Letztes Änderungsdatum: 2024-04-20 07:45:16 +0200 (Sa, 20. Apr 2024)

LG

pah

[betateilchen]

Aber doch. Funktioniert(e) seit Jahren schon so. Das letzte Mal im März...

Sorry - aber an dieser Aussage habe ich starke Zweifel.

Ein COMMIT per https:// hat - im Gegensatz zum CHECKOUT - in den vergangenen Jahren nicht funktioniert. Das hatte ich vor langer Zeit einmal versehentlich probiert und dann eine ganze Weile gebraucht, um dahinter zu kommen, wo mein Fehler lag.

Checke doch das repository nochmal mit svn+ssh:// (und einer korrekten svn-Konfiguration) aus und versuche dann den commit Deiner Datei noch einmal.

[rudolfkoenig]

Aber doch. Funktioniert(e) seit Jahren schon so. Das letzte Mal im März...

Authentifizierung ist nur mit SSH moeglich, wir hatten dazu nie eine Alternative.
Habe gerade nochmal getestet: Aenderungen ueber https://svn.fhem.de einzuchecken wird abgelehnt.
HTTPS ist (wie auf der o.g. Seite beschrieben) "read only check out".