Forum debian-fr.org

Problème en cours :

Arrive le moment fatal où j'ai planté la dernière fois.

Je dois vérifier si la clé fonctionne avant de verrouillé le serveur.
Ceci est il la chose à faire :

1 :
Dans :


je dois avoir :


2 : Puis je relance le service ssh


3:
Normalement si je me connecte via putty (ou autre) il devrait immédiatement le loggé ?
Ou dois-je quand même taper mon pseudo ?
Ou depuis cgywin que taper ? (ca semble être presque identique a des commandes unix)

Comprenez bien que je veux éviter de tout casser une fois de plus
Genre "le héros était enfermé dans un coffre verrouillé de l’extérieur dont lui seul avait avec la clé"



Bonne journée

Précédent problème résolu.

Je passe à celui qui devrait être le dernier pour cette phase du tuto.

Résultat des tentatives de connexion :
Connexion au root par mot de passe : refusé
Connexion au user par clé : authorisé
Connexion au user par mot de passe : authorisé
Connexion au root par mot de passe, depuis le user : authorisé

Est-ce normal avec la configuration établie que le user puisse encore se connecter via mot de passe, sans utiliser sa clé ?
Est-il possible de verrouiller aussi ce type de connexion pour ne laisser comme possibilité de connexion au user uniquement la connexion par clé user. Puis au root via mot de pass, depuis le user ainsi connecté.

Si ce n'est pas normal, je pense que je vais devoir réinitialiser mon serveur.
Existe t il un autre moyen de tout autre à zéro que celui de réinstaller le serveur ?

Bonne journée

Salut,


Oui si ta configuration le permet...

Tu n'as pas bloqué le connexion par mot de passe, tu as bloqué la connexion de root;
Si tu souhaites empêcher aussi un utilisateur de se connecter par mot de passe:

_________________
GO Compréhensif...
SID 3.8-etc...-aptosid-amd64 && Xfce 4.10
"Pastbin" / "service d'hébergement d'images" Visitez et Participez au wiki du forum!

Ok, bétise de ma part, c'est pas la 1ere fois, j'avais laissé le #
Je commence à y faire un peu plus attention, je sais bien que ca passe la ligne en tant que commentaire.

Sachant que si je ne n permet l'accès que par clé, je dois toujours l'avoir sur moi (au cas où j'ai besoin de relancer un service à distance). Ce qui est une contrainte, car si j'oublie ma clé et que je part 7 jours à 350km...

Selon toi, c'est déjà assez sécurisé comme ça, inutile d'aller aussi loin.
ou
Mieux vaut être un peu parano avec son serveur ?

Merci, et désolé pour cette erreur que j'aurais résoudre seul.
Bonne journée

Je serais toi et compte tenu de ta faible experience , je laisserais le port 22 et le PermitRootlogin à without password comme je le signale dans le tuto qui te sert de fil rouge . Au moins tu pourras alors compter sur OVH pour te rattraper le coup en cas de bêtise de ta part.

A titre personnel, j'assume d'être seul mettre à bord dans l'exemple du tuto et je veille à prendre mes propres dispositions de secours ( ou pas mais c'est mon problème ) si je merde, d'autant que je gère des services pas du tout critiques et qui peuvent donc être indisponibles quelques temps sans conséquence. En plus l'exemple du tuto c'est du vKS donc de l'offre low cost d'OVH , je n'attends aucun service de leur part donc j'ai fermé leur accès.

si j'avais à monter un hébergement avec des impératifs de disponibilité, je ne choisirais plus du tout les même solutions.

My 2 cents

_________________
Ubuntu/Debian user since 2008... http://sorrodje.alter-it.org
Moteur de recherche by seeks, Debian & myself : http://seeks.alter-it.org

Ok, donc sécurité. Si ca plante c'est pas bien grave à la condition que je soit capable de tout relancer en moins de 72h. (on verra). Sans oublie mes backups, je suppose que réinstaller le serveur coté ovh, ca écrase tout le disque.

Donc port 22 -> personnalisé -> verrouillé (sans mot de passe)
Aucune accès sauf le mien en gros.

Merci pour le conseil. Je voulais être certain.

Bonne journée

Voilà! Si tu verrouilles tout, tu dois être en mesure d'assurer seul la réparation, OVH ne pourra rien pour toi.

_________________
Ubuntu/Debian user since 2008... http://sorrodje.alter-it.org
Moteur de recherche by seeks, Debian & myself : http://seeks.alter-it.org

Ce sera ainsi, de toute façon pour faire réparer il faut payer...
Et pour le moment ...

Donc voila
Merci.

Salut,


Suffit de pas casser...
Tu devrais faire tes armes sur un serveur à la maison (une machine virtuelle fait très bien l'affaire).
Quand tu es sur de toi tu balance les commande sur le serveur distant.

_________________
GO Compréhensif...
SID 3.8-etc...-aptosid-amd64 && Xfce 4.10
"Pastbin" / "service d'hébergement d'images" Visitez et Participez au wiki du forum!

Je préfère le faire une réel pour 10e/mois.
Ca m'évite de mauvaises surprises sur des possibles différences entre ce que je fais chez moi et ce qui se passera réellement chez ovh. J'ai connu ca avec le php, obligé d'avoir un domaine de test sur un serveur effectif.

Salut,
Le prix n'est pas un argument. Je comprend mieux maintenant pourquoi les techniciens de OVH mettent du temps à répondre. Tu imagine le nombre de systèmes a réinstaller parceque les utilateurs ne prennent pas la peine d'en savoir un minimum avant de lancer des commandes sur leurs dédiés...

Les commandes et leurs résultats sont identiques sur une VM et un dédié.

Il faudrait exiger un permis avant de vendre des dédiés!!!

_________________
GO Compréhensif...
SID 3.8-etc...-aptosid-amd64 && Xfce 4.10
"Pastbin" / "service d'hébergement d'images" Visitez et Participez au wiki du forum!

les commandes oui, tout comme en php, mais les paramètres pas nécessairement, rarement même. Étant noob je ne vois pas comment je peut paramétrer mois même mon serveur virtuel à l'identique d'un serveur ovh ... Et même si j'en ai la possibilité je n'aurai aucune certitude que ce soit le cas.
Quand au techniciens ils ne font qu'installer, et paye un forfait pou cela, ensuite las manip sont elles aussi payantes... donc ils n'y a pas de temps perdu, argent supplémentaire = employé supplémentaire.

Salut,



Et quand ils ont terminé la manœuvre tu n'en sais pas plus qu'avant

_________________
Debian 3.9-2.slh.2-aptosid (3.9.12) GT520 > nvidia 319.17 ==> Intel (I5) ~3GHz
http://aptosid-fr.org/