OVH Community, your new community space.

problème connexion putty


cocolabombe0
14/05/2015, 17h35
Sur l'ordinateur, je verifie pas toujours mes logiciels à jour. Mais sur mon serveur, je fais une mise à jour toutes les semaines au cas où il y en a.
Et sur online, c'est bien un debian 7 que j'ai et pas de soucis.

janus57
14/05/2015, 16h58
Bonjour,

Je n'ai pas installer la dernière version. Je suis actuellement en 0.62.
Heu déjà que PuTTY est pas mis à jour souvent mais si en plus vous utilisez une version obsolète et avec des failles de sécurité cela ne m'étonne pas trop...

These features are new in beta 0.64 (released 2015-02-28):

Security fix: PuTTY no longer retains the private half of users' keys in memory by mistake after authenticating with them. See private-key-not-wiped-2. (Sorry! We thought we'd fixed that in 0.63, but missed one.)
Support for SSH connection sharing, so that multiple instances of PuTTY to the same host can share a single SSH connection instead of all having to log in independently.
Command-line and configuration option to specify the expected host key(s).
Defaults change: PuTTY now defaults to SSH-2 only, instead of its previous default of SSH-2 preferred.
Local socket errors in port-forwarded connections are now recorded in the PuTTY Event Log.
Bug fix: repeat key exchanges in the middle of an SSH session now never cause an annoying interactive host key prompt.
Bug fix: reset the bolded-text default setting back to what it used to be. (0.63 set it to something wrong, as a side effect of refactoring.)
Bug fix: IPv6 literals are handled sensibly throughout the suite, if you enclose them in square brackets to prevent the colons being mistaken for a ort suffix.
Bug fix: IPv6 dynamic port forwardings should work again.

These features are new in beta 0.63 (released 2013-08-06):

Security fix: prevent a nefarious SSH server or network attacker from crashing PuTTY at startup in three different ways by presenting a maliciously constructed public key and signature. See vuln-modmul, vuln-signature-stringlen, vuln-bignum-division-by-zero.
Security fix: PuTTY no longer retains the private half of users' keys in memory by mistake after authenticating with them. See private-key-not-wiped. (Addendum: this turned out not to be wholly fixed, because private-key-not-wiped-2 was not found until 0.64.)
Revamped the internal configuration storage system to remove all fixed arbitrary limits on string lengths. In particular, there should now no longer be an unreasonably small limit on the number of port forwardings PuTTY can store.
Port-forwarded TCP connections which close one direction before the other should now be reliably supported, with EOF propagated independently in the two directions. This also fixes some instances of port-forwarding data corruption (if the corruption consisted of losing data from the very end of the connection) and some instances of PuTTY failing to close when the session is over (because it wrongly thought a forwarding channel was still active when it was not).
The terminal emulation now supports xterm's bracketed paste mode (allowing aware applications to tell the difference between typed and pasted text, so that e.g. editors need not apply inappropriate auto-indent).
You can now choose to display bold text by both brightening the foreground colour and changing the font, not just one or the other.
PuTTYgen will now never generate a 2047-bit key when asked for 2048 (or more generally n−1 bits when asked for n).
Some updates to default settings: PuTTYgen now generates 2048-bit keys by default (rather than 1024), and PuTTY defaults to UTF-8 encoding and 2000 lines of scrollback (rather than ISO 8859-1 and 200).
Unix: PSCP and PSFTP now preserve the Unix file permissions, on copies in both directions.
Unix: dead keys and compose-character sequences are now supported.
Unix: PuTTY and pterm now permit font fallback (where glyphs not present in your selected font are automatically filled in from other fonts on the system) even if you are using a server-side X11 font rather than a Pango client-side one.
Bug fixes too numerous to list, mostly resulting from running the code through Coverity Scan which spotted an assortment of memory and resource leaks, logic errors, and crashes in various circumstances.
Cf : http://www.chiark.greenend.org.uk/~s...y/changes.html

