Clés SSH

Crone123 · Le 28/06/2013, à 22:42

Bonjour,
J'ai suivis la doc, et j'aimerais en plus de l'authentification par mot de passe, avoir la possibilité de se connecter par clé publique/privée.
Donc, j'ai généré une clé, et j'ai envoyée la partie privée au client. J'ai bien autorisé la clé sur le serveur.

A la connexion, il me demande la passphase pour la clé, je l'entre, aucun soucis.
Puis, il me demande le mot de passe pour le compte...
Donc la clé n'as aucun intérêt.

Je voulais en fait utiliser la clé pour un montage automatique du SSHFS, donc on entre une fois le mot de passe de la clé, et un système le conserve tout le temps que l'on en a besoin, sans avoir besoin d'entrer le mot de passe du compte derrière....l'idée est d'entrer moins de mots de passes avec un montage automatique sur les ordis locaux. ( a 2m du serveur)
Le montage automatique se fait sur un serveur local, donc a la limite j'aurais même pu mettre sans passphase.

Que dois-je régler pour ne pas avoir a entrer de mot de passe sur le compte si j'utilise une clé publique/privée?
Comment faire pour que le client retienne le mot de passe le temps d'une session?
Peut t-on configurer coté serveur: "N'autoriser telle clé que si le client est telle IP.."?
Merci

EDIT: Pour ne pas avoir a entrer le mot de passe, j'ai trouvé: Mettre UsePAM a no, et mettre le chmod de authorized_keys a 600
Maintenant pour le reste je ne sais pas....
Merci

Dernière modification par Crone123 (Le 28/06/2013, à 23:10)

nesthib · Le 29/06/2013, à 00:10

Ça n'est pas normal. Est-tu sûr d'avoir importé correctement la clé ? On dirait, ici, que ton authentification par clé échoue et que tu te retrouves à devoir mettre le mot de passe par défaut.

Essaie de faire :

ssh-copy-id crone123@serveur

puis recommence l'authentification. Tu devrais pouvoir te connecter sans mot de passe.

Si le problème persiste, donne le retour de :

ssh -vvv crone123@serveur

Pour tout ce qui est configuration côté serveur, regarde dans /etc/ssh/sshd_config
Petit conseil, garde une connexion ssh d'ouverte quand tu fais des changement afin de ne pas te retrouver à la porte de ton serveur. De plus, je ne crois pas qu'un filtrage par IP soit la meilleure idée. Si tu as peur des attaques utilise fail2ban.

Crone123 · Le 29/06/2013, à 00:27

J'ai fais mes tests en attendant, j'ai maintenant un SSHFS fonctionnel avec clé sans passphase.

J'ai regardé auth.log c'était juste le fichier .ssh/authorized_keys qui n'avais pas son chmod a 600
Du coup, vu que y a plus de mdp pas besoin de les retenir.
Le filtrage par ip c'était pour le cas où une clé se perde, enfin, si une clé se perd vu que j'y prête une certaine attention, j'aurais vite fait de supprimer toutes les clés du serveur et en générer des nouvelles.

Pour le coup du SSH a laisser ouvert je me suis déjà fait avoir oui, j'y ai pensé merci (moi c'était plus violent, c'était carrément du a un DROP de iptables XD )
Heureusement que mon serveur est juste a coté, donc si j'ai un problème du genre je peux brancher un écran, une souris et un clavier et corriger le problème.

Fail2ban je connais, je reçois d'ailleurs 25mails par jours XD
En parlant de Fail2ban, admettons qu'il bannisse 11 personnes, comment se fait-il que je puisse avoir 500erreurs de login alors qu'il doit bannir au bout de 6erreurs?
ça peut être du a un problème de iptables qui autoriserait une connexion déjà active venant de l'extérieur (quoi qu'il ne m'as jamais fait de merde donc..) ? Ou c'est normal?
J'ai déjà vérifié, le temps de ban de mon serveur est réglé sur 31jours.

Du coup, la connexion est fonctionnelle, un dernier détail: Quand j'ouvre le SSHFS, ou le NFS (que j'utilisais avant), nautilus me spamme de messages disant qu'il y a un problème alors que le truc fonctionne parfaitement...
Exemple:

Impossible de monter Partage

DBus error org.freedesktop.DBus.Error.NoReply: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.

