srm RT2600AC - 2FA : code invalide... à la connexion à SRM

[.Shad.]

Regardez dans /etc/ssh/sshd_config si PermitRootLogin est défini à oui ou non, et si c'est commenté ou pas.
A noter que toute modification sera sûrement perdue à la prochaine mise à jour.

[MilesTEG1]

il y a 49 minutes, oracle7 a dit :

Rassures-toi tu n'es pas le seul à avoir des soucis à ce niveau sur le routeur.

Depuis quelques jours, si je tente une connexion avec puTTY avec mon compte User-ADMIN dès que je valide la saisie de mon MdP, puTTY quitte violemment sans aucune explication.

Maintenant depuis WinSCP, j'arrive à me connecter en SSH avec l'utilisateur root mais je dois renseigner le MdP, la connexion par clé SSH ne fonctionne plus : la clé est refusée par le serveur.

@oracle7
Je viens de tenter la connexion en root, et bien effectivement ça fonctionne, même si l'utilisateur admin est désactivé. C'est mieux que de devoir se connecter avec ce dernier...
Mais ça reste moyennement pratique.
Je me dis que c'est peut-être parce que je n'ai aucun dossier partagé de créé sur le routeur, et donc pas de home où mon utilisateur USER_ADMIN peut stocker des trucs...

il y a 59 minutes, oracle7 a dit :

J'ai donc refait une pair de clés privées/publique mais rien y fait, clé toujours refusée par le serveur.
Ce qui est bizarre c'est que sur les NAS, il n'y a aucun problèmes à ce niveau.

Je n'ai jamais essayé ce genre de connexion, je préfère entrer mon mot de passe, car si on fait avec le couple clés privée+publique, je trouve que ça peut être dangereux...
Avec le mot de passe, j'arrive sur le prompt de mon USER-ADMIN du NAS, et je dois entrer à nouveau le mot de passe après la commande sudo -i pour être en root. Ça m'oblige certes à entrer deux fois le mot de passe admin, mais au moins je suis pas direct dessus, ça me motive à être motivé pour y accéder... Bref, je suis plus rassuré ainsi 😉