Site officiel de PuTTY, et cela ressemble fort à du Debian 8 si cela a toujours marché sur du Debian 7 (ou alors vous étiez en Debian 6 avant), car OpenSSH a commencé à faire le ménage dans les hmac/ciphers à cause de la NSA.

Dans tout les cas on garde sont serveur à jours tous comme les logiciels sur son propre PC, cela évite de tourner en rond si le problème viens d'un software qui est pas à jour.

Cordialement, janus57

cocolabombe0
14/05/2015, 16h37
Je n'ai pas installer la dernière version. Je suis actuellement en 0.62.
Je viens d'installer la nouvelle version et cela fonctionne bien.
Et c'est debian 7

janus57
14/05/2015, 16h30
Bonjour,

May 14 15:14:52 ns332796 sshd[19676]: fatal: no matching mac found: client hmac-sha1,hmac-sha1-96,hmac-md5 server hmac-sha2-512,hmac-sha2-256,hmac-ripemd160 [preauth]
cela ressemble a un client qui utilise de nouveaux/viex protocol de sécurité qui sont refusé /non pris en charge voir inconnu.

Ton putty est en quel version ? téléchargé où ?
Tu forcerait pas dans ton putty un vieux protocol SSH ?

Car bon que ça marche avec KiTTY et non PuTTY qui ont le même code source de base c'est totalement illogique et fait penser que tu as forcés certains paramètres sur ton PuTTY qui ne sont pas repris par KiTTY.

D'ailleurs c'est un Debian 7 (Wheezy) ou Debian 8 (jessie) ?

EDIT :
Changes since OpenSSH 6.6
=========================

Potentially-incompatible changes

* sshd(8): The default set of ciphers and MACs has been altered to
remove unsafe algorithms. In particular, CBC ciphers and arcfour*
are disabled by default.

The full set of algorithms remains available if configured
explicitly via the Ciphers and MACs sshd_config options.

* sshd(8): Support for tcpwrappers/libwrap has been removed.

* OpenSSH 6.5 and 6.6 have a bug that causes ~0.2% of connections
using the curve25519-sha256@libssh.org KEX exchange method to fail
when connecting with something that implements the specification
correctly. OpenSSH 6.7 disables this KEX method when speaking to
one of the affected versions.
Cf : http://www.openssh.com/txt/release-6.7

Ciphers
Specifies the ciphers allowed for protocol version 2. Multiple ciphers must be comma-separated. The supported ciphers are:

3des-cbc
aes128-cbc
aes192-cbc
aes256-cbc
aes128-ctr
aes192-ctr
aes256-ctr
aes128-gcm@openssh.com
aes256-gcm@openssh.com
arcfour
arcfour128
arcfour256
blowfish-cbc
cast128-cbc
chacha20-poly1305@openssh.com

The default is:

aes128-ctr,aes192-ctr,aes256-ctr,
aes128-gcm@openssh.com,aes256-gcm@openssh.com,
chacha20-poly1305@openssh.com

The list of available ciphers may also be obtained using the -Q option of ssh(1).
Cf : man sshd_config

Cordialement, janus57

cocolabombe0
14/05/2015, 16h18
J'essayerai quand j'irai chez ma soeur. J'utiliserai Kitty en attendant.

nowwhat
14/05/2015, 15h51
Citation Envoyé par cocolabombe0
J'ai pensé à Kaspersky donc j'ai essayé de le fermer et cela ne fonctionnait pas.
Faut pas 'essayer' avec Kaspersky - il est plus costaux que ça.
Pour être sur que c'est lui, faut le virer. Puis redémarrer le PC - et encore, il est plus que conseillé 'leur' outils de nettoyage, tellement que c'est coriace.

PS : antivirus : plus besoin en fait puis le parafeu de "Microsoft" de base fait largement l'affaire, sachant qu'on en plus tous derrière un box qui fait du NAT. Dès qu'on arrête d'installer n'importe quoi (genre "Office Gratuit" + keygen)