Enfin, ces derniers temps nautilus est hyper buggué, entre ça et les onglets qui sélectionnent dans le mauvais et font a peu près tout sauf ce qu'il faut.... (et on ne prends pas mon bug au sérieux, mais il suffit d'utiliser nautilus 15min pour l'avoir..., je l'ai depuis que je suis sur la 12.04, et il n'est pas corrigé sur la 13.04 non plus....)
Sérieusement, les onglets: Vous avez un onglet A, vous ouvrez un onglet B, et un onglet C, vous allez sur l'onglet B, 50% de chance qu'une sélection de fichier soit affichée dans l'onglet B mais sélectionne réellement des fichiers de l'onglet A, résultat: Les copies, déplacement, ouvertures et suppression touchent les fichiers de l'onglet A.
Fermer l'onglet A et refaire la sélection depuis l'onglet B fait crasher le logiciel.
Si vous aviez pu faire une copie des fichiers vers l'onglet C, c'est aussi probable que les fichiers soient copiés vers l'onglet A ou B, mais pas dans le C, ça arrive a partir du moment ou l'on utilise des onglets, et a peu près n'importe quand. Des fois vous l'utilisez 30min pas de problèmes, et des fois en 5min tout bug.
Bref...et pas de solution pour l'instant....

EDIT: Il me sort aussi:

Impossible de monter Partage

Timeout waiting for mount to appear

Dernière modification par Crone123 (Le 29/06/2013, à 00:33)

nesthib · Le 29/06/2013, à 03:35

Un temps de ban de 31 jours me semble inutile. une dizaine de minutes devrait suffire.

Crone123 · Le 29/06/2013, à 17:12

Pourquoi?

Haleth · Le 29/06/2013, à 18:54

Parcque faire une brute-force avec 10min entre chaque tentative, c'est encore moins possible que l'impossible

Crone123 · Le 29/06/2013, à 18:56

Sauf que les gars ils essayent pleins de mdp, et quand ils sont bloqués ils parent, puis reviennent quand ils ne sont plus bloqués
10min, c'était le cas, je bloquais plusieurs fois la même IP par jour..
31jours pose un réel problème?

Haleth · Le 29/06/2013, à 19:01

Fail2ban permet de faire du progressif, si je ne m'abuse (ban 10min la première fois, 20min ensuite, puis 1H ..)
Dans tout les cas, avec un pass de 10char, à raison de 10min par essai, le risque est faible.

Mettre 31 jours ne posent pas de problème, sauf si, par hasard, tu te fais ban (tu = ton IP).

Crone123 · Le 29/06/2013, à 19:02

Oui, enfin, je suis en local, donc je peux régler ça.

Je peux diminuer le temps, mais comment régler le progressif sur fail2ban?

Haleth · Le 29/06/2013, à 19:08

De base, dans mon fichier /etc/fail2ban/jail.conf:

# Jail for more extended banning of persistent abusers
# !!! WARNING !!!
#   Make sure that your loglevel specified in fail2ban.conf/.local
#   is not at DEBUG level -- which might then cause fail2ban to fall into
#   an infinite loop constantly feeding itself with non-informative lines
[recidive]

enabled  = false
filter   = recidive
logpath  = /var/log/fail2ban.log
action   = iptables-allports[name=recidive]
           sendmail-whois-lines[name=recidive, logpath=/var/log/fail2ban.log]
bantime  = 604800  ; 1 week
findtime = 86400   ; 1 day
maxretry = 5

En gros, ca surveille le fichier de log de fail2ban, et si le même se fait ban 5 fois en moins d'un jour, il est ban une semaine.

Crone123 · Le 29/06/2013, à 19:13

Pas mal
Mais il ne faut pas mettre: "enabled = true" dans la config?

Haleth · Le 29/06/2013, à 19:14

Oui, certainement

Crone123 · Le 29/06/2013, à 19:15

Voilà, c'est configuré Merci
EDIT: C'est normal de voir des choses comme ça:

Total failed:	2689

?

Dernière modification par Crone123 (Le 29/06/2013, à 19:17)

nesthib · Le 29/06/2013, à 19:19

Comme le dit Haleth, tenter de casser un mot de passe avec 3 essais toutes les 10 minutes, c'est mission impossible.

Crone123 · Le 29/06/2013, à 19:21

Oui, surtout sur le compte root qui est désactivé en ssh XD
Je voulais juste savoir si le nombre de tentatives étaient normales compte tenu du fait que fail2ban est censé bannir...
Ou alors il y a des attaquants qui ne font que 3 tentatives, puis attendent, puis en font 3 etc... pour ne jamais se faire bannir?