(je sais pas si j'ai réussi à traduire mon ressenti avec des mots...)

il y a une heure, oracle7 a dit :

Sinon, j'arrive à désactiver sans problème le compte admin par défaut du routeur.

Moi aussi, mais faut qu'il soit activé le compte admin, sinon...

 

il y a une heure, oracle7 a dit :

Autre constat, il faut impérativement désactiver les plugins du type "uBlock Origin" dans le navigateur (FF) utilisé pour se connecter à SRM sinon, on reçoit des messages comme quoi l'utilisateur courant n'est pas autorisé pour valider par ex une modification dans le pare-feu du routeur. Va comprendre ???

Mon AdGuard du navigateur est désactivé sur les IP du LAN. Par contre, Bitdefender Antitracker non, mais ça ne pose pas de soucis, enfin j'en ai jamais eu avant...

 

il y a une heure, oracle7 a dit :

Au final, je me demande si ces problèmes ne font pas suite à la mise à jour du paquet VPN Plus Server qui a eut lieu il y à 3 semaines même si le rapport avec n'est pas évident. En tous cas, c'est bizarre ????

Hmmm, je sais pas...

Je t'avoue qu'en ce moment je ne me sers pas du tout du VPN... vu que je suis confié chez moi depuis plusieurs mois... 

 

@.Shad. Dans le fichier /etc/ssh/sshd_config j'ai ça :

#LoginGraceTime 2m
PermitRootLogin yes
#StrictModes yes
#MaxAuthTries 6
#MaxSessions 10

Du coup, pas besoin de modifier 😉

 

[oracle7]

@MilesTEG1

Bonjour,

il y a 53 minutes, MilesTEG1 a dit :

Je n'ai jamais essayé ce genre de connexion, je préfère entrer mon mot de passe, car si on fait avec le couple clés privée+publique, je trouve que ça peut être dangereux...

J'ai simplement suivi le TUTO : Accès SHH et ROOT via DSM6. Je penses que le couple clés privée+publique est plus sécurisant qu'un simple MdP même long. Mais ce n'est que mon avis ...

il y a une heure, MilesTEG1 a dit :

Dans le fichier /etc/ssh/sshd_config j'ai ça :

Je ne préfère pas modifier ce type de fichier car à la première MàJ de DSM il est réinitialisé automatiquement et avant de penser qu'il l'a été, on risque fort de chercher longtemps si un dysfonctionnement apparaît à ce niveau avant d'y penser.

En tous cas, j'espère que @.Shad. aura une idée à suggérer vis à vis de la clé réfusée par le routeur lors de la connexion WinSCP ou puTTY car il me semble bien que cela fonctionnait correctement les mois précédents.

Cordialement

oracle7😉

[.Shad.]

@MilesTEG1 @oracle7 Rien n'empêche de faire une identification par clé + mot de passe.

il y a 6 minutes, oracle7 a dit :

En tous cas, j'espère que @.Shad. aura une idée à suggérer vis à vis de la clé réfusée par le routeur lors de la connexion WinSCP ou puTTY car il me semble bien que cela fonctionnait correctement les mois précédents.

Tu as toi aussi vérifié ce que j'ai dit concernant le PermitRootLogin à @MilesTEG1 ?
Sinon je n'ai pas de RT donc je peux difficilement vérifier, mais bon le fichier de configuration de SSH du RT est de souvenir très classique.

[oracle7]

@.Shad.

Bonjour,

il y a 3 minutes, .Shad. a dit :

Tu as toi aussi vérifié ce que j'ai dit concernant le PermitRootLogin à @MilesTEG1 ?

Oui, il est en standard identique à ce qu'a dit @MilesTEG1 précédemment : non commenté et positionné à Yes.

J'ai par ailleurs comparer les fichiers /etc/ssh/sshd_config du routeur et d'un de mes NAS :

• Sur le routeur j'ai la ligne active : AuthorizedKeysFile    /etc/ssh/keys/%u/authorized_keys
• Alors que sur le NAS la "même ligne" est commentée et pointe ailleurs : #AuthorizedKeysFile    .ssh/authorized_keys
• Sur le RT et le NAS j'ai la même chose pour : #PubkeyAuthentication yes

Etonnant, non ?

Cordialement

oracle7😉

[.Shad.]

il y a 3 minutes, oracle7 a dit :

Sur le routeur j'ai la ligne active : AuthorizedKeysFile    /etc/ssh/keys/%u/authorized_keys

Il y a un utilisateur root dans /etc/ssh/keys ?

[oracle7]

@.Shad.

Bonjour,

NON, j'ai bien pensé créer un répertoire keys/root/ dans /etc/ssh/ et y mettre le fameux fichier "authorized_keys" mais toujours le même problème : cela ne survivra pas à une MàJ de SRM. Donc j'ai oublié l'idée.

Cordialement

oracle7😉

[Diabolomagic]

Il y a 4 heures, MilesTEG1 a dit :

@Diabolomagic

C'est vraiment naze comme système ça... devoir réactiver le compte admin pour se connecter en SSH est contre-intuitif pour la sécurité...

Y a pas une autre solution ? (en tout cas, moi je ne vois pas comment...)

Je suis exactement dans ton cas sauf que je me suis aperçu que même si le compte admin par défaut est désactivé cela ne m’empêche pas de me connecter en SSH avec l'utilisateur root. Dans putty je renseigne le login root@192.168.x.x et ça fonctionne !

Modifié le 7 avril 2021 par Diabolomagic
N'avait pas vu la page 2 avant de répondre ... Pardon.

[MilesTEG1]

Il y a 3 heures, Diabolomagic a dit :

Je suis exactement dans ton cas sauf que je me suis aperçu que même si le compte admin par défaut est désactivé cela ne m’empêche pas de me connecter en SSH avec l'utilisateur root. Dans putty je renseigne le login root@192.168.x.x et ça fonctionne !

J'y arrive aussi avec le compte root, même si le compte admin est désactivé.
Par contre, avec mon compte USER-ADMIN, là quoiqu'il arrive, je peux pas le connecter.

[maxou56]

@MilesTEG1 @Diabolomagic @oracle7

Bonsoir,

Pour la connexion ssh en root c'est "normal" SRM est basé sur DSM5 et a un fonctionnement différent de DSM6

https://www.synology.com/fr-fr/knowledgebase/DSM/tutorial/General_Setup/How_to_login_to_DSM_with_root_permission_via_SSH_Telnet#anchor2

Modifié le 7 avril 2021 par maxou56

[MilesTEG1]

@maxou56 Sérieux ? Sur DSM5 ?
Et beh... ils auraient pu faire une MAJ où il y avait du DSM6 sous le capot...
Espérons qu'on passera directement sur une version DSM7 en sous-main...

DSM6 est sorti quand déjà ? Que je vois si j'ai beaucoup utilisé DSM5 😄 Mon 1er syno a été un DSS212.

[oracle7]

@maxou56

Bonjour,

MERCI beaucoup pour le tuyau.

Maintenant, je souhaiterai faire la "même chose" mais avec une paire de clé privée+publique (RSA) plutôt que de taper un MdP pour me connecter à SRM et surtout qui soit reconnue et acceptée.

Cà doit exister, non ?

Cordialement

oracle7😉

Modifié le 7 avril 2021 par oracle7

[Diabolomagic]

Il y a 13 heures, maxou56 a dit :

https://www.synology.com/fr-fr/knowledgebase/DSM/tutorial/General_Setup/How_to_login_to_DSM_with_root_permission_via_SSH_Telnet#anchor2

Merci pour le tuyau 🙂

Modifié le 8 avril 2021 par Diabolomagic

[oracle7]

@Diabolomagic

Bonjour,

Dans tes réponses, il n'est pas nécessaire de re citer le post précédant dans sa totalité, ce serait bien que tu ne cites que la partie à la quelle tu réponds, cela surcharge moins les posts et ils sont plus faciles à lire. Merci.

Cordialement

oracle7😉

[Diabolomagic]

@oracle7 Oups... Désolé, tu me l'avais déjà dis en plus. J'ai édité le post précédent.

[MilesTEG1]

Bon et bien ça fait 2 jours que j'arrive à me connecter au NAS sans que le 2FA ne pose soucis...
J'ai changé le serveur NTP pou un par défaut (pool.ntp.org).
Je continuerais d'essayer régulièrement (vu que je ne laisse plus la case cochée pour garder la session ouverte ^^)

[N.A.S.]

Bonsoir,

Bon j'ai pas tout lu, mais j'ai ce problème. Après avoir déménagé, aujourd'hui mon routeur n'a pas accès à Internet (en gros, je ne peux pas utiliser de câble pour le connecter). Du coup j'ai branché mon ordinateur dessus et quand je veux me connecter j'ai le même message d'erreur concernant le 2FA.

J'ai déménagé dans un fuseau horaire différent. Celui du routeur est donc a priori sur Paris.

Sur le device où j'ai mon app 2FA, j'ai coupé le net, réglé le fuseau horaire sur Paris, redémarré l'App 2FA, mais tjs le même souci.

Avez-vous une idée de comment régler ce problème ?

Merci.

[MilesTEG1]

Tu vas devoir faire un reset du routeur j’en ai peur 😧 

Tu fais un soft reset = reset logiciel 

https://kb.synology.com/fr-fr/SRM/tutorial/What_s_the_difference_between_Soft_Reset_and_Hard_Reset

 

ca va réinitialiser le login administrateur.

tu ne devrais pas perdre la configuration du RT.

[maxou56]

Le 16/09/2022 à 23:21, N.A.S. a dit :

J'ai déménagé dans un fuseau horaire différent

Bonsoir,

Le fuseau horaire n'a pas d'importance.

Mais comme le RT2600ac il n'a pas accès à internet ne doit plus être à l'heure (sans doute de quelques minutes). Si tu es toujours sous SRM 1.2.x, il y a l'heure sur la page de connexion.

Modifié le 18 septembre 2022 par maxou56