Citation Envoyé par cocolabombe0
Je vais essayé la méthode avec putty et regedit. Mais bon, sur deux pc différents, ca m'étonne que cela soit sur ce logiciel.
Moui aussi.
Autre test: prend PC, et connecte le PC chez un copain (= autre FAI)

cocolabombe0
14/05/2015, 15h17
J'ai rouvert une commande vu que je suis entrain de copier des fichiers sur le serveur.
Je ne peux toujours pas aller avec putty.
tail -f /var/log/auth.log
May 14 15:12:01 ns332796 CRON[19484]: pam_unix(cron:session): session opened for user root by (uid=0)
May 14 15:12:04 ns332796 CRON[19484]: pam_unix(cron:session): session closed for user root
May 14 15:12:40 ns332796 sshd[19531]: Accepted password for root from xx.xxx.ip.xxx port 51067 ssh2
May 14 15:13:01 ns332796 CRON[19542]: pam_unix(cron:session): session opened for user root by (uid=0)
May 14 15:13:01 ns332796 CRON[19542]: pam_unix(cron:session): session closed for user root
May 14 15:14:01 ns332796 CRON[19593]: pam_unix(cron:session): session opened for user root by (uid=0)
May 14 15:14:01 ns332796 CRON[19593]: pam_unix(cron:session): session closed for user root
May 14 15:14:16 ns332796 sshd[4288]: Received signal 15; terminating.
May 14 15:14:16 ns332796 sshd[19653]: Server listening on 0.0.0.0 port 22.
May 14 15:14:16 ns332796 sshd[19653]: Server listening on :: port 22.
May 14 15:14:52 ns332796 sshd[19676]: fatal: no matching mac found: client hmac-sha1,hmac-sha1-96,hmac-md5 server hmac-sha2-512,hmac-sha2-256,hmac-ripemd160 [preauth]
May 14 15:15:01 ns332796 CRON[19680]: pam_unix(cron:session): session opened for user root by (uid=0)
May 14 15:15:01 ns332796 CRON[19682]: pam_unix(cron:session): session opened for user munin by (uid=0)
May 14 15:15:01 ns332796 CRON[19681]: pam_unix(cron:session): session opened for user root by (uid=0)
May 14 15:15:01 ns332796 CRON[19681]: pam_unix(cron:session): session closed for user root
May 14 15:15:02 ns332796 CRON[19680]: pam_unix(cron:session): session closed for user root
May 14 15:15:43 ns332796 CRON[19682]: pam_unix(cron:session): session closed for user munin
Les pam_unix augmente tous les minutes.

May 14 15:14:16 ns332796 sshd[4288]: Received signal 15; terminating.
May 14 15:14:16 ns332796 sshd[19653]: Server listening on 0.0.0.0 port 22.
May 14 15:14:16 ns332796 sshd[19653]: Server listening on :: port 22.
May 14 15:14:52 ns332796 sshd[19676]: fatal: no matching mac found: client hmac-sha1,hmac-sha1-96,hmac-md5 server hmac-sha2-512,hmac-sha2-256,hmac-ripemd160 [preauth]
A chaque fois que je lance la connexion par putty.

Avec Kitty, j'arrive à me connecter:
May 14 15:39:28 ns332796 sshd[25201]: Accepted password for root from xx.xxx.ip.xxx port 51656 ssh2
Est ce que le cron est affiché car je copie des fichiers depuis un autre serveur (commande scp).

nowwhat
14/05/2015, 14h55
Citation Envoyé par BBR
.....
il ne peut pas te filer le moindre log puisqu'il n'arrive pas à se connecter en ssh !
J'ai du mal comprendre ceci:
Citation Envoyé par cocolabombe0
Je viens d'installer Gygwin ainsi que openSSH et j'arrive à me connecter. Je ne vois pas trop ce qu'il cloche sur mon putty et sur deux ordinateurs différents
.

cocolabombe0
14/05/2015, 12h31
J'ai pensé à Kaspersky donc j'ai essayé de le fermer et cela ne fonctionnait pas.
Je vais essayé la méthode avec putty et regedit. Mais bon, sur deux pc différents, ca m'étonne que cela soit sur ce logiciel.

