OVH Community, votre nouvel espace communautaire.

SSH et SFTP


seebz
08/08/2012, 10h07
Citation Envoyé par tony
Pour vos accès en SSH et SFTP, nous vous invitons à utiliser le nom de serveur suivant :

ssh.clusterNNN.ovh.net

et ne plus utiliser votre nom de domaine ou le nom de votre offre comme nom de serveur.

Le numéro de votre cluster se trouve dans votre manager, section hébergement mutualisé, dans le récapitulatif (cliquez sur Synthèse).

Tony
Ca pourrait être bien de mettre à jour le guide

nsecord75
01/08/2012, 11h08
Bonjour,

J'ai le même problème que vylain, l'accès FTP fonctionne parfaitement mais je n'arrive pas à me connecter avec SSH, la connexion est fermée immédiatement après l'authentification.

Si quelqu'un a des idées, je serais très reconnaissant.

Merci d'avance

ssh -v -o PreferredAuthentications=keyboard-interactive,password,publickey mondomaine@ssh.cluster015.ovh.net
OpenSSH_5.9p1, OpenSSL 0.9.8r 8 Feb 2011
debug1: Reading configuration data /etc/ssh_config
debug1: /etc/ssh_config line 20: Applying options for *
debug1: Connecting to ssh.cluster015.ovh.net [213.186.33.200] port 22.
debug1: Connection established.
debug1: identity file /Users/nsecord75/.ssh/id_rsa type 1
debug1: identity file /Users/nsecord75/.ssh/id_rsa-cert type -1
debug1: identity file /Users/nsecord75/.ssh/id_dsa type -1
debug1: identity file /Users/nsecord75/.ssh/id_dsa-cert type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.5p1 Debian-6+squeeze2
debug1: match: OpenSSH_5.5p1 Debian-6+squeeze2 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.9
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5 none
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Server host key: RSA 0a:dd:5f:f7:4d:f4:57:79:a6:2f:96:83:c6:d2:6e:37
debug1: Host 'ssh.cluster015.ovh.net' is known and matches the RSA host key.
debug1: Found key in /Users/nsecord75/.ssh/known_hosts:4
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: Next authentication method: keyboard-interactive
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: Next authentication method: password
mondomaine@ssh.cluster015.ovh.net's password:
debug1: Authentication succeeded (password).
Authenticated to ssh.cluster015.ovh.net ([213.186.33.200]:22).
debug1: channel 0: new [client-session]
debug1: Requesting no-more-sessions@openssh.com
debug1: Entering interactive session.
debug1: Sending environment.
debug1: Sending env LANG = en_US.UTF-8
debug1: client_input_channel_req: channel 0 rtype exit-status reply 0
debug1: client_input_channel_req: channel 0 rtype eow@openssh.com reply 0
debug1: channel 0: free: client-session, nchannels 1
Connection to ssh.cluster015.ovh.net closed.
Transferred: sent 2480, received 2056 bytes, in 0.1 seconds
Bytes per second: sent 35062.9, received 29068.3
debug1: Exit status 1

vylain
03/06/2012, 13h06
J'ai oublié de préciser: les tests ci-dessus on été fait sur Mac avec un shell bash.
Sur PC Windows, je n'arrive pas à me connecter en SSH avec PuTTY.
Avec Filezilla (PC Windows), voilà ce que j'obtiens en FTP et SFTP:


Connexion FTP
Statut : Résolution de l'adresse de ssh.cluster005.ovh.net
Statut : Connexion à 213.186.33.203:21...
Statut : Connexion établie, attente du message d'accueil...
Réponse : 220-Bienvenue,
Réponse : 220-
Réponse : 220- On Vous Héberge ?
Réponse : 220-
Réponse : 220-Vous êtes connecté sur web449.
Réponse : 220 This is a private system - No anonymous login
Commande : USER mondomaine-abc
Réponse : 331 User mondomaine-abc OK. Password required
Commande : PASS **********
Réponse : 230-User mondomaine-abc has group access to: users
Réponse : 230 OK. Current restricted directory is /
Commande : OPTS UTF8 ON
Réponse : 200 OK, UTF-8 enabled
Statut : Connecté
Statut : Récupération du contenu du dossier...
Commande : PWD
Réponse : 257 "/" is your current location
Commande : TYPE I
Réponse : 200 TYPE is now 8-bit binary
Commande : PASV
Réponse : 227 Entering Passive Mode (213,186,33,203,239,82)
Commande : MLSD
Réponse : 150 Accepted data connection
Réponse : 226-Options: -a -l
Réponse : 226 2 matches total
Statut : Contenu du dossier affiché avec succès
Statut : Déconnecté du serveur

Connexion SFTP
Statut : Connexion à ssh.cluster005.ovh.net...
Réponse : fzSftp started
Commande : open "mondomaine-abc@ssh.cluster005.ovh.net" 22
Commande : Pass: **********
Erreur : Connection closed by server with exitcode 1
Erreur : Impossible d'établir une connexion au serveur
Statut : Attente avant nouvel essai...
Statut : Délai d'attente de 1 seconde suite à l'échec de la précédente tentative de connexion...
Statut : Connexion à ssh.cluster005.ovh.net...
Réponse : fzSftp started
Commande : open "mondomaine-abc@ssh.cluster005.ovh.net" 22
Commande : Pass: **********
Statut : Connected to ftp.720plan.ovh.net
Erreur : Connection closed by server with exitcode 1
Erreur : Impossible d'établir une connexion au serveur

Nowwhat
03/06/2012, 12h49
Ta façon de procédure me semble correct.
Quoi que, avec PC 'Windows' ou 'Mac' j'utilise FileZilla, il a le protocole SFTP intégré.

L'accès SSH marche ?

vylain
02/06/2012, 12h42
Bonjour,

Je suis client de l'hébergement mutualisé version Pro.
Je dispose d'un compte FTP auquel j'arrive à me connecter en FTP non-sécurisé sans problème.
Je souhaiter dorénavant y accéder pas SFTP ou SSH, mais je n'y arrive pas.
Est-ce que l'offre Pro permet cela ?

Si oui, pourriez-vous m'expliquer pourquoi cela ne marche pas et ce qu'il faut faire pour corriger cela ?
Les réponses précédentes ne m'ont pas aidé à résoudre mon problème...

Ci-dessous des logs de connexion en FTP, SFTP et SSH: seul le FTP fonctionne.