Haleth · Le 29/06/2013, à 19:24

À mon avis, c'est juste des robots qui pool à plein temps, sur plein d'IP. Tu les ban, c'est pas un problème, ils reviennent après.
Y'a personne derrière, ormis le type qui reçoit une alerte "j'ai obtenu un accès!".

Crone123 · Le 29/06/2013, à 19:25

Oui je m'en doute, mais c'est juste pour savoir "Pourquoi j'ai 2000fails de login en bannissant 15 personnes (ip)...."
Théoriquement, je devrais avoir que 90fails...

nesthib · Le 29/06/2013, à 19:52

Il y a effectivement beaucoup de bot qui ne testent que quelques fois.
Si tu veux un conseil
– mets fail2ban avec 10 minutes
– choisis un mot de passe très solide avec autorisation pour un seul compte
– empêche le ssh en root
– utilise une authentification par clé pour les autres comptes
et tu seras tranquille.

Si vraiment tu veux garder un œil sur ce qui se passe, utilise logwatch et vérifie qui s'est connecté chaque jour.

Crone123 · Le 29/06/2013, à 21:18

- fail2ban, c'est fait.
- mdp solide c'est fait.
- authentification par clé, c'est fait pour le sshfs, mais je conserve l'authentification par mdp pour les autres comptes (les autres comptes n'ont pas d'accès root, ni d'accès importants sur le serveur)
logwatch je l'utilise aussi (merci la doc en fait qui même si elle est parfois floue et parfois peu détaillée sur certains points, reste hyper pratique dans la plupart des cas, et explique pas mal de choses en matière de sécurité)

Existe t-il un moyen de dire:
→ Machin peut se connecter via mdp et par clé
→ Machin peut utiliser une clé pour se connecter mais pas un mdp
→ Machin peut utiliser un mdp mais pas une clé

L'avantage des clés est que le mdp de la clé n'est pas forcément celui du compte, autrement dit, dans le cas de "sudo", si on trouve le mdp de la clé, on ne peut pas forcément devenir root avec.
L'inconvénient des clés est qu'il faut les avoir sur sois pour se connecter...

Existe t-il un programme pour tester la fiabilité des mdp utilisateurs courant du système? (les mdp de /etc/shadow)
Est t-il possible d'avoir une clé root que l'on garde dans un coin pour le cas où? Tout en désactivant la connexion root en temps normal?
Peut t-on restreindre les clés a certaines utilisations? Exemple: clé machin: Ne peut servir qu'as un shell, clé machin ne peut servir qu'as du SSHFS, clé machin, ne peut servir que pour du sftp?
Merci

nesthib · Le 30/06/2013, à 06:40

Oui, tu peux restreindre ce que tu veux par utilisateur, par IP, par groupe… tout se passe dans le fichier de configuration /etc/ssh/sshd_config et si tu veux en savoir plus :

man sshd_config

Crone123 · Le 30/06/2013, à 18:01

OK je vais y jeter un oeil

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#1 Le 28/06/2013, à 22:42

Clés SSH

#2 Le 29/06/2013, à 00:10

Re : Clés SSH

#3 Le 29/06/2013, à 00:27

Re : Clés SSH

#4 Le 29/06/2013, à 03:35

Re : Clés SSH

#5 Le 29/06/2013, à 17:12

Re : Clés SSH

#6 Le 29/06/2013, à 18:54

Re : Clés SSH

#7 Le 29/06/2013, à 18:56

Re : Clés SSH

#8 Le 29/06/2013, à 19:01

Re : Clés SSH

#9 Le 29/06/2013, à 19:02

Re : Clés SSH

#10 Le 29/06/2013, à 19:08

Re : Clés SSH

#11 Le 29/06/2013, à 19:13

Re : Clés SSH

#12 Le 29/06/2013, à 19:14

Re : Clés SSH

#13 Le 29/06/2013, à 19:15

Re : Clés SSH

#14 Le 29/06/2013, à 19:19

Re : Clés SSH

#15 Le 29/06/2013, à 19:21

Re : Clés SSH

#16 Le 29/06/2013, à 19:24

Re : Clés SSH

#17 Le 29/06/2013, à 19:25

Re : Clés SSH

#18 Le 29/06/2013, à 19:52

Re : Clés SSH

#19 Le 29/06/2013, à 21:18

Re : Clés SSH

#20 Le 30/06/2013, à 06:40

Re : Clés SSH

#21 Le 30/06/2013, à 18:01

Re : Clés SSH

Pied de page des forums