BBR
14/05/2015, 10h57
je viens de faire un traceroute vers son ip, aucun souci, pas de vac

janus57
14/05/2015, 10h35
Bonjour,

au passage son serveur est pas derrière le VAC ? peut être qu'un élément de son réseau fait du "zèle" (une box avec un firewall un peu trop sensible, un firewall "intelligent" sur le PC qui refuse les connexions sécurisé avec des problèmes d'identifications (kaskersky est capable de le faire pour le HTTPS) etc...).

Et je confirme que la dernière fois que j'ai testé une installe avec clé inclus dans l’installe 0 password dans le mail juste : votre serveur est prêt.

Cordialement, janus57

BBR
14/05/2015, 09h27
Je démontre que une installation initiale d'un OS par KS(OVH) n('est pas prêt à ce faire avec un clé.
L'authentification reste comme avant : root+mot de passe.
bah si, quand je fais une install par clé, je reçois juste un mail me disant que le serveur est installé, aucun mot de pass root, si je fais sans clé, je reçois le mail d'installation avec utilisateur : root, mot de pass : xxxxxxx
Son problème ne vient pas du serveur, il m'a envoyé l'ip et j'accède bien à la demande de login, alors que lui se fait jeter direct
il ne peut pas te filer le moindre log puisqu'il n'arrive pas à se connecter en ssh !

nowwhat
14/05/2015, 09h22
Citation Envoyé par BBR
nowwhat, je n'ai rien compris à ta réponse,...
*
Je démontre que une installation initiale d'un OS par KS(OVH) n('est pas prêt à ce faire avec un clé.
L'authentification reste comme avant : root+mot de passe.

@cocolabombe0 : t'as accès avec UN PC - et pas l'autre.
La solution et le pourquoi n'est donc pas loin.
Il te faut 5 minutes.

Connecte toi avec le PC qui marche.
Change, ou ajoute dans le fichier
/etc/ssh/sshd_config
ceci:
LogLevel DEBUG
puis sauvegarde.
Redémarre ssh comme ça:
service ssh restart
puis
tail -f /var/log/auth.log

garde cette session ouverte.

Maintenant, sur le PC ou ça ne marche pas, tente un login.

File nous le log de ssh.

Un plan B: Enlève Putty de ton PC.
PUIS: avec l'aide de regedit, vite toutes les entrées lié à Putty.
Ca fera l'affaire aussi.

janus57
14/05/2015, 07h39
Bonjour,

peut être la source de ton PuTTY ?