MyComputer vylain$ ftp -v mondomaine-abc@ssh.cluster005.ovh.net
Connected to ssh.cluster005.ovh.net.
220-Bienvenue,
220-
220- On Vous Héberge ?
220-
220-Vous êtes connecté sur web291.
220 This is a private system - No anonymous login
331 User mondomaine-abc OK. Password required
Password:
230-User mondomaine-abc has group access to: users
230 OK. Current restricted directory is /
Remote system type is UNIX.
Using binary mode to transfer files.
ftp> dir
229 Extended Passive mode OK (|||42407|)
150 Accepted data connection
drwx---r-x 2 1070 users 2 May 30 18:37 .
drwx---r-x 2 1070 users 2 May 30 18:37 ..
226-Options: -a -l
226 2 matches total
ftp>
ftp>
ftp> exit
221-Goodbye. You uploaded 0 and downloaded 0 kbytes.
221 Logout.
MyComputer vylain$ sftp -v mondomaine-abc@ssh.cluster005.ovh.net
OpenSSH_5.6p1, OpenSSL 0.9.8r 8 Feb 2011
debug1: Reading configuration data /etc/ssh_config
debug1: Applying options for *
debug1: Connecting to ssh.cluster005.ovh.net [213.186.33.203] port 22.
debug1: Connection established.
debug1: identity file /Users/vylain/.ssh/id_rsa type -1
debug1: identity file /Users/vylain/.ssh/id_rsa-cert type -1
debug1: identity file /Users/vylain/.ssh/id_dsa type -1
debug1: identity file /Users/vylain/.ssh/id_dsa-cert type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.5p1 Debian-6+squeeze1
debug1: match: OpenSSH_5.5p1 Debian-6+squeeze1 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.6
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5 none
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host 'ssh.cluster005.ovh.net' is known and matches the RSA host key.
debug1: Found key in /Users/vylain/.ssh/known_hosts:4
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: Next authentication method: publickey
debug1: Trying private key: /Users/vylain/.ssh/id_rsa
debug1: Trying private key: /Users/vylain/.ssh/id_dsa
debug1: Next authentication method: keyboard-interactive
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: Next authentication method: password
mondomaine-abc@ssh.cluster005.ovh.net's password:
debug1: Authentication succeeded (password).
Authenticated to ssh.cluster005.ovh.net ([213.186.33.203]:22).
debug1: channel 0: new [client-session]
debug1: Requesting no-more-sessions@openssh.com
debug1: Entering interactive session.
debug1: Sending environment.
debug1: Sending env LANG = fr_FR.UTF-8
debug1: Sending subsystem: sftp
debug1: client_input_channel_req: channel 0 rtype exit-status reply 0
debug1: client_input_channel_req: channel 0 rtype eow@openssh.com reply 0
debug1: channel 0: free: client-session, nchannels 1
debug1: fd 0 clearing O_NONBLOCK
Transferred: sent 1648, received 2040 bytes, in 0.1 seconds
Bytes per second: sent 28593.8, received 35395.3
debug1: Exit status 1
Connection closed
MyComputer vylain$ ssh -v -o PreferredAuthentications=keyboard-interactive,password,publickey mondomaine-abc@ssh.cluster005.ovh.net
OpenSSH_5.6p1, OpenSSL 0.9.8r 8 Feb 2011
debug1: Reading configuration data /etc/ssh_config
debug1: Applying options for *
debug1: Connecting to ssh.cluster005.ovh.net [213.186.33.203] port 22.
debug1: Connection established.
debug1: identity file /Users/vylain/.ssh/id_rsa type -1
debug1: identity file /Users/vylain/.ssh/id_rsa-cert type -1
debug1: identity file /Users/vylain/.ssh/id_dsa type -1
debug1: identity file /Users/vylain/.ssh/id_dsa-cert type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.5p1 Debian-6+squeeze1
debug1: match: OpenSSH_5.5p1 Debian-6+squeeze1 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.6
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5 none
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host 'ssh.cluster005.ovh.net' is known and matches the RSA host key.
debug1: Found key in /Users/vylain/.ssh/known_hosts:4
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: Next authentication method: keyboard-interactive
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: Next authentication method: password
mondomaine-abc@ssh.cluster005.ovh.net's password:
debug1: Authentication succeeded (password).
Authenticated to ssh.cluster005.ovh.net ([213.186.33.203]:22).
debug1: channel 0: new [client-session]
debug1: Requesting no-more-sessions@openssh.com
debug1: Entering interactive session.
debug1: Sending environment.
debug1: Sending env LANG = fr_FR.UTF-8
debug1: client_input_channel_req: channel 0 rtype exit-status reply 0
debug1: client_input_channel_req: channel 0 rtype eow@openssh.com reply 0
debug1: channel 0: free: client-session, nchannels 1
Connection to ssh.cluster005.ovh.net closed.
Transferred: sent 2144, received 2120 bytes, in 0.1 seconds
Bytes per second: sent 29680.9, received 29348.6
debug1: Exit status 1

wiz-
17/05/2012, 17h48
Pour information:
Si vous souhaitez utiliser des clés différentes pour différents types de connexion, dans mon cas 1 clé pour le ssh et 1 clé pour le svn+ssh, vous pouvez, côté client (et dans le cas linux), créer un fichier config dans le dossier .ssh
et y mettre le contenu:
Host ftp.votrenomdedomaine.fr
IdentityFile /home/votre_homedir_local/.ssh/id_dsa_ovh_ssh
Host ssh.cluster006.ovh.net
IdentityFile /home/votre_homedir_local/.ssh/id_dsa_ovh_svn

à remplacer bien entendu par les bons noms.
Attention, dans IdentityFile, vous devez référencer les fichiers contenant les clés privées et non pas les clés privées.

Plus de détails ici : http://www.gsp.com/cgi-bin/man.cgi?s...pic=ssh_config

wiz-
17/05/2012, 14h02
J'avais bien utilisé les clés publiques dans tous mes tests précédents.
J'ai trouvé le problème ! :
lorsque je générais mes clés, au lieu de laisser (en local côté client sous ubuntu) le nom de fichier proposé par défaut (/home/user_home/.ssh/id_dsa ou /home/user_home/.ssh/id_rsa), je choisissais /home/user_home/.ssh/id_dsa_ssh_ovh par exemple.
Il semble que ça ne fonctionne pas... Je pensais que ssh prenait toutes les clés publiques du dossier .ssh, j'imagine que j'ai mal supposé !

Merci pour votre aide précieuse !

fatumbi
17/05/2012, 12h14
bhen voilà, un truc bien clair : déjà, ça devrait rouler sans pb en ssh et sans demander ton pass (pas de rapport avec svn, tunnel etc...)

