zugang zu SVN funktioniert nicht mehr

Begonnen von martinp876, 07 April 2024, 21:45:55

Vorheriges Thema - Nächstes Thema

martinp876

Mein Zugang zu svn funktioniert nicht mehr. Wir in https://svn.fhem.de/ "read/write access for developers" habe ich versucht alles noch einmal durchzuführen.
Jetzt ist meine kopie verschwunde.... die Änderungen werde ich wohl wieder rekonstruieren können...
Sollte alles noch funktionieren wir vor? Das erstellen des Checkout ist schon ewig her... letztes commit auch schon eine Weile

Otto123

#1
Hallo Martin,

ich meine seit der Serverumstellung vor einem Jahr wurde nichts geändert. Es läuft alles wie bisher.
Ich habe gerade entsprechend Anleitung meinen Zugang neu eingerichtet und getestet.

Gibt es irgendwelche Fehlermeldungen? Ist Dein passender private Key an Ort und Stelle? hat der die Berechtigungen 600?

Gruß Otto
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

rudolfkoenig

ZitatMein Zugang zu svn funktioniert nicht mehr.
Der Eintrag mit dem oeffentlichen Schluessel fuer martinp876 wurde zuletzt vor 8 Jahren geaendert, es ist von Typ rsa mit der Endung M2+X7w==

martinp876

Hallo Otto, Rudi,
das keyfile scheint zu stimmen. gebe ich ein falsches ein wird es angemeckert. Im Putty erhalte ich ein Access denied.  Kann es sein, dass das Passwort gesperrt ist? Ich bin mir eigentlich sicher, dass es  richtig ist...

Updating: D:\homeAuto\fhem5 from svn+ssh://svn.fhem.de/trunk 
Error: Unable to connect to a repository at URL 'svn+ssh://svn.fhem.de/trunk'
Error: To better debug SSH connection problems, remove the -q option from 'ssh' in the 
Error:  [tunnels] section of your Subversion configuration file. 
Error: Network connection closed unexpectedly 


nun, 1 Jahr könnte knapp sein. War etwas zu beachten? Die URL ist noch die gleiche laut Anleitung
Gruß

Otto123

Hallo Martin,

es gibt kein Passwort, einzig dein private key muss zu dem hinterlegtem public key passen und verwendbar sein. Exakt die gleiche Meldung, bzw. die Aufforderung zum Passwort kommt, wenn Dein private Key nicht ausschließlich durch Dich (den User der ihn verwendet) lesbar ist!
Also prüfe bitte die Dateirechte des private keys.ls -lha ~/.ssh/
Es hat sich seit 8 Jahren nichts geändert, lediglich vor einem Jahr wurde der Server getauscht. Gleiche Daten wie vorher. Es gab eigentlich bei keinem Probleme.

Das Du mit putty keinen Zugriff bekommst ist richtig.

@Rudi Kann es RSA Versionsprobleme geben?

Gruß Otto
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

betateilchen

Zitat von: Otto123 am 08 April 2024, 21:15:03Also prüfe bitte die Dateirechte des private keys.
ls -lha ~/.ssh/

Nicht jeder arbeitet mit Linux...

Zitat von: martinp876 am 08 April 2024, 20:37:52Updating: D:\homeAuto\fhem5 from svn+ssh://svn.fhem.de/trunk

Aber auch unter Windows kann man Dateirechte prüfen und setzen.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

rudolfkoenig

Zitat@Rudi Kann es RSA Versionsprobleme geben?
Wenn ich die auth-logs auf dem Server richtig lese, dann beschwert sich sshd ueber die Schluessellaenge.
fhem2-svn sshd[4102396]: error: userauth_pubkey: parse key: Invalid key length [preauth]
RSA Schluessel sind normalerweise recht lang, Martins Eintrag ist weniger als ein drittel der von Anderen.
Ich gehe davon aus, dass Martin mir einen laengeren RSA oder einen ed25519 Schluessel zuschicken muss.

Otto123

#7
Zitat von: betateilchen am 09 April 2024, 06:09:17Aber auch unter Windows kann man Dateirechte prüfen und setzen.
stimmt, kann man:
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
Zitat* 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?

Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

martinp876

Vielen Dank für die Hilfe - noch klappt es nicht.
Es hat Jahrelang funktioniert - evtl habe ich eine Umstellung verpasst? Mein letzter nachgewiesener commit ist 16 Monate her.
Ein Passwort muss ich angeben wenn ich Aktionen schreibend mache - schon immer.
Die Keyfiles sind von 2016... und ja, das Enviroment für SVN ist Windows - das operational System natürlich Lunix :).
Rechte des key-Files haben sich nicht geändert - ich habe nun alles "versteckt". Leiter ist WIN nicht so einfach zu setzen wie Linux...

