OVH Community, your new community space.

Clés SSH non reconnues


BBR
09/12/2015, 10h32
pas besoin de règle si c'est uniquement en local, par exemple mysql est en local sur le port 3306 et on ne l'ouvre pas et personne ne peut s'y connecter de l'extérieur, à moins que Redis ait un truc particulier

regarde les ports ouverts/en écoute sur ton serveur
Code:
netstat -tanpu
pour que tes 2 serveurs aient été hackés en même temps c'est qu'ils devaient communiquer entre eux, non ?

keytest
08/12/2015, 23h33
Merci pour ces remarques constructives qui me permettent d'apprendre et d'avancer.

1 - J'ai créé un user "redis" dédié qui a uniquement les droits sur le répertoire visé.
2 - J'ai vérifié les règles Iptables suivantes, pour accepter uniquement les connexions en local, elles sont bonnes puisque ma connexion est bien bloqué depuis mon pc. N'hésitez pas à taper dessus si je me trompe
iptables -A INPUT -p tcp --dport 6379 -s 127.0.0.1 -j ACCEPT
iptables -A INPUT -p tcp --dport 6379 -j DROP

3 - Il me reste à faire l'équivalent en ipv6, puisqu'apparement les règles ipv4 n'ont pas suffit
4 - "Binder" Redis sur 127.0.0.1 via le fichier de conf
5 - Ajouter une auth sur Redis via le fichier de conf

Merci encore

janus57
06/12/2015, 23h13
Bonjour,

les deux serveurs ont "buggé"au même moment, ça écarte un probable problème de hardware , non ?
sur des KS, cela peut être possible (mais 10% de chance quoi).

je n'ai jamais touché à la config SSH, j'en découvre le fonctionnement du coup...
ça c'est pas le top par contre.

Redis tourne en root sur la machine
Heu je suis le seul à prendre peur qu'un service (non sécurisé car accès public) tourne en root ????
Sinon il fallait peut être suivre les conseil de redis : http://redis.io/topics/security
Sinon pour iptables voici pour l’inspiration : http://blog.redsmin.com/post/1174338...ess-redis-with

Quid de l'IPv6 sur redis?
Car c'est gentil de configurer iptables en IPv4 pour bloquer les connexions à redis, mais si le hacker utilise IPv6 sur ton redis c’est "open bar" pour lui =)

Cordialement, janus57

BBR
06/12/2015, 22h39
avais-tu configuré ton ssh ?
ce fichier : /etc/ssh/sshd_config
en mettant ceci :
#PermitRootLogin Yes
PermitRootLogin without-password
PasswordAuthentication no

puis relancer le service
service ssh restart

à faire bien sûr en ayant testé avant ton accès par clé

et il y a quoi dans ton iptables ?

edit : je ne connais pas redis, ça t'est indispensable ?
et surtout ton serveur était à jour ?

keytest
06/12/2015, 21h37
Redis tourne en root sur la machine. De ce que je comprend, quelqu'un a réussi à écrire via Redis sur /root/.ssh/authorized_keys2.
Pourtant Redis étant censé être inaccessible depuis l'extérieur via les règles décrites plus haut :-(, c'est là ou quelque chose m'échappe.

Je n'ai rien touché à la config par défaut de la distrib OVH concernant l'authentification SSH. Dans le auth.log je n'ai pas trouvé de connexions autre qu'avec mon IP donc il me semble vraiment que le problème vient de la sécurisation de Redis.

J'attends l'action d'OVH pour pouvoir rebooter en rescue-pro sauvegarder mes data, et réinstaller...
Et réétudier le bug iptables sur Redis.....

Je suis d'ailleurs prenneur d'avis sur celles-ci, vu qu'elles vous paraissent bizarre

BBR
06/12/2015, 21h09
alors tes serveurs ont été hackés et en root, donc la seule chose à faire : réinstaller
tu avais empêché la connexion par root et pass ? parce que cela reste actif si tu ne le spécifies pas, mettre une clé n'empêche pas de se connecter par mot de passe, il y a des choses à configurer

