Matériel: PC Version de YunoHost: 4.2 J’ai accès à mon serveur : En SSH & En direct avec un clavier/écran Êtes-vous dans un contexte particulier ou avez-vous effectué des modificiations particulières sur votre instance ? : Suite a mise a jour 4.2
Description du problème
Suite a la mise a jour 4.2 je n’ai plus d’acces ssh avec le compte qui etait dedié a cette usage.
Bonjour.
A l’origine de mon serveur, j’ai installer une debian et configuré un accès ssh avec un utilisateur dédié (appelons le SECU c.f. la cité de la peur). Puis j’ai installer yunohost et j’ai bien pris soin de ne pas utiliser SECU comme utilisateur yunohost car dans mon esprit il était uniquement la pour la maintenance.
Depuis la merveilleuse mise a jour 4.2 et ça prise en charge des droits ssh, SECU n’a plus d’accès ssh.
Avant de faire le “bourrin” et d’aller modifier le /etc/sshd_config et/ou le /etc/group, je viens exposer mon souci et poser quelque questions:
Comment régler mon problème ?
Avoir des accès ssh sur des utilisateurs yunohost ne me plais pas trop, qu’en pensez vous ?
Est il possible d’avoir toujours mon compte SECU sans qu’il soit utilisateur yunohost et que cette config ne sois pas écrasé par de future MaJ ?
J’ai pris l’habitude de ne pas utiliser les conventions. Car je me dis que si j’avais a attaquer une machine j’aurai tendance a teste admin, root … mais je suis peut être trop parano
admin est moins courant que root (la très grande majorité des bots testent surtout root, ou des login plus ou moins random), et de toute façon l’accès en admin est actif à moins que tu ne bricoles la conf ssh dans ce sens …
Aussi ce genre de ~supersitions à coup de “j’utilise pas admin pour me logger donc je suis + secure” créé un faux sentiment de sécurité. Dans la mesure où tu utilises un mot de passe raisonnablement compliqué (je parles pas d’un mot de passe de 150 char, je parle de 12 char ou plus), ou mieux, une clef SSH, alors si ton serveur se fait poutrer ce ne sera pas par un bruteforcing sur SSH. Est-ce que tu as pensé à toutes les autres portes d’entrées et surface d’attaque de ton serveur ? Une fois un de mes serveurs s’est fait poutré car j’avais créé un user “test” avec comme mot de passe “test”, et un bot à transformer le serveur en serveur de spam en se connectant sur le serveur SMTP … Et on pourrais citer 15 autres exemples de comment un serveur se fait poutrer partiellement ou complètement sans qu’il n’y ai SSH dans l’histoire.
Bref, utiliser admin, ça fait le job, et faire la danse de la pluie pour croire améliorer la sécu c’est contre productif. (Déjà le fait que dans Yunohost on se connecte en admin et pas en root est discutable). Ou alors tu as une vraie raison pratique de te connecter avec un autre user …
Si, il y a un compte admin, seulement ce n’est pas un user unix mais un user ldap
Si tu veux vraiment utiliser un autre user, tu peux potentiellement faire genre “usermod -a -G ssh.app ton_user” et il devrait ensuite avoir les droits de se connecter…
Ou sinon, avoir un user yunohost classique que tu autorises à se connecter en SSH, c’est très bien aussi
Ce sont les users yunohost + admin qui est un user à part
Tu peux potentiellement bricoler avec slapcat + grep mais bon, yunohost user list sinon … (comme dit, qui ne listera pas admin, mais qui existe tout de même …)
Tu as peut être été banni temporairement par fail2ban sur le port 22 à le suite de trop nombreuses tentatives erronées ?
Pour le côté pratique de se connecter facilement avec le même user partout, tu peux aussi utiliser un fichier .ssh/config pour spécifier que pour ce serveur là tu veux un autre user.
@djez ton compte admin est celui qui te permet de rentre dans l’interface admin de Yunohost, donc c’est vrai que tu rentres juste le mot de passe pour accéder à l’interface admin.
En SSH, essaie admin@xx.xx.xx.xx avec le mot de passe pour accéder à l’interface admin de Yunohost.
Avec plaisir, et hop un problème de résolu.
Moi aussi j’aime bien la console, mais lors de grosses mises à jour, un regard neuf via la webadmin ne fait pas de mal.
A++
)