Sicher ein sehr dummer Bedien(er)fehler... aber welcher?
p.s. Password oder PassPhrase... sollten das gleiche sein - steht mal so mal so


Otto123

#9
Zitat von: martinp876 am 09 April 2024, 19:37:25Ein Passwort muss ich angeben wenn ich Aktionen schreibend mache - schon immer.
Ich vermute, Du hast deinem Private Key File eine Passphrase verpasst. Das passiert rein lokal bei Dir.
Im SVN ist kein Passwort hinterlegt, SVN macht ssh und ssh fragt nur dann als Alternative (falls konfiguriert) ein Passwort ab wenn der offerierte private Key nicht stimmt oder aus anderen Gründen inakzeptabel ist.

Du kannst eventuell Informationen zu deinem Key erhalten mittels (auch unter Windows):
ssh-keygen -y -e -f <filename>Da müsste am Anfang so etwas stehen wie:
ZitatComment: "2048-bit RSA, converted by

Diese Informationen wäre für die Bestätigung des Problems interessant.
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

krikan

Habe testweise mit einer "alten" putty-.ppk-Datei und TortosieSVN unter Windows einen CheckOut gemäß Anleitung auf svn.fhem.de probiert. Scheiterte auch immer am angeblich falschen Passwort.

Nachdem ich aus dem openssh-Schlüssel über puttygen 0.8 0x64 eine neue ppk-Datei erzeugt hatte, funktioniert ein Checkout problemlos.

In der neuen ppk-Datei gibt es zusätzliche Zeilen beginnend mit "Key-Derivation" und "Argon2".

Vielleicht ist hier -falls der openssh-Schlüssel vorliegt- auch die Neugenerierung des ppk-Schlüssels über puttygen die Lösung.

Gruß, Christian

martinp876

ja, einen passkey habe ich hinterlegt. Mir ist unklar, warum der nicht mehr funktionieren sollte... das file hat sich nicht geändert und den Passkey habe ich im keepass - stabil. Und auch im Kopf...

Habe also Putty 8.0 geladen und einen neuen Key erzeugt - ohne Passwort. Jetzt verlangt er kein Passwort, aber bricht immer noch ab - mit den gleichen Meldungen.
Das Fenster hat sich im Putty leicht geändert, da der privat Key nun im Submenü Auth->Credentials anzugeben ist.
Das Keyfile kann ich unter Windows nun schreibschützen und als Archive taggen - ändert nichts. Einzelne Nutzer zu sperren ist unklar. Da sind eigentlich keine - muss der Admin gesperrt werden? Sollte es Einschränkungen im Win geben, welche gesetzt werden müssen brauche in eine Info.

auf der Himbeere kann ich keinen der über PuttyGen (egal welche Version) prüfen - das Format ist immer ungültig

ssh-keygen -y -e -f <filename> finde ich unter windows nicht.

neuen Key in Linux erstellt, geht auch nicht.

Ich kann mein altes PPR in Puttygen laden. Die Passphrase wird abgefragt und akzeptiert. Alles wie ich es erwarte.

Puttygen zeigt den öffentlichen Schlüssel  welcher endet, wie Rudi es postste.

Also:
- Pub-Key und PrivKey sollten zusammenpassen
- Passphrase ist korrekt
- Putty session gesprichert mit Host martinp876@svn.fhem.de, ssh/port ok.

Es wird ein FHEM Passwort abgefragt. das sollte noch funktionieren.  - geht ja hier auch




Otto123

#12
Zitat von: martinp876 am 11 April 2024, 20:33:15ssh-keygen -y -e -f <filename> finde ich unter windows nicht.
es gibt ssh-keygen bei Dir nicht?  Das ist seit Windows 10 ein Systemprogramm. Welches Windows verwendest Du?
CMD auf und dann
C:\Users\heinz>ssh-keygen -y -e -f .ssh\otto123svn
---- BEGIN SSH2 PUBLIC KEY ----
Comment: "4096-bit RSA, converted by heinz@lukw11 from OpenSSH" ...


Zitat von: martinp876 am 11 April 2024, 20:33:15Das Keyfile kann ich unter Windows nun schreibschützen und als Archive taggen - ändert nichts. Einzelne Nutzer zu sperren ist unklar. Da sind eigentlich keine - muss der Admin gesperrt werden? Sollte es Einschränkungen im Win geben, welche gesetzt werden müssen brauche in eine Info.
Die Zugriffsrechte müssen so aussehen wie in Beitrag #7 gezeigt. Das ist aber per default so und nicht extra gemacht.