Et là, je sens donc poindre un semblant de confusion sur la paire de clé ;-) :
La clé privée reste dans le .ssh/ du client
C'est bien la clé publique qui doit être communiquée au serveur dans son authorized_keys2

Le principe : le user (client) possède son identité et a donc sa clé a lui (privée). Il donne aux autres (serveurs, correspondants mails, etc...) sa clé publique.

Retente tout propre et en douceur :

Génère les clés sans pass pour commencer, ensuite on s'en passe aussi très bien : Ce mot de passe là ne fait que protéger le fichier d'une lecture par quelqu'un d'autre et n'a rien a voir avec la sécurité de la connexion elle-même.

Une seule clé dans authorized_keys2 sur le serveur et sur une seule ligne
Copié/collé de la clé publique générée, avec un éditeur de texte honnête sous ubuntu (vi p ex^^) et sans rien modifier ni ajouter (pas de 'tunnel'....)

Connecte toi en ssh.

Il ne devrait rien te demander comme password.

Connecte toi en svn+ssh (sans tunnel) : ça devrait marcher aussi, (je crois, mais c'est moins sur, mon souvenir est vague là) pour un seul user donc.

Après seulement, ajoute ou modifie authorized_keys2 du serveur pour faire un tunnel svn.

wiz-
17/05/2012, 11h05
Bonjour,

merci pour vos explications et votre aide !

- j'avais essayé avec et sans mot de passe pour la génération de la clé => Pas de changement. J'ai laissé tomber le mot de passe, et généré les clés sans pass.

- j'indiquais le user svn donc effectivement ça ne fonctionnait pas, même en rentrant un mot de passe => J'ai remplacé par le user ssh.

- effectivement le mot de passe demandé est bien celui de la connexion SSH

- pour l'option -q (côté server .subversion/config), elle me serait utile pour comprendre plus en détails le problème. Le fait que ça ne change pas le résultat me perturbe et je me demande si je n'ai pas un problème en amont de svn, puisque l'avoir enlevée ne change pas le comportement

- pour la ligne par user svn command="/usr/bin/svnserve --root=/homez.YYY/Domaine/svn --tunnel --tunnel-user=User_Svn",no-port-forwarding,no-agent-forwarding,no-X11-forwarding,no-pty ssh-dss User_Client@Machine_Client ça me semble être bon (en théorie), mais j'ai un doute au vu du résultat. C'est bien sur 1 seule ligne

- pour la connexion ssh_user avec clé: je lancais un ssh sans clé dans le authorized_keys2, par sécurité pour le test, j'ai ajouté une clé (rsa pour le ssh et dss pour le svn)

=> résultats actuels:
- la connexion en ssh fonctionne mais je dois saisir mon mot de passe ssh (clé générée sans mot de passe)
- la connexion ssh+svn: me demande mon mot de passe. partie ssh ok si je le saisis mais j'ai une erreur que je ne comprends pas (je ne connais pas vraiment svn en details):
svn: No repository found in 'svn+ssh://ssh_user@ssh.cluster006.ovh.net/depot'
avec depot qui est le depot que j'ai créé par :
(à partir du home dir, connecté en ssh)
mkdir svn
svnadmin create svn/depot

Je pense donc qu'il y a (au moins) 2 pbs:
- reconnaissance des clés publiques ssh, que ce soit pour la connexion ou le svn
- problème avec svn pour le dépot (ou autre)

fatumbi
16/05/2012, 10h18
Salut,
S'il te demande un mot de passe, c'est que la clé ssh n'est pas reconnue par svn / ou n'est pas 'tunnelé'.
Le mdp demandé est alors ton mdp de connexion ssh (le même qu'en ftp) et user doit être l'admin du site hébergé.

Connecté comme ça, SVN signera ses modif du nom de l'admin de ton site (ton nom de domaine).

Sinon, comme j'ai un peu galéré, je pense avoir fait le tour des soucis ^^:

Ok pour l'option -q côté serveur, et au cas où et surtout, rien d'autre à faire qu'à modifier .ssh/authorized_key2.
Côté client, .svn/config n'a aucune incidence : c'est une config de serveur, le client n'en a rien à faire...

Ensuite attention :
Il faut bien te connecter avec l'adresse suivante, et tous les users du svn se connectent donc de la même manière avec :
svn checkout svn+ssh://SSH_USER@ssh.cluster006.ovh.net/le_depot_svn
ils seront aiguillés d'après leur clé selon chaque ligne ajoutée pour chacun dans authorized_key2


Ici, SSH_USER est ton nom de domaine, qui va être redirigée vers un autre user spécifique à svn: dans le .ssh/authorized_key2 penses bien que :


1/ Que tu as 3 users différents sur la ligne que tu as ajoutée :
command="/usr/bin/svnserve --root=/homez.YYY/Domaine/svn --tunnel --tunnel-user=User_Svn",no-port-forwarding,no-agent-forwarding,no-X11-forwarding,no-pty ssh-dss User_Client@Machine_Client

- homez.YYY/Domaine : "Domaine" est le user principal du domaine sur la machine mutualisée, c'est "SSH_USER".
- user=User_Svn : "User_Svn" est un pseudo utilisateur juste pour svn. Le nom qu'il utilisera pour signer les modifications.
- User_Client@Machine_Client : c'est juste un commentaire ajouté a la création de la clé sur ta machine cliente pour qu'un humain reconnaisse la clé à la relecture du fichier.

Ensuite homez.YYY est le répertoire montré par "pwd" qd tu te connectes en ssh.

3/ l'autre souci que tu peux avoir (et j'ai tourné longtemps), c'est que tu ne peux pas "tuneler" SSH_USER pour svn et l'utiliser aussi directement en ssh avec le même type de clé.
Pour contourner sur le client d'admin, j'ai une clé 'utilisateur_svn' et une autre 'utilisateur_ssh' de deux types différents rsa et dss.
D'ou deux lignes :
ssh-rsa
command="/usr/bin/svnserve --root=/homez.YYY/SSH_USER/svn --tunnel --tunnel-user=SSH_USER",no-port-forwarding,no-agent-forwarding,no-X11-forwarding,no-pty ssh-dss

Guillaume.S
16/05/2012, 09h45
Bonjour,

Lorsque tu as généré ta clée sur ton poste, tu as mis un mot de passe ?
(Etape CREATION DES CLES PUBLIQUES/PRIVEES sur le guide OVH)

Si tu n'as pas mis de mot de passe, et que le serveur t'en demande un, c'est qu'il ne reconnait pas ce que tu as mis dans "~/.ssh/authorized_keys2".
(Tout doit être sur une seule et même ligne)

Cordialement,

wiz-
16/05/2012, 08h37
des news ? Faut il contacter le support OVH ?

wiz-
12/05/2012, 23h36
Bonsoir,
je rencontre moi aussi des problèmes.
J'ai suivi le guide (http://guide.ovh.com/SVNMutu), puis essayé différentes choses décrites sur ce forum:
- supprimé toutes les clés sur mon pc (kubuntu 12.04), carrément supprimer le dossier .ssh
- modifié le ".subversion/config" pour décommenter la ligne ssh, en supprimant l'option -q, a la fois sur le server & mon pc
- ajouté des utilisateurs sur "autz"...

En fin de compte, après avoir supprimé les clés puis en avoir recréé, il m'est demandé la 1ere fois si je suis sur de vouloir accéder au server & conserver la clé, je réponds oui.
A chaque tentative :
svn checkout svn+ssh://*****@ssh.cluster006.ovh.net/****
j'obtiens :

*****@ssh.cluster006.ovh.net's password:
Permission denied, please try again.
*****@ssh.cluster006.ovh.net's password:
Permission denied, please try again.
*****@ssh.cluster006.ovh.net's password:
Permission denied (publickey,password,keyboard-interactive).
svn: To better debug SSH connection problems, remove the -q option from 'ssh' in the [tunnels] section of your Subversion configuration file.
svn: La connexion réseau a été fermée de façon inattendue

Je ne comprends pas
- pourquoi il m'est demandé un mot de passe
- quel mot de passe devrait etre donné
- pourquoi il m'est indiqué de supprimer l'option -q alors que je pense l'avoir déjà fait (local + server)

Une autre personne a testé sous windows + tortoise (avec un autre tunnel-user), elle rencontre les mêmes problèmes.

Je n'avais pas mis en place ni utilisé svn précédemment.

Savez vous comment progresser sur ces problèmes ?

azerty37
07/05/2012, 17h10
Citation Envoyé par azerty37
Voilà Guillaume, ton diagnostic s'affine ! De cette façon, en forçant le login avec le mot de passe ça fonctionne !

J'ai refait des essais autour des clés, et c'est toujours la même erreur. Il n'y a que l'auth avec mot de passe qui fonctionne.

J'ai trouvé. C'était la même clé pour SSH et SVN+SSH, et ça ne fonctionne pas dans ce cas. Une clé différente pour chaque usage et ça va beaucoup mieux.

Donc je retrouve maintenant l'usage de SSH et de SFTP, c'est beaucoup mieux.

Merci.

azerty37
07/05/2012, 11h55
Citation Envoyé par Guillaume.S
Re,

Tu pourrais essayer avec cette commande :
ssh -o PreferredAuthentications=keyboard-interactive,password,publickey TONLOGIN@ssh.cluster005.ovh.net
Cordialement,
Voilà Guillaume, ton diagnostic s'affine ! De cette façon, en forçant le login avec le mot de passe ça fonctionne !

J'ai refait des essais autour des clés, et c'est toujours la même erreur. Il n'y a que l'auth avec mot de passe qui fonctionne.

Guillaume.S
07/05/2012, 11h24
Re,

Tu pourrais essayer avec cette commande :
ssh -o PreferredAuthentications=keyboard-interactive,password,publickey TONLOGIN@ssh.cluster005.ovh.net

Cordialement,

Guillaume.S
07/05/2012, 11h21
Bonjour,

En essayant d'enlever l'adresse du serveur de ton ~/.ssh/known_hosts ?

L'erreur que tu as, c'est en te connectant en SVN ? Pas en SSH ?

Cordialement,

azerty37
06/05/2012, 01h45
Citation Envoyé par Guillaume.S
@azerty37 : tu as l'erreur avant ou après avoir rentré ton pass ?
Juste après l'envoi de la commande.

J'ai essayé aussi en supprimant ma clé (~/.ssh/id_rsa) pour voir si ça changeait qlq chose, mais rien. La même erreur.

Guillaume.S
02/05/2012, 15h51
Re,

@barme :
Effectivement, le serveur SSH de cluster002 a été indisponible de 18h48 jusque 19h25 ce Lundi 30 avril. (Check Logs + Alertes)

Il a rebooté (je cherche pourquoi), et il n'est pas rentré de suite dans le cluster (corrigé, un process a mal démarré et a mis le serveur en "indisponbile" par sécurité).
Une intervention humaine a été nécessaire derrière, d'où le temps d'indisponibilité.

Désolé pour ce contre-temps.

Cordialement,

barme
02/05/2012, 11h36
Oui, c'est bien l'adresse que j'utilise.
Cela fonctionne bien maintenant.

Guillaume.S
02/05/2012, 10h05
Bonjour,

@barme : Tu utilises bien "ssh.cluster002.ovh.net" comme adresse de connection au serveur SSH ?

Cordialement,

barme
30/04/2012, 19h27
Même problème d'utilisation du ssh sur cluster002, avec un autre message d'erreur : Connection refused

Guillaume.S
27/04/2012, 10h03
Bonjour,

@azerty37 : tu as l'erreur avant ou après avoir rentré ton pass ?

D'autres personnes ont ce problème sur le cluster005 ?

Cordialement,

azerty37
26/04/2012, 19h59
le SSH et SFTP ne fonctionne pas sur ssh.cluster005.ovh.net

$ ssh xxxx@ssh.cluster005.ovh.net
PTY allocation request failed on channel 0
( success ( 2 2 ( ) ( edit-pipeline svndiff1 absent-entries commit-revprops depth log-revprops partial-replay ) ) )

pesoft
15/04/2012, 16h03
Ca ne fonctionne toujours pas avec les logins multi-ftp ?

Ukri
12/04/2012, 10h04
Bonjour à tous,

Après avoir un tout petit peu galéré, voici le problème que je rencontrais depuis quelques jours et ce que j'ai fait pour le résoudre :

En ssh, lorsque je lançais une commande svn depuis le serveur, j'obtenais
Code:
svn: To better debug SSH connection problems, remove the -q option from 'ssh' in the [tunnels] section of your Subversion configuration file.
svn: Network connection closed unexpectedly
En allant sur le fichier de conf (/.suversion/config) tout est commenté.
J'ai mis dans la section [tunnel] ceci :

Code:
ssh = $SVN_SSH ssh -o ControlMaster=no
Il semblerait que par défaut le -q soit ajouté... Avec la ligne ci-dessus on change de message !

Code:
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that the RSA host key has just been changed.
[......]
Host key verification failed.
J'ai donc supprimé des hôtes connus avec la commande
Code:
ssh-keygen -R example.com
A la commande svn suivante, j'obtiens ceci :
Code:
The authenticity of host 'example.com (x.x.x.x)' can't be established.
RSA key fingerprint is [.....].
Are you sure you want to continue connecting (yes/no)? yes
Et hop tout refonctionne !

Si ça peut être utile à quelqu'un... Bon perso j'ai pas tout compris, s'il y a des boulettes là-dedans merci de le dire !

Guillaume.S
11/04/2012, 18h39
Bonjour,

Oui la nouvelle clef SSH pour le cluster010/60gp est :
cluster010 fini : 52:f8:78:4e:5f:6e:05:63:dd:4b:9e:d9:72:2f:04:87

Dans quelques secondes sur guide.ovh.com.

On vient de finir le nouveau serveur SSH pour 60gp sur travaux :
https://travaux.ovh.net/?do=details&id=6557

Cordialement,

Rudloff
11/04/2012, 18h34
Quand j'essaie de me connecter, SSH me dit que l'empreinte a changé. Le serveur me renvoi cette empreinte (qui n'est pas indiquée ici) :
Code:
52:f8:78:4e:5f:6e:05:63:dd:4b:9e:d9:72:2f:04:87
Est-ce que OVH a changé ses empreintes récemment ?
Est-ce risqué de se connecter ?

lmars
11/04/2012, 16h21
Citation Envoyé par Papageno3
Bonjour,

Cela fait 1 mois que je me prends la tête pour retrouver mon accès par sFTP et SSH : j'ai dû ouvrir un ticket incident, qui ne m'a donné la réponse qu'à l'instant même, et ce 2 jours après avoir ouvert le ticket...

N'aurait-il pas été un minimum fairplay d'informer directement vos clients? Un petit mail à tous les clients sur mutus ça ne mange pas de pain bon sang! Tout le monde ne traîne pas sur ce forum pour avoir les infos.

Je suis sûr qu'en ce moment même il y a des clients mutus qui tournent en rond et qui doivent être en train de pester conter OVH

Papageno3
Et oui, même chose : Comme d'habiiittuuude ...

dsaunier
10/04/2012, 15h59
Suivi, souci idem pour moi aussi et très bloquant vu mon travail actuel de rsync.

pesoft
10/04/2012, 12h01
sauf pour les autres comptes FTP que j'ai créé pour mon multi-dom, pour eux ça marche toujours pas.

pesoft
10/04/2012, 11h58
ha oui ... mieux :-)

Beluc
10/04/2012, 11h32
mieux ?

Le 04/10/12 09:55, pesoft a écrit :
> Je suis sur cluster002 et ça ne fonctionne pas... j'ai essayé
> ssh.cluster002 et ftp.cluster002, d'ailleurs il a proposé une nouvelle
> empreinte pour chacun des deux mais après il va pas plus loin.
>
>


pesoft
10/04/2012, 09h55
Je suis sur cluster002 et ça ne fonctionne pas... j'ai essayé ssh.cluster002 et ftp.cluster002, d'ailleurs il a proposé une nouvelle empreinte pour chacun des deux mais après il va pas plus loin.

Lecden
10/04/2012, 09h00
J'ai également le problème (uniquement en SFTP sur cluster002 sous filezilla), est-ce lié par hasard au CDN que j'ai nouvellement activé ?

seishi
21/02/2012, 21h09
Ne vous dérangez pas, à la lecture des différents incident je préfère utiliser mon droit de rétractation.

Merci.

seishi
21/02/2012, 19h57
Bonsoir,

Impossible d'effectuer la moindre commande vu qu'a m'a connexion je me retrouve à la racine ("/"). Du coup je n'ai aucun droit... :/

Message d'erreur :
Could not chdir to home directory /homez.514/mon_id: No such file or directory

Est-ce normal ? Qu'ai je raté ?

Cordialement,

Daniel60
10/02/2012, 10h18
Citation Envoyé par nbonniot
... Ce qui fait que j'e n'ai aucun numéro de cluster pour substituer à ma commande SVN+SSH actuelle.
Comment puis-je le trouver?...
C'est indiqué par Tony sur le premier message.

Nowwhat
10/02/2012, 10h08
Luut,

Normalement ('chez moi'): https://www.ovh.com/managerv3/ => Hébergements et domaines => [Ton domaine] => Mutualisé => Hébergement => Synthèse

nbonniot
10/02/2012, 08h59
Bonjour,

J'ai pour ma part un hébergement start 10G qui a évolué en pro l'année dernière... Ce qui fait que j'e n'ai aucun numéro de cluster pour substituer à ma commande SVN+SSH actuelle.

Comment puis-je le trouver? Merci pour votre retour rapide car franchement comme beaucoup d'utilisateurs de ce thread et je trouve franchement moyen qu'aucune comm n'ait été faite à ce sujet : c'est déjà pas simple de trouver les bonnes informations pour mettre en place le SVN+SSH (votre page SVNMutu contient la moitié de ce qu'il faut faire pour que ça marche), mais si en plus vous changer des informations aussi structurantes que l'accès sans en informer personne...

Donc comment puis-je avoir mon numéro de cluster?

Salutations,

Nicolas BONNIOT

Papageno3
01/02/2012, 17h59
Citation Envoyé par tony
Pour vos accès en SSH et SFTP, nous vous invitons à utiliser le nom de serveur suivant : ssh.clusterNNN.ovh.net et ne plus utiliser votre nom de domaine ou le nom de votre offre comme nom de serveur.
Bonjour,

Cela fait 1 mois que je me prends la tête pour retrouver mon accès par sFTP et SSH : j'ai dû ouvrir un ticket incident, qui ne m'a donné la réponse qu'à l'instant même, et ce 2 jours après avoir ouvert le ticket...

N'aurait-il pas été un minimum fairplay d'informer directement vos clients? Un petit mail à tous les clients sur mutus ça ne mange pas de pain bon sang! Tout le monde ne traîne pas sur ce forum pour avoir les infos.

Je suis sûr qu'en ce moment même il y a des clients mutus qui tournent en rond et qui doivent être en train de pester conter OVH

Papageno3

saimon
24/01/2012, 17h19
ma connection ssh sur le cluster 003 ne fonctionne plus depuis plusieurs jours ... connection refusée.

[edit] pb résolu (blacklistage d'ip), merci au support

fatumbi
22/01/2012, 11h21
Il semble que le ticket d'incident soit clos depuis le 10 janvier (http://travaux.ovh.net/?do=details&id=6237&edit=yep)

Par contre l'accès reste impossible à ssh://log@domaine.xx

Est-ce vraiment définitif ?

Je n'ai pas bien envie de communiquer "mondomaine@ssh.clusterNNN.ovh.net" à "tout le monde" :-/

rosmord
15/01/2012, 13h19
Pour les utilisateurs de SVN, je me permets de résumer les opérations à effectuer pour se mettre à jour :

Supposons qu'on ait le site toto.fr

0) manager/hébergement/synthèse pour voir le cluster (par exemple ligne "serveur web")
a) comme dit précédemment, pour se simplifier la vie, se créer un alias
Manager OVH => DNS => Zone DNS et CNAME:
ssh.toto.fr qui pointe vers ssh.clusterNNN.ovh.net

b) attendre !! que le DNS soit à jour (tester si host ssh.toto.fr renvoie quelque chose).

