[HINWEIS] - SVN-Repository ist zu svn.fhem.de umgezogen

Begonnen von Markus Bloch, 11 Dezember 2016, 15:15:15

Vorheriges Thema - Nächstes Thema

Markus Bloch

Ich kann mir das heute Nachmittag gerne anschauen, sobald ich Feierabend habe.

Gruß
Markus
Developer für Module: YAMAHA_AVR, YAMAHA_BD, FB_CALLMONITOR, FB_CALLLIST, PRESENCE, Pushsafer, LGTV_IP12, version

aktives Mitglied des FHEM e.V. (Technik)

Markus Bloch

"User Tobias" bitte dennoch mit großem U schreiben, sonst wird die Zeile nicht erkannt.
Developer für Module: YAMAHA_AVR, YAMAHA_BD, FB_CALLMONITOR, FB_CALLLIST, PRESENCE, Pushsafer, LGTV_IP12, version

aktives Mitglied des FHEM e.V. (Technik)

justme1968

das neue repository ist traumhaft schnell im vergleich zu sourceforge :)
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

hexenmeister

Moin!
Habe wohl gleiches Problem wie Tobias. :(
OpenSSH_6.0p1 Debian-4+deb7u4, OpenSSL 1.0.1e 11 Feb 2013
debug1: Reading configuration data /home/alex/.ssh/config
debug1: /home/alex/.ssh/config line 1: Applying options for svn.fhem.de
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: Connecting to svn.fhem.de [88.99.31.202] port 55522.
debug1: Connection established.
debug1: identity file id_rsa.ppk type -1
debug1: identity file id_rsa.ppk-cert type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_7.2p2 Ubuntu-4ubuntu2.1
debug1: match: OpenSSH_7.2p2 Ubuntu-4ubuntu2.1 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.0p1 Debian-4+deb7u4
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-sha1 none
debug1: kex: client->server aes128-ctr hmac-sha1 none
debug1: sending SSH2_MSG_KEX_ECDH_INIT
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ECDSA 66:41:62:f3:45:ed:a3:59:93:28:c6:84:2d:36:b0:00
debug1: Host '[svn.fhem.de]:55522' is known and matches the ECDSA host key.
debug1: Found key in /home/alex/.ssh/known_hosts:8
debug1: ssh_ecdsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Trying private key: id_rsa.ppk
debug1: No more authentication methods to try.
Permission denied (publickey).


Weder meine Keys will der Server nicht (id_rsa, id_rsa.pub, id_rsa.ppk... habe schon alle durchprobiert...)

Was könnte ich dagegen tun?

Grüße
Alexander
Maintainer: MQTT_GENERIC_BRIDGE, SYSMON, SMARTMON, systemd_watchdog, MQTT, MQTT_DEVICE, MQTT_BRIDGE
Contrib: dev_proxy

Markus Bloch

Hallo Alexander,

bitte nicht PuTTY-Private-Keys mit OpenSSH mischen. Das funktioniert nicht. Wenn du auf der Linux-Shell eine SSH-Verbindung machst, benötigst du id_rsa als Private-Key. Wenn du in Windows PuTTY benutzt, benötigst du id_rsa.ppk (PuTTY Private Keyfile)

Du hattest heute um 17:03 Uhr und um 16:56 eine erfolgreiche Verbindung. Du hast also schonmal deinen korrekten Private-Key verwendet.

Gruß
Markus
Developer für Module: YAMAHA_AVR, YAMAHA_BD, FB_CALLMONITOR, FB_CALLLIST, PRESENCE, Pushsafer, LGTV_IP12, version

aktives Mitglied des FHEM e.V. (Technik)

Markus Bloch

Zitat von: Tobias am 19 Dezember 2016, 12:56:27
Auch mit "user Tobias" ändert sich an der Fehlermeldung nix. Genau diesen Usernamen hatt ich auch Rudi zusammen mit dem Public Key mitgegeben

Ich sehe keinen Verbindungsversuch mit Username Tobias bei mir im Log. Bitte das "U" am Anfang groß schreiben und nochmal probieren. Wenn du mit einem ssh svn.fhem.de die folgende Ausgabe erhälst, funktioniert die Verbindung:

( success ( 2 2 ( ) ( edit-pipeline svndiff1 absent-entries commit-revprops depth log-revprops atomic-revprops partial-replay inherited-props ephemeral-txnprops file-revs-reverse ) ) )


Dann kannst du via svn co .... auschecken.

Gruß
Markus
Developer für Module: YAMAHA_AVR, YAMAHA_BD, FB_CALLMONITOR, FB_CALLLIST, PRESENCE, Pushsafer, LGTV_IP12, version

aktives Mitglied des FHEM e.V. (Technik)

hexenmeister

#51
Zitat von: Markus Bloch am 19 Dezember 2016, 17:33:07
Du hattest heute um 17:03 Uhr und um 16:56 eine erfolgreiche Verbindung. Du hast also schonmal deinen korrekten Private-Key verwendet.

Hm, ja,.. mit PuTTY bekomme ich die Verbindung, aber checkout funktioniert nicht (weder mit Tortoise, noch per Commandline).
D:\temp\FHEM_Test2>svn co svn+ssh://svn.fhem.de/fhem/trunk/fhem
svn: E170012: Unable to connect to a repository at URL 'svn+ssh://svn.fhem.de/fhem/trunk/fhem'
svn: E170012: Can't create tunnel
svn: E720087: Can't create tunnel: Falscher Parameter.

Von meinem Linux-System bekomme ich schon gar keine SSH-Verbindung. Auch mit der id_rsa-Datei nicht.

Grüße
Alexander
Maintainer: MQTT_GENERIC_BRIDGE, SYSMON, SMARTMON, systemd_watchdog, MQTT, MQTT_DEVICE, MQTT_BRIDGE
Contrib: dev_proxy

Markus Bloch

Wenn die Verbindung in Putty klappt, kannst du mit dem entsprechenden Session-Namen in Putty, unter der die Verbindung funktioniert, in Tortoise auschecken. Dazu musst du den Putty-Sessionnamen als Hostnamen in der URL verwenden:

svn+ssh://sessionname/

Wenn deine PuTTY-Session also "svn.fhem.de" heist, kannst du mit svn+ssh://svn.fhem.de/ auch auschecken.

Gruß
Markus
Developer für Module: YAMAHA_AVR, YAMAHA_BD, FB_CALLMONITOR, FB_CALLLIST, PRESENCE, Pushsafer, LGTV_IP12, version

aktives Mitglied des FHEM e.V. (Technik)

Markus Bloch

Um unter Windows mit Tortoise auszuchecken musst du im Windows Explorer einen Ordner erstellen, dort hineingehen und dann Rechtsklick => "SVN Checkout" machen. Es öffnet sich ein Fenster und dort gibst du die Checkout-URL an.

Ich muss leider wieder ins Auto steigen. Evtl. können auch andere User, bei denen es bereits funktioniert dir weiterhelfen.
Developer für Module: YAMAHA_AVR, YAMAHA_BD, FB_CALLMONITOR, FB_CALLLIST, PRESENCE, Pushsafer, LGTV_IP12, version

aktives Mitglied des FHEM e.V. (Technik)

hexenmeister

#54
Danke für die schnelle Antwort.
Leider komme ich nicht weiter. Ich mache eigentlich alles genauso.
s. Anhang


EDIT: Verdammt, ich glaube, ich sehe den Fehler (Tippfehler beim Session-Namen)!

EDIT2: Auschecken geht! Danke für die Hilfe! Allerdings verstehe ich immer noch nicht, warum unter Linux nicht klappt...
Maintainer: MQTT_GENERIC_BRIDGE, SYSMON, SMARTMON, systemd_watchdog, MQTT, MQTT_DEVICE, MQTT_BRIDGE
Contrib: dev_proxy

betateilchen

Zitat von: hexenmeister am 19 Dezember 2016, 17:58:20
Allerdings verstehe ich immer noch nicht, warum unter Linux nicht klappt...

Welche Fehlermeldung bekommst Du denn, wenn Du versuchst, von der Kommandozeile eine ssh Verbindung aufzubauen?


ssh -l <userName> -p 55522 -i ~/.ssh/id_rsa 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!

chris1284

ich hätte da mal eine frage. das key-pärchen habe ich unter debian erstellt (openssh) in putty zu einen ppk konvertiert. die verbindung funktioniert auch, kann auch änderungen einchecken. nur bekomme  im svn gefühlt 1000 mal die abfrage des passwortes des provate keys. kann man dies unterbinden?

Markus Bloch

Unter Windows durch laden des Private-Keys in Pageant (Putty Agent). Dann musst du nur einmalig die Passphrase eingeben und der Agent authentifiziert alle Anfragen im Hintergrund. Unter Linux nennt sich dass ssh-agent.

Gruß
Markus

Developer für Module: YAMAHA_AVR, YAMAHA_BD, FB_CALLMONITOR, FB_CALLLIST, PRESENCE, Pushsafer, LGTV_IP12, version

aktives Mitglied des FHEM e.V. (Technik)

hexenmeister

Zitat von: betateilchen am 19 Dezember 2016, 19:21:59
Welche Fehlermeldung bekommst Du denn, wenn Du versuchst, von der Kommandozeile eine ssh Verbindung aufzubauen?


ssh -l <userName> -p 55522 -i ~/.ssh/id_rsa svn.fhem.de


Damit komme ich weiter:
ssh -l hexenmeister -p 55522 -i ~/.ssh/id_rsa svn.fhem.de
PTY allocation request failed on channel 0
( success ( 2 2 ( ) ( edit-pipeline svndiff1 absent-entries commit-revprops depth log-revprops atomic-revprops partial-replay inherited-props ephemeral-txnprops file-revs-reverse ) ) )

Die Verbindung steht also grundsätzlich. Über die konfigurierte Verbindung klappte es erstmal weiterhin  nicht:
ssh -v svn.fhem.de
OpenSSH_6.0p1 Debian-4+deb7u4, OpenSSL 1.0.1e 11 Feb 2013
debug1: Reading configuration data /home/alex/.ssh/config
debug1: /home/alex/.ssh/config line 1: Applying options for svn.fhem.de
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: Connecting to svn.fhem.de [88.99.31.202] port 55522.
debug1: Connection established.
debug1: identity file id_rsa type -1
debug1: identity file id_rsa-cert type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_7.2p2 Ubuntu-4ubuntu2.1
debug1: match: OpenSSH_7.2p2 Ubuntu-4ubuntu2.1 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.0p1 Debian-4+deb7u4
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-sha1 none
debug1: kex: client->server aes128-ctr hmac-sha1 none
debug1: sending SSH2_MSG_KEX_ECDH_INIT
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ECDSA 66:41:62:f3:45:ed:a3:59:93:28:c6:84:2d:36:b0:00
debug1: Host '[svn.fhem.de]:55522' is known and matches the ECDSA host key.
debug1: Found key in /home/alex/.ssh/known_hosts:8
debug1: ssh_ecdsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Trying private key: id_rsa
debug1: No more authentication methods to try.
Permission denied (publickey).


Erst als ich im  ~/.ssh/config 'IdentityFile id_rsa' durch 'IdentityFile ~/.ssh/id_rsa' ersetzt habe, klappte es endlich. Vlt. nutzt das jemanden noch :)

Vielen Dank!

Grüße
Alexander
Maintainer: MQTT_GENERIC_BRIDGE, SYSMON, SMARTMON, systemd_watchdog, MQTT, MQTT_DEVICE, MQTT_BRIDGE
Contrib: dev_proxy

Markus Bloch

Zitat von: hexenmeister am 19 Dezember 2016, 22:44:35
Erst als ich im  ~/.ssh/config 'IdentityFile id_rsa' durch 'IdentityFile ~/.ssh/id_rsa' ersetzt habe, klappte es endlich. Vlt. nutzt das jemanden noch :)

Das (und der Username) wird auch das Problem bei Tobias sein.

Gruß
Markus
Developer für Module: YAMAHA_AVR, YAMAHA_BD, FB_CALLMONITOR, FB_CALLLIST, PRESENCE, Pushsafer, LGTV_IP12, version

aktives Mitglied des FHEM e.V. (Technik)