Aber um das Problem zu lösen, wäre es doch einfach:
  • Du erzeugst ein neues Keypärchen, vorzugsweise ed25519 oder rsa 4096 (siehe svn.fhem.de) und
  • schickst den Public Key an die Adresse svn@fhem.de
  • Rudi trägt den neuen Schlüssel ein.
Anschließend verwendest Du den neuen private Key und wir hoffen es funktioniert alles?
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

martinp876

Win10. kein ssh-keygen. Sollte nicht das Problem sein, da mein Key scheinbar i.O. ist.

Ich werde beim Commit nach meinem FHEM Passwort gefragt - und dass funktioniert scheinbar nicht. Ich denke wir suchen an der falschen Stelle.

Otto123

#14
seitens svn gibt es keine extra Passwortabfrage wenn der Key funktioniert, das muss also ein lokales Problem sein. Nach wie vor besteht aber die Vermutung: Dein hinterlegter Public Key ist zu kurz.

Im svn Log kommt von Dir gar nichts an.
Im journalctl -u ssh kommt von Dir nur ein: Connection closed by authenticating user .. preauth Ich meine: auch dort stirbt die Anmeldung bevor es losgeht.

Ich weiß leider nicht mehr wie ich helfen könnte.

In Windows wird seit dem Release 1806 OpenSSH.Client vorinstalliert, kann sein das bei einem älteren Windows auch beim Update keine Installation erfolgt. Habe ich mir noch nicht angeschaut.
Ich finde die Arbeit mit ssh viel angenehmer als mit putty

Du kannst in der Powershell prüfen:
Get-WindowsCapability -Online | Where-Object Name -like 'OpenSSH*'Und wenn Du willst installieren:
Get-WindowsCapability -Online | Where-Object Name -like 'OpenSSH.C* | Add-WindowsCapability -Online 'siehe auch

Damit könnte man auch unter Windows den ssh Zugriff mit verbose testen:
ssh -v svn.fhem.deVielleicht bekommt man dabei mehr Informationen.
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

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.
Zitat[ 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

Zitat von: Otto123 am 09 April 2024, 12:04:10
Zitat von: betateilchen am 09 April 2024, 06:09:17Aber auch unter Windows kann man Dateirechte prüfen und setzen.
stimmt, kann man:
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
Zitat* 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.
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

Otto123

Zitat von: rudolfkoenig am 13 April 2024, 10:48:32Martin 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?
ssh -v svn.fhem.deDas liefert mehr an Informationen.
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

Prof. Dr. Peter Henning

#19
ZitatOpenSSH_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

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.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

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:
  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

ZitatIst 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 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

#23
Zitat von: Prof. Dr. Peter Henning am 20 April 2024, 13:03:53Kö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/  :o
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

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

#26
Zitat von: rudolfkoenig am 20 April 2024, 15:09:38Ueber 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:

Zitat von: Prof. Dr. Peter Henning am 20 April 2024, 07:03:34[ 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 :)

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
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

Prof. Dr. Peter Henning

#27
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:
Zitat von: betateilchen am 20 April 2024, 15:14:23Bei "URL" und "Repository Root" sollte besser nicht https:// stehen
Aber doch. Funktioniert(e) seit Jahren schon so. Das letzte Mal im März...

ZitatPfad: .
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

#28
Zitat von: Prof. Dr. Peter Henning am 20 April 2024, 17:52:55Aber 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.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

rudolfkoenig

ZitatAber 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".

Prof. Dr. Peter Henning

Zitat von: betateilchen am 20 April 2024, 18:14:22aber an dieser Aussage habe ich starke Zweifel
Mag sein. Aber ich habe genau diese lokale Ablage mit genau diesem SVN-Client über Jahre hinweg benutzt, ohne Probleme. Du kannst mir jetzt natürlich erzählen, dass im Hintergrund ein Commit immer schon über svn+ssh gelaufen sei - aber daran habe ich starke Zweifel.

Den Lösungsweg, das ganze nochmal neu und sauber mit der Kommandozeile zu machen, habe ich ja schon beschritten, wie du unten siehst.

LG

pah

rudolfkoenig

Zitat2. Wieso funktionierte über lange Zeit ein commit mit dem alten RSA-Schlüssel und https:// ?
Ich habe keine Ahnung, wie man RSA-Schluessel mit https:// verwendet, ich behaupte, der Schluessel gehoert zu SSH.
Die Ursache bei SSH: wir haben unlaengst ein OS-Upgrade gemacht, und der neue SSH Server mag keine kurzen RSA-Schluessel.

Prof. Dr. Peter Henning

#32
Gut, also damit ist die Ursache geklärt. Auf meiner Seite funktioniert das mit dem Kommandozeilenprogramm, auch gut.

Den Synchro-SVN-Client kann ich dann eben nicht mehr zum Einchecken verwenden.

In jedem Falle Dank in die Runde fürs mitdiskutieren. Etwas rätselhaft bleibt es trotzdem, wie dieser Client in den vergangenen Jahren den Eincheck-Vorgang durchgeführt hat. Denn etwas anderes als "https://svn.fhem.de" und meinen privaten Key hatte das Teil nie.

LG

pah

betateilchen

Zitat von: rudolfkoenig am 20 April 2024, 18:41:59Die Ursache bei SSH: wir haben unlaengst ein OS-Upgrade gemacht, und der neue SSH Server mag keine kurzen RSA-Schluessel.

Wird denn ed25519 irgendwann der neue "Standard" bei svn.fhem.de?
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

Otto123

Zitat von: Prof. Dr. Peter Henning am 20 April 2024, 18:51:30Synchro-SVN-Client
Hat sicher nichts mit dem Fall hier zu tun, aber Zukunftsicher ist er eh nicht:
ZitatSyncro Soft will discontinue offering the Syncro SVN Client v10 on September 15, 2019. At that time, the Syncro SVN Client will reach End of Sale. Syncro SVN Client will reach End of Maintenance on March 15, 2020 and End of Support on September 15, 2020.
Wir haben am SVN seit einem Jahr nichts weiter geändert, vielleicht hat auch ein Windows Update am 13. März zu dem verändertem Verhalten geführt?

Zitat von: rudolfkoenig am 20 April 2024, 18:41:59und der neue SSH Server mag keine kurzen RSA-Schluessel.
ich habe das bisher nur gelesen und konnte das nicht nachstellen. Ein Ubuntu 22.04 in der Testumgebung akzeptiert 1024 bit lange RSA Schlüssel. Ich forsche da weiter...
Zitat von: betateilchen am 20 April 2024, 19:07:13Wird denn ed25519 irgendwann der neue "Standard" bei svn.fhem.de?
Ich bin dafür -> Anleitung auf svn.fhem.de ändern. Wir sollten auch die Arbeit mit Windows am SVN auf einen neuen Stand bringen!?
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

Prof. Dr. Peter Henning

Zitat von: Otto123 am 21 April 2024, 14:08:06Windows Update am 13. März
Läuft der Server denn unter Windows?

LG

pah

Otto123

Nein auf ubuntu 22.04, ich meinte ein Update auf deinem Client. Auf dem Server gab es zu diesem Zeit kein Update.
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

rudolfkoenig

ZitatLäuft der Server denn unter Windows?
Gott bewahre :)

