zugang zu SVN funktioniert nicht mehr

[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]

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

[rudolfkoenig]

Mein 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.

Code Auswählen Erweitern

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

[betateilchen]

Also prüfe bitte die Dateirechte des private keys.

Code Auswählen Erweitern

ls -lha ~/.ssh/

Nicht jeder arbeitet mit Linux...

Updating: D:\homeAuto\fhem5 from svn+ssh://svn.fhem.de/trunk

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

[rudolfkoenig]

@Rudi Kann es RSA Versionsprobleme geben?

Wenn ich die auth-logs auf dem Server richtig lese, dann beschwert sich sshd ueber die Schluessellaenge.

Code Auswählen Erweitern

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]

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?

[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]

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

Code Auswählen Erweitern

ssh-keygen -y -e -f <filename>Da müsste am Anfang so etwas stehen wie:

Comment: "2048-bit RSA, converted by

Diese Informationen wäre für die Bestätigung des Problems interessant.

[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]

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

Code Auswählen Erweitern

C:\Users\heinz>ssh-keygen -y -e -f .ssh\otto123svn
---- BEGIN SSH2 PUBLIC KEY ----
Comment: "4096-bit RSA, converted by heinz@lukw11 from OpenSSH" ...

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.

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?

[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]

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:

Code Auswählen Erweitern

Get-WindowsCapability -Online | Where-Object Name -like 'OpenSSH*'Und wenn Du willst installieren:

Code Auswählen Erweitern

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:

Code Auswählen Erweitern

ssh -v svn.fhem.deVielleicht bekommt man dabei mehr Informationen.