BBR
06/12/2015, 21h05
sur ton serveur ?
bizarre ton iptables

keytest
06/12/2015, 20h29
Pour info voilà ce que je viens de trouver
http://kevinchen.co/blog/postmortem-server-compromised/

Pourtant mes règles Iptables étaient à priori OK :
# REDIS SECURITY
iptables -A INPUT -p tcp --dport 6379 -s 127.0.0.1 -j ACCEPT
#NODE1
iptables -A INPUT -p tcp --dport 6379 -s 91.121.XXX.XXX -j ACCEPT
#NODE2
iptables -A INPUT -p tcp --dport 6379 -s 91.121.XXX.XXX -j ACCEPT
iptables -A INPUT -p tcp --dport 6379 -j DROP

Ai-je oublié quelque chose ?

keytest
06/12/2015, 20h09
Voilà comment commence mon fichier /root/.ssh/authorized_keys2 , il a été modifié vers 1h30 cette nuit, heure à laquelle je dormais comme une marmotte ^^

REDIS0006þ crackitA‚


ssh-rsa AAAAB3NzaC1yc2EAAAADAQABA
J'utilise Redis, mais je ne vois pas le rapport

BBR
06/12/2015, 19h57
cela va plutôt dans le sens d'un problème en local sur ton pc

keytest
06/12/2015, 19h50
Merci à tous les deux. Je regarde et vous tient au courant. A noter que :
- les deux serveurs ont "buggé"au même moment, ça écarte un probable problème de hardware , non ?
- je n'ai jamais touché à la config SSH, j'en découvre le fonctionnement du coup...

BBR
06/12/2015, 19h47
elle ressemble à quoi cette 1ere ligne ?
remplace-là avec ton original de clé

nowwhat
06/12/2015, 19h27
Tentative de lire : /root/.ssh/authorized_keys2
Dec 6 19:15:28 node2 sshd[6601]: debug1: trying public key file /root/.ssh/authorized_keys2
== Ok.

Mais ....
Dec 6 19:15:28 node2 sshd[6601]: debug1: read_keyfile_line: /root/.ssh/authorized_keys2 line 1 exceeds size limit
Quelque chose a changé avec authorized_keys2 car avant qu'il annonce "line 1 exceeds size limit" il faut vraiment que ce "line 1" soit très longue ......

PS :
IL te manque un
UsePAM no
dans ton sshd_config (je présume que tu utilise plus du tout le système PAM)

PS Janus a posté au même moment avec le la même conclusion
Citation Envoyé par janus57
....
Là le mode rescue semble obligatoire pour vérifier les clé et surtout les composants (comme le disque).
SI t'as toujours une session ouverte, garde le ouvert !!
Répare le problème (et découvre qui l'a changé, si ce n'est pas toi !!) , redémarre ssh et test-le !

janus57
06/12/2015, 19h27
Bonjour,

la clé SSH a été généré avec quoi ? comment ?

Visiblement votre clé sur le serveur à un problème :
Dec 6 19:15:28 node2 sshd[6601]: debug1: read_keyfile_line: /root/.ssh/authorized_keys2 line 1 exceeds size limit
De ce que je comprend je n'ai pas de fichier authorized_keys, est-ce normal ?
on s'en fou SSH va essayer de lire authorized_keys et authorized_keys2 qui sont historiquement pour le SSHv1 et SSHv2, de nos jours il existe juste SSHv2 si on utilise des OS à jour.

Là le mode rescue semble obligatoire pour vérifier les clé et surtout les composants (comme le disque).

Cordialement, janus57

keytest
06/12/2015, 19h17
Voilà le résultat (merci!). De ce que je comprend je n'ai pas de fichier authorized_keys, est-ce normal ? En plus de ça le authorized_keys2 n'aurait pas le bon format... . Je suis un peu perdu dans le sens où je n'ai jamais touché à une quelconque config ssh . Comment ces fichiers auraient pu être modifiés ?