c) Chaque utilisateur distant doit faire un relocate (ou alors un simple checkout du programme avec la nouvelle version, mais c'est embêtant s'il a fait des modifications).

Donc, l'utilisateur doit aller dans son projet et taper :

svn switch --relocate svn+ssh://toto@toto.fr/monProjet svn+ssh://toto@ssh.toto.fr/monProjet

Pas de modification à faire sur le site lui-même ?

miki
14/01/2012, 15h46
Je me reponds tout seul pour ceux que ca interesse:
Sans rien changer sur mes PC portables a part que je suis chez moi (j'etais en deplacement durant la panne), SVN tortoise remarche dans windows. Bizarre...
Sous Linux suse 11.3, j'ai fait le relocate des bases SVN et la ca remarche aussi.
Mais le ssh toujours pas, par contre il est devenu bcp plus loquace, comme s'il y avait de nouveau de la vie de l'autre cote de la ligne.

miki
13/01/2012, 09h10
En comparant avec les autres users pour qui la manip de changement de nom de serveur vers le nom avec NNN fonctionne sous tortoise et sous linux et qui peuvent se connecter en ssh, je pense que c'est un probleme specifique ssh pour moi. En gros, c'est comme si mes tentatives de connexion depuis linux pour trouver la parade a la panne SSH chez OVH avait bloque mon acces.

miki
12/01/2012, 22h03
@Nowwhat: Oui, j'ai bien mis le numero, et le preuve c'est que sous Tortoise+Putty+SVN ca a marche tout de suite. Sous linux, mondomaine.com ne donne plus aucune reponse pdt pas mal de tps avant de mourir, alors que le nouveau nom avec NNN envoie balader illico.
@mariek: pas sur de savoir ce qu'est CNAME, mais dans mon cas, il y a plusieurs user windows, plusieurs user Linux, et pour les chanceux ca a marche tout de suite. Mais apres les essais, c'est tombe en panne.

mariek
12/01/2012, 21h38
@miki la création du CNAME prend pas mal de temps (perso ça a pris la journée pour fonctionner)

Nowwhat
12/01/2012, 21h35
Bonsoir,
T'as bien remplacé NNN par le numéro de cluster, n'est pas ?

miki
12/01/2012, 21h25
Bonjour,

Meme cas que Grunzig: on a svn_tortoise+Putty / ssh, sous windows, et svn/ssh sous linux. Apres avoir galere plusieurs jours on a finalement trouve l'info sur le fait qu'il ne fallait plus pointer sur mondomaine.com mais sur le ssh.clusterNNN.ovh.net . C'est vrai que ca meritait qd mm un petit email. Bref.

La mise a jour dans Putty pour Tortoise a marche pour tout le monde (changement du serveur dans Putty et hop).

Par contre sous linux, ssh mondomaine@ssh.clusterNNN.ovh.net repond de facon variable:
- pour certains ca marche: connexion directe, svn OK
- pour certains ca demande un mot de passe, et ce mot de passe ne semble plus etre celui du ManagerV3. Du coup refus, pas de ssh, pas de svn evidemment.
- apres qq essais (mot de passe, nom de serveur...), maintenant c'est directement refus de connexion. Mais ce qui est facheux, c'est que ca s'etend aux Tortoise sous windows qui marchaient hier et qui maintenant se voient aussi l'acces refuse.

J'arrive ici avec le lien du mail de reponse du support, peut-etre que qqun a une idee de ce qui se passe dans notre cas ?

Merci

mariek
12/01/2012, 09h35
Bonjour,
Pour SVN avec Tortoise, je suppose qu'il faut faire un relocate ?
Quelle est la syntaxe exacte ? J'ai ça à la base :
svn+ssh://login@domaine.fr/homez.XX/login/svn/mon_espace_svn
je remplace domaine.fr par ssh.cluster010.ovh.net ?
svn+ssh://login@ssh.cluster010.ovh.net/homez.XX/login/svn/mon_espace_svn
Merci pour votre aide.
[EDIT]je me reponds à moi-même : oui, c'est bien ça.[/EDIT]

amourissime
11/01/2012, 16h06
Citation Envoyé par Nowwhat
Ah.ok. Compris.

Mais cette situation n'a pas changé depuis hier.
Personne (clients), depuis le 11 années existence d'OVH ont eu l'accès 'root' au serveurs d’hébergement mutualisé d'OVH.
Ceci inclus toi - moi, etc.

SI les utilisateurs d'un hébergement Pro, Perso ou autre ONT l'accès root, tet bien, nos sites existerons plus pour demain.

Sache que tout le monde arrive bien à utiliser SON base des données SQL ... (lié à ton hébergement).

Seul solution: veuillez prendre un serveur dédié pour avoir un accès 'root' à toi.
C'est avec un dédié que ton boîte aura le droits de trafiquer le mysql et autre config.
Explique-leur que tu as loué un service hébergement mutualisé. Explique-les aussi que ovh.com possède des FAQ, manuels et autres guides en Anglais (va voir le site version anglais) ... ceci évitera qu'on t'envoie des question 'bizarre'.

D'ailleurs, ta question n'est pas lié au premier post de Tony. L'accès 'root' n'a jamais existé.
Bonjour et merci pour la réponse

je ne peux pas me permettre d'en prendre un beaucoup trop cher. l'accès ssh n'étant pas possible, j'ai demandé à la société qui m'a vendu le script de me le rembourser
La société à acceptée, j'ai la somme sur paypal.
Cette société a été honnête.
Cordialement
jacky

Grunzig
10/01/2012, 17h15
Je peux comprendre que pour des raisons de sécurité, on fasse des modifications mais la moindre des choses c'est tout de même de prévenir les clients, surtout lorsque ça occasionne une perturbation / interruption du service.

De plus, dans le mail me fournissant les informations d'accès à mon hébergement, j'ai eu ça :

Avec votre hébergement, vous avez aussi la possibilité de vous
connecter via ssh sur les serveurs.

Serveur ssh : mondomaine.com ou pro.ovh.net

sans le ssh. devant le nom de domaine !

En sachant que le mail est daté du 13 avril 2011, on pouvait supposer que les informations données étaient exactes. Surtout que tout fonctionnait jusqu'à hier matin...

Bref.... maintenant ça fonctionne, c'est le principal.

Merci à Tony, bachbach et Nowwat.

Comme indiqué plus haut par Nowwat, il faut faire :
Manager OVH => DNS => Zone DNS et ajoute un CNAME:
ssh.votre_domaine.tld qui pointer vers ssh.clusterNNN.ovh.net

tony
10/01/2012, 14h22
Normal, quand tu fais ssh domaine.com, tu ne passes pas par le bon réseau.
On a maintenu ce passage en fonctionnement un moment, mais là ce n'est plus possible, ça pourrait provoquer une faille de sécurité.

Tony

Grunzig
10/01/2012, 13h46
Citation Envoyé par Nowwhat
Pour autant:
Un ssh vers ssh.cluster002.ovh.net marche très bien ...

Un ping vers ssh.cluster002.ovh.net te donne bien l'IP 213.186.33.201 (ceci est l'IP de cluster002 - bien sur, t'as PAS donné la tienne ...).
oui, ça fonctionne avec le nom de domaine du cluster mais pas avec le mien

ssh mondomaine.com ne fonctionne pas
ssh ssh.cluster006.ovh.net fonctionne

Du coup, je viens de vérifier le ping vers mon nom de domaine, et ça me renvoie un timeout...

Par contre, en http, je n'ai aucun souci.

La seule chose qui ne passe pas est : ssh mondomaine.com

bachbach
10/01/2012, 13h39
Merci Nowwhat !
mon manque d'attention, du coup tout fonctionne très bien, avec
Manager OVH => DNS => Zone DNS et ajoute un CNAME:
ssh.votre_domaine.tld qui pointer vers ssh.clusterNNN.ovh.net

merci !

Nowwhat
10/01/2012, 13h15
Citation Envoyé par Grunzig
J'ai essayé de me connecter en ssh (pour tester, sans svn) et il ne se passe rien en fait... plusieurs minutes s'écoulent sans que rien ne se passe, comme si ssh attendait une réponse du serveur. Je n'ai même pas l'invite de saisi du mot de passe.
Pour autant:
Un ssh vers ssh.cluster002.ovh.net marche très bien ...

Un ping vers ssh.cluster002.ovh.net te donne bien l'IP 213.186.33.201 (ceci est l'IP de cluster002 - bien sur, t'as PAS donné la tienne ...).

bachbach
10/01/2012, 11h57
+1

avec git+indefero sur le serveur, et tower sur les machines
http://forum.ovh.com/showthread.php?...light=indefero
besoin de ssh://identifiant@domaine.net/projet.git

avec le terminal : connexion ssh se perd dans le vide aussi bien avec le domaine qu'avec le cluster.

impossible de bosser dans ces conditions !
please …

Grunzig
10/01/2012, 11h42
Citation Envoyé par tony
Normalement ça doit fonctionner sur le nouveau serveur. Tu as quoi comme erreur ?

Tony
J'ai essayé de me connecter en ssh (pour tester, sans svn) et il ne se passe rien en fait... plusieurs minutes s'écoulent sans que rien ne se passe, comme si ssh attendait une réponse du serveur. Je n'ai même pas l'invite de saisi du mot de passe.

tony
10/01/2012, 11h09
Normalement ça doit fonctionner sur le nouveau serveur. Tu as quoi comme erreur ?

Tony

Grunzig
10/01/2012, 09h14
Bonjour,

Nous utilisons SVN sur un serveur mutualisé pro, via svn+ssh sur le nom de domaine de l'hébergement. Donc là, on galère un peu pour travailler.
Est ce qu'il y aurait une solution pour contourner ce problème ?
Quelqu'un aurait une idée du temps de l’interruption de services ?

Merci pour votre aide.

Gaston_Phone
09/01/2012, 20h00
Citation Envoyé par Nowwhat
Oulà, Gaston_phone !!!
Je m'image pas que cette question est venu de toi.
L'accès SSH permet le fameuse SFTP
Ben quoi!

Nota : on peut très bien dézipper tout un dossier avec gunzip via la commande system() mise dans un script.php.

Nowwhat
09/01/2012, 18h27
Ah.ok. Compris.

Mais cette situation n'a pas changé depuis hier.
Personne (clients), depuis le 11 années existence d'OVH ont eu l'accès 'root' au serveurs d’hébergement mutualisé d'OVH.
Ceci inclus toi - moi, etc.

SI les utilisateurs d'un hébergement Pro, Perso ou autre ONT l'accès root, tet bien, nos sites existerons plus pour demain.

Sache que tout le monde arrive bien à utiliser SON base des données SQL ... (lié à ton hébergement).

Seul solution: veuillez prendre un serveur dédié pour avoir un accès 'root' à toi.
C'est avec un dédié que ton boîte aura le droits de trafiquer le mysql et autre config.
Explique-leur que tu as loué un service hébergement mutualisé. Explique-les aussi que ovh.com possède des FAQ, manuels et autres guides en Anglais (va voir le site version anglais) ... ceci évitera qu'on t'envoie des question 'bizarre'.

D'ailleurs, ta question n'est pas lié au premier post de Tony. L'accès 'root' n'a jamais existé.

amourissime
09/01/2012, 17h17
Citation Envoyé par Nowwhat
Bonjour,

Un plan B:
Manager OVH => DNS => Zone DNS et ajoute un CNAME:
ssh.votre_domaine.tld qui pointer vers ssh.clusterNNN.ovh.net
Le NNN est visible dans votre Manager comme indiqué plus haut.
En suite, avec votre client SSH vous utilisez ssh.votre_domaine.tld
(au lieu de votre_domaine.tld comme avant).

@amourissime: Il suffit de lire le premier post ici http://forum.ovh.com/showthread.php?t=76263
Donne les ton ssh.clusterNNN.ovh.net (remplace le NNN pour le votre) et communique le mot de passe FTP. Ça marche.
merci pour l'info, mais ça ne suffit pas , voila leur réponse que j'ai traduit en français: Qu'en pensez vous?

Merci à vous
Jacky

Tout en essayant de mettre à jour votre site, nos techniciens a rencontré un problème qui pourrait être résolu que si nous avions les détails d'accès root sur votre serveur. Les détails que vous avez fourni les détails ne sont pas profondes - ce sont les détails de votre compte d'hébergement notamment.

Le problème nous avons été confrontés lorsqu'ils tentent de mettre à jour votre site est lié à MySQL paramètres de votre serveur qui ne nous permettrait pas de faire une sauvegarde. Voici l'erreur que nous avons reçus: erreur Got: 2002: Impossible de se connecter au serveur MySQL local à travers socket '/ var / run / mysqld / mysqld.sock' (2) lorsque vous essayez de vous connecter. Nous avons donc besoin de détails accès root pour corriger les paramètres MySQL et redémarrez le serveur.

Nowwhat
09/01/2012, 15h36
Citation Envoyé par Gaston_Phone
En quoi, l'accès en SSH est-il utile à une société tierce pour mettre à jour un logiciel.

Un bon script en PHP peut très bien faire le travail.
Oulà, Gaston_phone !!!
Je m'image pas que cette question est venu de toi.
L'accès SSH permet le fameuse SFTP

Ainsi que je mets mes hébergements à jour.
Avec le SSH, euh SFTP, euh, "FTP de luxe et sécurisé".

L'accès SSH permet aussi de metre son hébergement à jour.
Genre: on dépose le ZIP sur son hébergement, puis on SSH dessus pour exécuter un dézip sur place - parfait pour eux qui ont des soucis avec leur accès FTP - nous savons que ça existe ....

Gaston_Phone
09/01/2012, 14h40
Citation Envoyé par amourissime
j'ai un hébergement mutualisé, version pro, la société qui m'a fourni le script pour mon site, demande l'accès SSH pour mettre mon site à jour.
je leur ai transmit les codes d'accès FTP, leur réponse est la suivante: accès SSH impossible
En quoi, l'accès en SSH est-il utile à une société tierce pour mettre à jour un logiciel.

Un bon script en PHP peut très bien faire le travail.

tony
09/01/2012, 14h05
Tu as pas accès root en mutualisé (heureusement d'ailleurs ) vu que le serveur est partagé par plusieurs personnes.

Accès root c'est serveur dédié ou vps

Tony

amourissime
09/01/2012, 13h29
Citation Envoyé par Nowwhat
Bonjour,

Un plan B:
Manager OVH => DNS => Zone DNS et ajoute un CNAME:
ssh.votre_domaine.tld qui pointer vers ssh.clusterNNN.ovh.net
Le NNN est visible dans votre Manager comme indiqué plus haut.
En suite, avec votre client SSH vous utilisez ssh.votre_domaine.tld
(au lieu de votre_domaine.tld comme avant).

@amourissime: Il suffit de lire le premier post ici http://forum.ovh.com/showthread.php?t=76263
Donne les ton ssh.clusterNNN.ovh.net (remplace le NNN pour le votre) et communique le mot de passe FTP. Ça marche.
merci pour la réponse
en fait je n'ai pas été assez précis, il s'agit de l'accès root, es ce pareil?
merci
Jacky

Nowwhat
09/01/2012, 10h47
Bonjour,

Un plan B:
Manager OVH => DNS => Zone DNS et ajoute un CNAME:
ssh.votre_domaine.tld qui pointer vers ssh.clusterNNN.ovh.net
Le NNN est visible dans votre Manager comme indiqué plus haut.
En suite, avec votre client SSH vous utilisez ssh.votre_domaine.tld
(au lieu de votre_domaine.tld comme avant).

@amourissime: Il suffit de lire le premier post ici http://forum.ovh.com/showthread.php?t=76263
Donne les ton ssh.clusterNNN.ovh.net (remplace le NNN pour le votre) et communique le mot de passe FTP. Ça marche.

amourissime
09/01/2012, 10h18
Bonjour
j'ai un hébergement mutualisé, version pro, la société qui m'a fourni le script pour mon site, demande l'accès SSH pour mettre mon site à jour.
je leur ai transmit les codes d'accès FTP, leur réponse est la suivante: accès SSH impossible,
Les coordonnées FTP permettent elles l'accès ssh pour appliquer les modifications de script
Pouvez vous m'aider à résoudre ce problème?
merci infiniment pour vos réponses.

Gaston_Phone
09/01/2012, 09h34
Citation Envoyé par tony
Juste pour les hébergements qui ont un accès SSH
Tony
Cela est fort dommage.

Daniel60
09/01/2012, 07h58
On ne peut pas dire que ce soit "user frendly" !

tony
08/01/2012, 23h56
Juste pour les hébergements qui ont un accès SSH

Tony

Gaston_Phone
08/01/2012, 23h32
Citation Envoyé par tony
Post initial modifié
Bonsoir Tony, tu as oublié de préciser si cela concernait ou non les hébergements PERSO.

tony
08/01/2012, 22h58
Post initial modifié

totoffe54
08/01/2012, 22h25
Effectivement, la synthèse de l'hébergement donne le cluster (et pas seulement dans la ligne FTP). En fait, c'est là et pas dans "récapitulatif" qu'il fallait chercher.

J'ai de nouveau accès à mon ssh.

Merci de l'info !

Gaston_Phone
08/01/2012, 22h21
Citation Envoyé par totoffe54
Rien vu de tel dans la section en question (j'ai une offre pro).
Une piste --> OVH - Hébergement : Quel cluster .

totoffe54
08/01/2012, 22h16
Bonsoir,

Le numéro de votre cluster se trouve dans votre manager, section hébergement mutualisé, dans le récapitulatif.
Rien vu de tel dans la section en question (j'ai une offre pro).

Et comme effectivement le ssh sur mon nom de domaine ne semble plus fonctionner ce soir, j'ai plus d'accès ssh.

Cordialement,

Gaston_Phone
08/01/2012, 21h25
Et pour les hébergements PERSO ?

tony
08/01/2012, 21h03
Pour vos accès en SSH et SFTP, nous vous invitons à utiliser le nom de serveur suivant :

ssh.clusterNNN.ovh.net

et ne plus utiliser votre nom de domaine ou le nom de votre offre comme nom de serveur.

Le numéro de votre cluster se trouve dans votre manager, section hébergement mutualisé, dans le récapitulatif (cliquez sur Synthèse).

Tony