Prof. Dr. Peter Henning

Zitat von: Otto123 am 21 April 2024, 14:13:16Update auf deinem Client
Nicht doch, ich dachte wir seien Freunde  :o

Der Client ist (obwohl veraltet) immer noch im Bundle mit dem Synchro oXygen XML_Editor (neueste Version von 2024). Und da ich diesen Editor für alle Projekte - von Perl bis Python - benutze (und zwar auf einem sauberen Linux-System), war er bisher sehr bequem.

LG

pah

martinp876

Hi,
ich habe nun (endlich) einen neuen PublicKey (wohl mit 4096Bit) an svn.fhem.de geschickt.
Leider noch keine Antwort. Ist die Adresse noch richtig? Jedenfalls : keine Antwort, kein Zugang bi sjetzt


rudolfkoenig

Ich habe die Email am "Mon, 3 Jun 2024 09:10:46 +0200" beantwortet, nachdem ich den Schluessel ersetzt habe.

martinp876

super -
sorry, deine Antwort ist im Spam hängen geblieben. dann noch ein blöder Fehler von mir... wie immer.

Was ich mitnehme (als Security Laie)
der öffentliche Schlüssen muss für fhem-SVN min 4096Bit sein. Das kann man einfach an der Filelänge ablesen. Ein Fachmann hätte also gleich sagen können "der key ist nicht mehr zulässig" - schlicht wegen der file-länge. Rudi hat diese in Frage gestellt - aber eigentlich ist es wohl eindeutig.

Jetzt ist es wieder ok bei mir. Bis zum nächsten Mal kann ich es wieder vergessen ;)


betateilchen

Zitat von: martinp876 am 08 Juni 2024, 09:22:44der öffentliche Schlüssen muss für fhem-SVN min 4096Bit sein. Das kann man einfach an der Filelänge ablesen.

Auf diese einfache Kombination würde ich mich nicht verlassen. Es hängt vom Schlüsseltyp ab.
Der öffentliche key bei ed25519 ist beispielsweise in der Regel kürzer als 80 Zeichen.

Aber Hauptsache es funktioniert jetzt wieder.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!