Dec 6 19:15:15 node2 CRON[5914]: pam_unix(cron:session): session closed for user munin
Dec 6 19:15:26 node2 sshd[5848]: debug1: Forked child 6601.
Dec 6 19:15:26 node2 sshd[6601]: Set /proc/self/oom_score_adj to 0
Dec 6 19:15:26 node2 sshd[6601]: debug1: rexec start in 5 out 5 newsock 5 pipe 7 sock 8
Dec 6 19:15:26 node2 sshd[6601]: debug1: inetd sockets after dupping: 3, 3
Dec 6 19:15:26 node2 sshd[6601]: Connection from 109.12.206.210 port 54419
Dec 6 19:15:26 node2 sshd[6601]: debug1: Client protocol version 2.0; client software version WinSCP_release_5.7.5
Dec 6 19:15:26 node2 sshd[6601]: debug1: no match: WinSCP_release_5.7.5
Dec 6 19:15:26 node2 sshd[6601]: debug1: Enabling compatibility mode for protocol 2.0
Dec 6 19:15:26 node2 sshd[6601]: debug1: Local version string SSH-2.0-OpenSSH_6.0p1 Debian-4+deb7u2
Dec 6 19:15:26 node2 sshd[6601]: debug1: permanently_set_uid: 102/65534 [preauth]
Dec 6 19:15:26 node2 sshd[6601]: debug1: list_hostkey_types: ssh-rsa [preauth]
Dec 6 19:15:26 node2 sshd[6601]: debug1: SSH2_MSG_KEXINIT sent [preauth]
Dec 6 19:15:26 node2 sshd[6601]: debug1: SSH2_MSG_KEXINIT received [preauth]
Dec 6 19:15:26 node2 sshd[6601]: debug1: kex: client->server aes256-ctr hmac-sha2-256 none [preauth]
Dec 6 19:15:26 node2 sshd[6601]: debug1: kex: server->client aes256-ctr hmac-sha2-256 none [preauth]
Dec 6 19:15:26 node2 sshd[6601]: debug1: SSH2_MSG_KEX_DH_GEX_REQUEST received [preauth]
Dec 6 19:15:26 node2 sshd[6601]: debug1: SSH2_MSG_KEX_DH_GEX_GROUP sent [preauth]
Dec 6 19:15:26 node2 sshd[6601]: debug1: expecting SSH2_MSG_KEX_DH_GEX_INIT [preauth]
Dec 6 19:15:27 node2 sshd[6601]: debug1: SSH2_MSG_KEX_DH_GEX_REPLY sent [preauth]
Dec 6 19:15:27 node2 sshd[6601]: debug1: SSH2_MSG_NEWKEYS sent [preauth]
Dec 6 19:15:27 node2 sshd[6601]: debug1: expecting SSH2_MSG_NEWKEYS [preauth]
Dec 6 19:15:28 node2 sshd[6601]: debug1: SSH2_MSG_NEWKEYS received [preauth]
Dec 6 19:15:28 node2 sshd[6601]: debug1: KEX done [preauth]
Dec 6 19:15:28 node2 sshd[6601]: debug1: userauth-request for user root service ssh-connection method none [preauth]
Dec 6 19:15:28 node2 sshd[6601]: debug1: attempt 0 failures 0 [preauth]
Dec 6 19:15:28 node2 sshd[6601]: debug1: PAM: initializing for "root"
Dec 6 19:15:28 node2 sshd[6601]: debug1: PAM: setting PAM_RHOST to "210.206.12.109.rev.sfr.net"
Dec 6 19:15:28 node2 sshd[6601]: debug1: PAM: setting PAM_TTY to "ssh"
Dec 6 19:15:28 node2 sshd[6601]: debug1: userauth-request for user root service ssh-connection method publickey [preauth]
Dec 6 19:15:28 node2 sshd[6601]: debug1: attempt 1 failures 0 [preauth]
Dec 6 19:15:28 node2 sshd[6601]: debug1: test whether pkalg/pkblob are acceptable [preauth]
Dec 6 19:15:28 node2 sshd[6601]: debug1: Checking blacklist file /usr/share/ssh/blacklist.RSA-2048
Dec 6 19:15:28 node2 sshd[6601]: debug1: Checking blacklist file /etc/ssh/blacklist.RSA-2048
Dec 6 19:15:28 node2 sshd[6601]: debug1: temporarily_use_uid: 0/0 (e=0/0)
Dec 6 19:15:28 node2 sshd[6601]: debug1: trying public key file /root/.ssh/authorized_keys
Dec 6 19:15:28 node2 sshd[6601]: debug1: Could not open authorized keys '/root/.ssh/authorized_keys': No such file or directory
Dec 6 19:15:28 node2 sshd[6601]: debug1: restore_uid: 0/0
Dec 6 19:15:28 node2 sshd[6601]: debug1: temporarily_use_uid: 0/0 (e=0/0)
Dec 6 19:15:28 node2 sshd[6601]: debug1: trying public key file /root/.ssh/authorized_keys2
Dec 6 19:15:28 node2 sshd[6601]: debug1: fd 4 clearing O_NONBLOCK
Dec 6 19:15:28 node2 sshd[6601]: debug1: read_keyfile_line: /root/.ssh/authorized_keys2 line 1 exceeds size limit
Dec 6 19:15:28 node2 sshd[6601]: debug1: restore_uid: 0/0
Dec 6 19:15:28 node2 sshd[6601]: Failed publickey for root from 109.12.206.210 port 54419 ssh2

