Bonsoir
J'ai un hébergement mutualisé dont la configuration n'a pas changé depuis des années et qui a toujours bien fonctionné. J'ai voulu faire une mise à jour svn ce soir (la dernière mise à jour devait dater du 11 décembre) mais sans succès. Je reçois le message d'erreur:
ovh_ssh: /usr/bin/svnserve: Aucun fichier ou dossier de ce type
Visiblement quelque chose à changé du côté d'OVH, mais la documentation ne mentionne rien…
Merci pour votre aide.
Jette un oeil à https://community.ovhcloud.com/t/52061 cette réponse 
Merci beaucoup, passer la config en stable a réglé le problème !
Merci aussi d'avoir inclus la doc: je n'avais aucune idée du sens de « passer ovhconfig en stable » raison pour laquelle j'étais passé trop vite sur l'info hier soir quand je l'avais vu dans l'autre thread.
Bonjour, <br />Sur le même sujet/problème (échec de connexion SVN) :<br />Petite intro : Je réussissais à me connecter à SVN par SSH il y a quelques jours encore.<br />(Pour info, je ne suis pas spécialiste IT).<br /><br />----------<br />Information sur la configuration du serveur :<br />* le PHP est en version 7.2 stable<br />* après vérification, je me suis aperçu que le numéro de répertoire personnel avait changé : <br />/homez.645/monUser ---> /homez.773/monUser. J'ai donc changé ces info dans le autorized-keys(2), ce qui n'a rien changé au résultat<br />* la configuration du fichier config (.subversion) est :<br />...<br />[tunnels]<br />ssh = $SVN_SSH ssh <br />...<br /><br />----------<br />Test avec Putty :<br />* Connection/SSH/Auth : Attempt authentification using Pageant<br /><br />Le log du test avec Putty (avec ") donne :<br />Event Log: Looking up host "ftp.cluster006.hosting.ovh.net" for SSH connection<br />Event Log: Connecting to 51.68.11.200 port 22<br />Event Log: We claim version: SSH-2.0-PuTTY_Release_0.74<br />Outgoing raw data at 2020-08-21 13:56:48<br /> 00000000 53 53 48 2d 32 2e 30 2d 50 75 54 54 59 5f 52 65 SSH-2.0-PuTTY_Re<br /> 00000010 6c 65 61 73 65 5f 30 2e 37 34 0d 0a lease_0.74..<br />Incoming raw data at 2020-08-21 13:56:48<br />...<br />Event Log: Remote version: SSH-2.0-OpenSSH_7.4p1<br />Event Log: Using SSH protocol version 2<br />Event Log: No GSSAPI security context available<br />Outgoing packet #0x0, type 20 / 0x14 (SSH2_MSG_KEXINIT)<br />...<br />Incoming packet #0x0, type 20 / 0x14 (SSH2_MSG_KEXINIT)<br />...<br />Event Log: Doing ECDH key exchange with curve Curve25519 and hash SHA-256 (unaccelerated)<br />Outgoing packet #0x1, type 30 / 0x1e (SSH2_MSG_KEX_ECDH_INIT)<br />...<br />Incoming packet #0x1, type 31 / 0x1f (SSH2_MSG_KEX_ECDH_REPLY)<br />...<br />Incoming packet #0x2, type 21 / 0x15 (SSH2_MSG_NEWKEYS)<br />Event Log: Server also has ssh-rsa host key, but we don't know it<br />Event Log: Host key fingerprint is:<br />Event Log: ssh-************************************<br />Outgoing packet #0x2, type 21 / 0x15 (SSH2_MSG_NEWKEYS)<br />Event Log: Initialised AES-256 SDCTR (AES-NI accelerated) outbound encryption<br />Event Log: Initialised HMAC-SHA-256 (unaccelerated) outbound MAC algorithm<br />Event Log: Initialised AES-256 SDCTR (AES-NI accelerated) inbound encryption<br />Event Log: Initialised HMAC-SHA-256 (unaccelerated) inbound MAC algorithm<br />Outgoing packet #0x3, type 5 / 0x05 (SSH2_MSG_SERVICE_REQUEST)<br />...<br />Incoming packet #0x3, type 6 / 0x06 (SSH2_MSG_SERVICE_ACCEPT)<br />...<br />Event Log: Pageant is running. Requesting keys.<br />Event Log: Pageant has 1 SSH-2 keys<br />Outgoing packet #0x4, type 50 / 0x32 (SSH2_MSG_USERAUTH_REQUEST)<br /> 00000000 00 00 00 08 62 6d 70 6f 77 65 72 73 00 00 00 0e ....bmpowers....<br /> 00000010 73 73 68 2d 63 6f 6e 6e 65 63 74 69 6f 6e 00 00 ssh-connection..<br /> 00000020 00 04 6e 6f 6e 65 ..none<br />...<br />Incoming packet #0x4, type 51 / 0x33 (SSH2_MSG_USERAUTH_FAILURE)<br /> 00000000 00 00 00 12 70 75 62 6c 69 63 6b 65 79 2c 70 61 ....publickey,pa<br /> 00000010 73 73 77 6f 72 64 00 ssword.<br />Event Log: Trying Pageant key #0<br />Outgoing packet #0x5, type 50 / 0x32 (SSH2_MSG_USERAUTH_REQUEST)<br />...<br />Incoming packet #0x5, type 51 / 0x33 (SSH2_MSG_USERAUTH_FAILURE)<br /> 00000000 00 00 00 12 70 75 62 6c 69 63 6b 65 79 2c 70 61 ....publickey,pa<br /> 00000010 73 73 77 6f 72 64 00 ssword.<br />Event Log: Server refused our key<br />Event Log: Sent password<br />Outgoing packet #0x6, type 2 / 0x02 (SSH2_MSG_IGNORE)<br />...<br />Pour finir sur une connexion avec succès, mais seulement avec l'utilisateur de base et le mot de passe (en manuel) de base.<br />En résumé : <br />* j'arrive à me connecter au serveur OVH en SSH avec l'identifiant de base<br />* mais la clé (contenue sous Pageant) n'est pas reconnue.<br /><br />Si quelqu'un a une idée ?
Salut,
je pense que j'ai le même problème. Mon dépot qui fonctionnait correctement depuis 2 ans, et auquel je me suis connecté sans souci le 17/08 ne me permet plus de me logger depuis quelques jours.
Je suis très novice dans ce qui des dépots svn et utilisation de clefs, mais quand je fais la commande svn+ssh://loginFTP@clusterXXX/depot_test dans mon terminal (avec les bonnes valeurs bien sûr), un mot de passe m'est demandé, ce qui n'est pas normal me semble-t-il.
Vu les soucis qu'OVH a subit en fin de semaine, un service serait-il encore en attente d’exécution ?
Merci d'avance d'y jeter un oeil…
Salut,
J'ai le meme probleme.
J'utilise svn en svn+ssh via une paire de clé (en utilisant Pageant en local, et en configurant authorized_keys2 coté server). Je suis sur un server mutualisé.
Ca fonctionnait tres bien jusqu'a fin juillet / debut aout (2020), et depuis plusieurs années…
Aujourd'hui ca ne fonctionne plus. ca me demande un password…
(depuis le 19 / 08 / 2020)
Par contre, svn fonctionne avec le login/password ftp de base.
Quelqu'un aurait il trouvé une solution a ce probleme ?
Qu'est ce qui a changé coté OVH ?
Bonjour,
@MaximeR17 : peux-tu, stp, exliquer comment tu fais pour connecter svn 'en direct' ? tu le fais en svn:// et non en svn+ssh:// ?
Sinon, je me demandais si la configuration du SSH sur le serveur mutualisé n'a pas changé. Perte du lien vers autorized_user (avec ou sans 2, car ça aussi ça avait changé).
Je suis qu'un utilisateur de base qui sait juste copier des tutos. Linux (SSH tout ça) c'est trèèès obscur.
J'ai cru un moment que c'était à cause du client openSSH de W10 (que j'ai désactivé) mais les tests avec Putty (et surtout les logs) m'ont démontré le contraire.
OVH a eu de très gros souci en fin de semaine (page travaux). Comme ça correspond à la date où nos dépôts SVN sont devenus inaccessibles, je pense que tout n'a pas encore été rétabli chez OVH. Ou alors ils l'ont oublié 
J'ai peut-être une solution.
Après avoir lu qqpart que les clés DSA (toujours recommandées dans le tuto OVH) sont obsolètes (deprecated), j'ai testé l'ajout d'une clé d'un type moderne : ED25519.
–> Création avec PuttyGEN, je récupère la clé publique et la clé privée (.PPK)
–> log avec net2ftp.clusterXXX.hosting.ovh.net (mettre le votre
–> modif de .ssh/autorized_key (et pas _key2) : même commande SVN seul la partie clé change :
ssh-ed2519 CLEPUBLIQUE
au lieu de ssh-dsa CLEPUBLIQUE
Test avec putty : Connection/SSH/Auth : allow agent forwarding –> OK, le log montre que le serveur accepte la clé.
Test de ToirtoiseSVN (attention avec configuration NETWORK sans aucune commande dans la ligne client SSH)
Conclusion : pour moi bingo.
J'espère vraiment que ça va aider à débloquer certains.
Merci pour le retour. J'ai tenté de reproduire cette solution mais ça n'a rien donné.
Création clef : -> ssh-keygen -t ed25519
Création du fichier .ssh/autorized_keys sur le serveur
Intégration de la ligne de commande en remplaçant juste ssh-dss CLEF par ssh-ed25519 CLEF
->> Dans Eclipse, remplacement du fichier clef privée dans les propriétés de location du dépot : ça ne marche pas. Même résultat qu'avec la clef DSA
->> Dans le terminal, svn checkout svn+ssh://login@ftp.clusterXXX.hosting.ovh.net/depot réclame toujours un mot de passe
J'ai fait le test sur le fichier fichier .ssh/autorized_keys2 et le résultat est identique.
J'ai peut-être raté quelque chose dans la solution proposée…
@MICHELB55
Bonjour,
J'ai oublié de mettre en avant le fait que le répertoire du serveur avait changé pour moi (homez.XXX).
Pour savoir s'il a changé, je me suis logué avec Putty et l'identifiant FTP/SSH du site. Avec une petite commande "pwd", le nom du répertoire s'affiche en retour.
Du coup, correction du homez.XXX dans le authorized_keys :
"command="/usr/bin/svnserve --root=/homez.XXX/loginFTP/svn --tunnel…"
Bon courage !
Merci, mais j'avais vérifié le premier jour : mon homez.XXX est toujours le même.
Je vais continuer à chercher, mais je crois que la solution devra venir d'OVH : qu'il rétablissent la config, ou disent quoi utiliser si DSA est désactivé…
Merci encore pour le soutien !
De mon côté j'ai testé cette méthode (clé ed25519 dans authorized_keys)… et ça fonctionne ! Merci +++ @LionelM11
Ma crainte, c'est que subitement ça ne fonctionne plus.. ça m'a déjà fait ça avec une autre méthode que j'avais trouvé sur le net il y a qques semaines (remplacer le "ssh" par "ftp" dans l'adresse de connexion) - méthode qui a bien fonctionné mais que pendant une ou deux semaines.
<blockquote><br />DSA est désactivé...<br /></blockquote><br /><br />dsa? pas chez Ovh<br /><br /><blockquote><br />c'est que subitement ça ne fonctionne plus..<br /></blockquote><br /><br />rsa ou ed25519, c'est ok:<br />```text<br />sh-keyscan -p 22 -t ed25519 ftp.cluster028.hosting.ovh.net<br /># <a target="_blank">ftp.cluster028.hosting.ovh.net:22</a> SSH-2.0-OpenSSH_7.4p1<br />ftp.cluster028.hosting.ovh.net ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIPB4VaR3vPCBr936FaWqk+xIXXMuozx45AskwN2Tiw+D<br />```<br />```text<br />ssh-keyscan -p 22 -t rsa ftp.cluster028.hosting.ovh.net<br /># <a target="_blank">ftp.cluster028.hosting.ovh.net:22</a> SSH-2.0-OpenSSH_7.4p1<br />ftp.cluster028.hosting.ovh.net ssh-rsa AAAAB3NzaC1yc...HRl6b0fD1oB6lQ==<br />```<br /><br />je teste uniquement ces deux types de clés dans mes scripts de connexions, pas de soucis, chez Ovh ou ailleurs
Pour info, après 2 mois d'attente et d'échanges, j'ai finalement eu une réponse officielle du support :
"Je vous informe que les clés DSA ne sont plus disponible sur nos hébergements
mutualisés.
Il vous faut donc utiliser des clés ed25519."
oui DSA est déprécié
> OpenSSH 7.0 deprecated and disabled support for DSA keys due to discovered vulnerabilities, therefore the choice of cryptosystem lies within RSA or one of the two types of ECC.
https://wiki.archlinux.org/index.php/SSH_keys#Choosing_the_authentication_key_type
Merci pour ta réponse.
Pour ma part j'ai eu aussi fin septembre une réponse (sujet SSH KO) :
"…Afin que cela fonctionne, je vous invite à passer votre clef en RSA (au lieu de DSN)…".
a bientôt.
Bonjour à tous,
Je fais juste un dernier retour pour confirmer que le support OVH m'a dit d'utiliser une clef RSA car les clefs DSA sont désactivées.
Comme j'avais fait le test sans succès avec une clef RSA, j'étais un peu embêté, puis je suis tombé sur un article dans la doc OVH qui expliquait comment créer une clef RSA. J'ai fait le test et tout est rentré dans l'ordre.
Donc pour résumer :
* mauvaise méthode : ssh-keygen -t rsa
* bonne méthode : ssh-keygen -b 4096
J'espère que cette info triviale sera utile aux néophytes comme moi.