Sinon une petit alternative à PuTTY ==> KiTTY : http://www.9bis.net/kitty/?zone=fr
Il a certaines options sympa en plus de PuTTY (c'est un fork "amélioré" de PuTTY).

Cordialement, janus57

cocolabombe0
14/05/2015, 02h20
Bon, BBR arrive à ce connecter avec putty, moi pas.
Je viens d'installer Gygwin ainsi que openSSH et j'arrive à me connecter. Je ne vois pas trop ce qu'il cloche sur mon putty et sur deux ordinateurs différents.

cocolabombe0
13/05/2015, 23h50
J'essais une dernière fois une réinstallation normale (avec mot de passe) mais cette fois-ci avec debian 7.5.

BBR
13/05/2015, 23h44
nowwhat, je n'ai rien compris à ta réponse, il n'a pas choisi l'installation avec clé manager donc il a reçu un mot de passe root, j'ai fait une install de debian 8 de la même façon et le mot de pass reçu fonctionne
cocolabombe0 tu devrais relancer l'installation, il y a du avoir un problème

cocolabombe0
13/05/2015, 22h46
J'ai fais une installation classique.
Je vais essayé en mettant la clé ssh avec une réinstallation.

Je l'ai généré avec PuttyGen, copier sur mon bureau et mis dans putty à Auth.
Il reste plus qu'à mettre mon ip dans putty et je pourrais me connecter après?

J'ai fini de réinstaller au toujours pas de connexion avec putty.

C'est dès que je met l'ip du serveur (que je prend dans mon manager kimsufi (IP principale) que je mets dans putty et le port 22 que j'arrive pas à me connecté. Donc je n'étais pas encore à l'étape où je devais mettre mon mot de passe.

C'est normal ça? (Boot from hard drive (no netboot))

nowwhat
13/05/2015, 22h21
Citation Envoyé par BBR
je viens d'essayer, install de Jessie sans clé manager, le pass fourni par ovh fonctionne parfaitement
Normal.
La version 'OVH' de l'install SSHD de Debian 8 n'a pas activé cette version.
Je demande à voir: voici le nouveau mail de KS quand on loue un serveur:
Voici votre clé privé pour accéder à votre serveur:
-----BEGIN DSA PRIVATE KEY-----
Proc-Type: 4,ENCRYPTED
DEK-Info: AES-256-CBC,815A2CD9BA2DD5998BDC235ABE76E305

s+8fbQITAhNsrtj0vALjypbJXxPk2aIsCj2H+veCVycF1YZzYa VJagHexydGc1S+
fR8l6+UxxjkOIY7fjSUPGJUvOBZhjYUfYz1GZCB+zYxxYc8zII nwkvBb3TzQc06v
PyMqj0C48hVhhsha9hwYYmOvF96B5wMLDya2ZTrEiPxsqYbxkm kK7sE5zdsBaopi
sQa9mqlih0nYgpefeJJyxCAJiyW4UskXYbPB5nQI1yEPlP3zQD LTJJ32yVXx75Pp
VYW6ws3RQivSGHK2qc9PlkQO0sPeeMguAGxpPs5BAHmZOq4YC4 zj5sCIWD2BRuOn
xUSbNA85usoUDSpKulXa1pCgAMyIZ2s+wGcM2w0iWZ9BwdaRXb fdl4oMOeethJUU
/1yIjY2IsorVdTyuuZ799PqiUasxQUbn2rhNPkBALSJst2ooB0p tt3WV0kdFFRi5
I4uZlD1zUT4zxkuoLdn34LqhSPa0gK6NmG4nDDqo1AnQmAWEhq AQXxC3oYEf8J1a
DcehZ6ydcWTL0cQ9HH5q5bxF++v0lNVDsenDRQbWPtLcDTbRFV INKX0gUxWfUkUv
+6hqdbk3/izm9YU+f01h+g==
-----END DSA PRIVATE KEY-----
Le mot de passe pour utiliser ce clé privé : sqhsfkhsfhskqfh

Bon courage.

Cordialement,
Le service commerciale de KS.
Ça va donner quoi, à votre avis ?

BBR
13/05/2015, 20h54
je viens d'essayer, install de Jessie sans clé manager, le pass fourni par ovh fonctionne parfaitement

nicobilaine
13/05/2015, 20h23
Le compte que vous avez reçu d'OVH est le root? Il me semble que par défaut il est désactivé sur Debian 8, est-ce que ça ne serait pas le problème? Peut-être qu'OVH n'en a pas tenu compte et fourni une installation avec root désactivé.
Le plus simple pour vous est de mettre une clé SSH et de réinstaller le serveur avec cette clé.

BBR
13/05/2015, 18h44
à l'installation tu as demandé une clé ssh ou tu as installé de façon standard ?
t'es sûr de bien mettre l'ip, root et le bon pass ?
si c'est juste Debian, tu n'as pas de http, faut tout installer toi-même

cocolabombe0
13/05/2015, 18h40
Bonjour, je viens d'avoir un serveur aujourd'hui. Je l'ai pris le 8 mai et donc valider aujourd'hui.
J'ai fais une installation de Debian 8 et je n'arrive pas à me connecter sur mon serveur.
Quand je rentre l'adresse ip sur putty, j'ai ce message:
Server unexpectedly closed network connection
Quand je sais de charger en http mon ip, j'ai
Page Web inaccessible

ERR_CONNECTION_REFUSED
J'espère que vous pourrez m'aider.
Cordialement Nicolas.