nowwhat
06/12/2015, 19h09
Citation Envoyé par keytest
....
J'ai encore un putty d'ouvert avec une session précédente (et donc valide) sur un des serveurs. Je vois un fichier authorized_keys2 dans /root/.ssh/ , est-ce que celui-ci est censé contenir la clé publique correspondant à mon .ppk ?
Oui. (mais va voir dans /etc/ssh/sshd_config pour être sur).

Sur le serveur sur laquelle que t'as encore un sessions SSH ouvert, change dans /etc/ssh/sshd_config :
LogLevel INFO
pour
LogLevel DEBUG
et redémarre ssh.

Fait un essaie avec Putty (nouvelle session) et surveille le
tail -f /var/log/aith.log
dans l'autre.

keytest
06/12/2015, 18h47
Merci à tous les deux d'avoir pris le temps de lire et de me répondre.

Suite à vos conseils :
- j'ai updaté WinSCP + putty => RAS
- les serveurs sont bien sûr payés, les prélèvements sont faits automatiquement
- clés vérifiées, je n'en ai qu'une pour mes serveurs, une seule déclarée dans l'admin et donc un seul fichier ppk de mon côté
- mode rescue, je vais chercher de ce côté mais sur l 'un des deux serveurs l'option est bloquée dans l'admin... et c'est bien sûr celui ou j'ai mes fichiers les plus récents / importants

J'ai encore un putty d'ouvert avec une session précédente (et donc valide) sur un des serveurs. Je vois un fichier authorized_keys2 dans /root/.ssh/ , est-ce que celui-ci est censé contenir la clé publique correspondant à mon .ppk ?

Pourtant tout tourne normalement sur les serveurs... apache... etc.

janus57
06/12/2015, 18h03
Bonjour,

aussi bien vérifier que putty (ou autre client SSH) utilise bien la bonne clé sur le bon serveur (si clés différentes).

Cordialement, janus57

BBR
06/12/2015, 17h42
que faire : relancer le serveur en mode rescue pour aller voir ce qui se passe
vérifier aussi que tu as bien la dernière version de Putty
vérifier aussi que tes serveurs ont bien été payés

keytest
06/12/2015, 15h21
Bonjour,

Depuis quelques minutes mes clés SSH ne sont plus reconnus par mes 2 Kimsufi, impossible de se connecter ni sur l'un ni surl 'autre : clé refusé par le serveur. Je n'ai pas de mot de passe root puisque j'ai choisi ma clé à l'install.
Pourtant rien n'a changé sur le serveur, c'est quelque peu étrange

Quelqu'un observe t-il le même comportement ?
Que faire dans cette situation ?

Merci d'avance