Tuto pour les nuls pour : serveur débian ovh : clé

Support Debian
#21

[quote=“westernz”]Ok je vais essayé.
Nouvelle question

sur : $ ssh-keygen -t dsa -f ~/.ssh/mot_peu_importe
On me demande un pass phrase.
Je peux laisser vide ?
Je dois laisser vide ?
Je dois donner un passphrase quelconque ? genre “toto” ?

Merci :slightly_smiling:[/quote]

Comme tu le souhaites.
Si tu entres un mot de passe il faudra le taper à chaque fois.
Si tu n’en mets pas, tu n’auras pas besoin de le taper quand tu te connecte.

Sachant qu’il y une clef, bien au chaud sur ta machine, je suis d’avis de ne pas mettre de mot de passe (sinon, autant se connecter directement avec un mot de passe…).
Mais les avis divergent, et c’est plus sécurisé avec un mot de passe.

#22

Ok, donc sans, c’est pour novice, donc il faut simplifié.

Si je ne lui donne pas de chemin de manière à laisser le fichier dans le dossier caché par defaut il me demande ceci :
Enter file in which to save the key (/home/Diagonale/.ssh/id_dsa):

  • Je ne sais pas de quoi il s’agit
  • J’ai noté mykey mais je ne sais pas ce que ca fait. JE m’attendez à ce que le nom de clé soit mykey et non id_dsa.pub

Suite :

Pour ce qui est du chemin local de a clé.
Je crée la clé via cygwin. Dans le dossier par défaut.

Mais pour la placer sur le serveur je vais utiliser putty car je ne sais pas comment copier vers le serveur via cgywin.
j’ai tenté :
$ ssh-copy-id -i ~/.ssh/labas.pub vks10509.ip-37-59-125.eu
ca me retourne : /usr/bin/ssh-copy-id: ERROR: No identities found

S’il s’agit d’un probleme de connexion, d’identification, si je tente de le passer depuis putty je vais avoir problème sur le chemin vers le dossier local.
Le dossier par defaut de cygwin n’est pas le même que celui de putty.
Je ne sais pas comment les dossier sont définit il y a des # des ~ et des $ je n’y comprend rien. Je ne connais que le dos personnellement “c:…”

#23

Salut,
Sans moi pour Cygwin et putty, je n’utilise pas…

Pour ceci: /home/Diagonale/.ssh/id_dsa
Il demande simplement le chemin et le nom, tu n’as qu’a mettre: /home/Diagonale/.ssh/labas (ou ~/.ssh/labas)

#24

CREATION
Pour
$ ssh-keygen -t dsa
A la question :
Enter file in which to save the key (/home/Diagonale/.ssh/id_dsa):
Je laisse vide ca ira très bien ?

COPIE
sous cygwin
$ ssh-copy-id -i ~/.ssh/id_dsa.pub "an16@37.59.125.3 -p 22"

[quote]The authenticity of host ‘37.59.125.3 (37.59.125.3)’ can’t be established.
RSA key fingerprint is a7:6b:12:a4:e7:b2:1e:a6:7b:da:4b:ae:22:0e:cd:fe.

Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added ‘37.59.125.3’ (RSA) to the list of known hosts.

an16@37.59.125.3’s password:
Now try logging into the machine, with “ssh 'an16@37.59.125.3 -p 22’”, and check in:

~/.ssh/authorized_keys

to make sure we haven’t added extra keys that you weren’t expecting.
[/quote]

Ça semble bon ça ?
J’aurai due valide le nouveau port ssh avant ou cela ne changera rien ?
Il passera de 22 à 3546 après le redémarrage service ssh.

Merci

#25

re,

[quote=“westernz”]Ça semble bon ça ?[/quote]Oui

[quote=“westernz”]J’aurai due valide le nouveau port ssh avant ou cela ne changera rien ?
Il passera de 22 à 3546 après le redémarrage service ssh.[/quote]Ça ne changera rien à la clef.

#26

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 :wink:
Genre “le héros était enfermé dans un coffre verrouillé de l’extérieur dont lui seul avait avec la clé”

Bonne journée

#27

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

#28

Salut,

[quote=“westernz”]…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é.[/quote]

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:

PermitRootLogin no ... RSAAuthentication yes PubkeyAuthentication yes ... PasswordAuthentication no

#29

Ok, bétise de ma part, c’est pas la 1ere fois, j’avais laissé le # :frowning:
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

#30

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 :laughing: ) 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 :slightly_smiling:

#31

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

#32

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

#33

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

Donc voila :slightly_smiling:
Merci.

#34

Salut,

[quote=“westernz”]Ce sera ainsi, de toute façon pour faire réparer il faut payer…
Et pour le moment …

Donc voila :slightly_smiling:
Merci.[/quote]

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.

#35

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.

#36

[quote=“westernz”]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.[/quote]

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… :013

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!!! :geek:

#37

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.

#38

Salut,

[quote=“westernz”]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.[/quote]

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