Perte connexion ssh après MàJ 4.2

Support
1

Bonsoir,

Je me permets d’ouvrir un sujet pour vous demander votre aide concernant l’impossibilité de me connecter en ssh sur mon serveur Ynh depuis le passage à la version 4.2.

Après la MàJ, l’outil de diagnostique m’indiquait que la config ssh devait être régénérée et m’a indiquait une commande à exécuter pour cela.
Depuis dès que j’essaie de me connecter j’ai le message suivant après avoir rentré le mot de passe “Permission denied, please try again.”

J’ai bien essayé de modifier le ficchier sshd_config en autorisant la connexion root et par mot de passe, j’ai également autorisé l’utilisateur amdin via “allowuser” mais tout ceci ne change rien.
Voici le fichier :

# This configuration has been automatically generated
# by YunoHost

Protocol 2
Port 1991

ListenAddress ::
ListenAddress 0.0.0.0


HostKey /etc/ssh/ssh_host_ecdsa_key
HostKey /etc/ssh/ssh_host_ed25519_key
HostKey /etc/ssh/ssh_host_rsa_key

# ##############################################
# Stuff recommended by Mozilla "modern" compat'
# https://infosec.mozilla.org/guidelines/openssh
# ##############################################


  KexAlgorithms diffie-hellman-group-exchange-sha256
  Ciphers aes256-ctr,aes192-ctr,aes128-ctr
  MACs hmac-sha2-512,hmac-sha2-256


# LogLevel VERBOSE logs user's key fingerprint on login.
# Needed to have a clear audit track of which key was using to log in.
SyslogFacility AUTH
LogLevel VERBOSE

# #######################
# Authentication settings
# #######################

# Comment from Mozilla about the motivation behind disabling root login
#
# Root login is not allowed for auditing reasons. This is because it's difficult to track which process belongs to which root user:
#
# On Linux, user sessions are tracking using a kernel-side session id, however, this session id is not recorded by OpenSSH.
# Additionally, only tools such as systemd and auditd record the process session id.
# On other OSes, the user session id is not necessarily recorded at all kernel-side.
# Using regular users in combination with /bin/su or /usr/bin/sudo ensure a clear audit track.

LoginGraceTime 120
PermitRootLogin yes
StrictModes yes
PubkeyAuthentication yes
PermitEmptyPasswords no
ChallengeResponseAuthentication no
AllowUsers r2d2
PasswordAuthentication yes
UsePAM yes

# Change to no to disable tunnelled clear text passwords
# (i.e. everybody will need to authenticate using ssh keys)
#PasswordAuthentication yes

# Post-login stuff
Banner /etc/issue.net
PrintMotd no
PrintLastLog yes
ClientAliveInterval 60
AcceptEnv LANG LC_*

# Disallow user without ssh or sftp permissions
AllowGroups ssh.main sftp.main ssh.app sftp.app admins root

# Allow users to create tunnels or forwarding
AllowTcpForwarding yes
AllowStreamLocalForwarding yes
PermitTunnel yes
PermitUserRC yes

# SFTP stuff
Subsystem sftp internal-sftp

# Apply following instructions to user with sftp perm only
Match Group sftp.main,!ssh.main
    ForceCommand internal-sftp
    # We can't restrict to /home/%u because the chroot base must be owned by root
    # So we chroot only on /home
    # See https://serverfault.com/questions/584986/bad-ownership-or-modes-for-chroot-directory-component
    ChrootDirectory /home
    # Forbid SFTP users from using their account SSH as a VPN (even if SSH login is disabled)
    AllowTcpForwarding no
    AllowStreamLocalForwarding no
    PermitTunnel no
    # Disable .ssh/rc, which could be edited (e.g. from Nextcloud or whatever) by users to execute arbitrary commands even if SSH login is disabled
    PermitUserRC no

Match Group sftp.app,!ssh.app
    ForceCommand internal-sftp
    ChrootDirectory %h
    AllowTcpForwarding no
    AllowStreamLocalForwarding no
    PermitTunnel no
    PermitUserRC no
    PasswordAuthentication yes

# root login is allowed on local networks
# It's meant to be a backup solution in case LDAP is down and
# user admin can't be used...
# If the server is a VPS, it's expected that the owner of the
# server has access to a web console through which to log in.
Match Address 192.168.0.0/16,10.0.0.0/8,172.16.0.0/12,169.254.0.0/16,fe80::/10,fd00::/8
    PermitRootLogin yes

J’ai aussi essayé en désactivant Fail2ban mais toujours sans succès.

Merci de votre aide !

2

Tu as bien essaye de te connecter avec l’utilisateur admin. Je vois que tu as changé le port SSH, est-ce que tu le renseignes bien quand tu te connectes ?

Tu as bien fait les migrations ?

Webadmin > Tools > Migrations

SI la migration ssh / sftp n’est pas faite ça peut expliquer.

3

Salut et merci pour ton aide !

Oui je me connecte bien avec l’utilisateur admin (qui fait partie du groupe sudo).
Oui je renseigne bien le port de connexion avec l’option -p comme habituellement avant la MàJ.
En effet je n’ai pas fait de migration mais lorsque je vais dans Webadmin > Tools > Migrations, j’ai d’indiqué " Aucune migration en attente "

4

Cette ligne prends probablement le dessus sur le AllowGroups, du coup seul r2d2 peut se connecter…

5

Salut Aleks et merci,

Justement c’est avec r2d2, qui est aussi l’utilisateur admin, que j’essaie de me connecter (et avec lequel je me connectais avant la maj). La ligne AllowUsers je l’ai rajoutée après avoir constaté l’échec de connexion donc même sans cette ligne ça ne marche pas =/

6

Nonon l’user admin il s’appelle admin …

Il faut que tu nous dite précisément quelle manip tu fais pour te connecter, et quel résultat tu obtiens

7

Alors est-ce que tu vas me croire si je te dis qu’en vérifiant avec la commande “cat /etc/passwd” il n’y a pas d’utilisateur “admin”…

Sinon pour me connecter j’utilise “depuis toujours” la commande “ssh -p1991 r2d2@mondomaine.fr” avant la maj cette commande fonctionnait très bien. Depuis la maj après avoir envoyé cette commande le serveur me demande le mdp pour r2d2 et lorsque je le rentre il me renvoie “Permission denied, please try again.” De même si j’essaie de me connecter en root lorsque la connexion root est autorisée dans le fichier sshd_config (avec ou sans la ligne “AllowUser”)

En direct sur le serveur pas de soucis pour me connecter ce qui semble exclure un mauvais mdp.

8

Oui, car c’est un user LDAP, pas un user unix, mais il existe bel et bien …

Oui, car la conf SSH a changé pour n’autoriser qu’une liste explicite d’user, admin, et les users yunohost autorisé à se logger en SSH (ou root, seulement depuis le réseau local)

Car la connexion en root ne marque que depuis le réseau local (et donc que si tu spécifie l’IP locale)

9

Ok ok !

En effet avec la commande “ldapsearch” je retrouve l’utilisateur admin. Par contre je n’ai pas le mot de passe de cette utilisateur… Y’a-t-il un moyen de le récupérer ou de le modifier ?

Ou alors serait-il possible de rajouter un utilisateur autorisé à ce connecter en SSH ?

10

Il s’agit du meme mot de passe que pour se connecter à la webadmin

Si tu as perdu le mot de passe mais que tu es capable de te connecter en ssh par un autre biais, tu peux le changer par “yunohost tools adminpw”

11

En effet avec admin la connexion fonctionne ! Merci pour l’aide et les explications.

Par contre j’ai un peu de mal à saisir la logique : il me semblait qu’il était favorable niveau sécurité d’avoir un nom utilisateur peu facile à trouver, donc pas un nom “conventionnel”, pour éviter les attaques. Là, en définissant “admin” comme utilisateur, cela ne facilite-t-il pas la possibilité de trouver l’user ssh ?

De plus, une fois connecté avec admin je peux exécuter des commandes sudo sans retaper le mot de passe root alors qu’avant, avec r2d2, je devais, lors de la première commande sudo, redonner le mot de passe.

Mes excuses si mon interrogation vous semble un peu idiote mais je ne suis pas un utilisateur expert et j’essaie de comprendre.

12

Oui et non, ça fait un peu partie des “danses de la pluie” : c’est un peu du même ordre que changer le port SSH. Ça n’améliore pas la sécurité “absolue” du système, c’est juste que c’est moins conventionnel. Classiquement on dit toujours qu’il faut désactiver le login en root pour ce genre de raison … admin est déjà un peu moins conventionnel que root. Aussi d’un point de vue attaquant extérieur, tu ne peux pas vraiment déduire que admin existe réellement ou non, car SSH fait “comme si” l’user sur laquelle la connexion est demandé existait - même si il n’existe pas, ou n’est pas autorisé à se connecter en SSH. Enfin, d’un point de vue attaquant, savoir qu’un user existe ou n’existe pas, ça n’amène pas à grand chose, la vrai sécurité, c’est le mot(ou phrase) de passe, ou bien la clef SSH.

Hmoui ça aussi c’est discutable, mais on va dire que d’un point de vue d’un attaquant extérieur, si tu avait accès à un shell “r2d2”, même si il faut taper le mot de passe, ce serait tout de même quasiment game over pour toi … car sous l’hypothèse où l’attaquant peut revenir plus tard, alors il peut modifier un peu ta conf pour intercepter le mot de passe la prochaine fois que tu utiliseras sudo, et hop. Ceci dit le fait de devoir taper le mot de passe régulièrement en sudo permet de se prémunir du cas où tu oublies de verrouiller ton laptop avant d’aller 5 minutes au toilette, ce genre de chose, mais bref.

Oui c’est pas vraiment des questions idiotes, en matière de sécu il y a plein de “j’ai entendu dire que”, mais quand on se pose la question de pourquoi, peu de gens savent vraiment expliquer pourquoi. Par exemple : pourquoi ne pas se logguer en root directement ? En pratique, ça n’apporte pas vraiment de sécu - mais dans les justifications on peut trouver par exemple qu’il est plus facile d’auditer après coup les commandes lorsqu’elles sont lancées avec sudo (car les commandes executées avec sudo sont logguées dans /var/log/auth.log) que si lancée depuis l’user root - notamment dans des contextes pro où plusieurs personnes ont un accès sudo sur une même machine. Mais là encore, on pourrait discuter des heures, car un attaquant pourrait effacer ses traces de /var/log/auth.log.

Le problème c’est que ce genre de truc peut vite donner un faux sentiment de sécu (wahou regardes mon serveur il est trop secure, j’ai changé le port ssh, et je me connecte meme pas en root), sauf que la sécurité est vraiment transversale et couvre pleins d’aspect, et ton système est aussi secure que son maillon le plus faible, car ou oubli qu’on a tel ou tel service exposé dans un coin.

Bref, se connecter en admin c’est tout à fait acceptable et pas vraiment un problème de sécu comparer à se connecter avec un autre user. (Mais tu as raison : à un moment dans la doc de yunohost, dans la page /security, c’était conseillé de faire la manip que tu as faite pour se connecter avec un autre user, mais en vrai, mouarf) (Aussi : dans le futur on prévoit tout de même d’en finir avec ce fameux user ‘admin’ car ça créé pleins de confusion plutot que d’avoir un groupe “admins” qui contiendrait plusieurs “vrais” users yunohost classiques, et ce sera plus intuitif)

13

Bonjour,

Le seul avantage que je vois dans le changement du port SSH est de limiter un peu la quantité de log généré par les bots. Au delà de ça, un attaquant peut le déduire facilement avec un scan de port.

Mais il faut également savoir qu’un utilisateur local sans privilèges peut écouter sur les ports supérieurs ou égaux à 1024. N’importe quel utilisateur local pourrait donc potentiellement causer une attaque DoS en écoutant sur le même port que le service SSH lorsque ce dernier est arrêté.

14

Perso j’ai toujours compris ça plus du côté de la fiabilité. Prendre l’habitude de ne pas lancer des rm -Rf PATH en root si c’est pas nécessaire, ça évite les accidents du type: je (ou mon chat, ou mon neveu sur mes genou) tape sur entrée trop tôt avant d’avoir terminer d’écrire le chemin complet, idem pour chown ou chmod… #truestory

Mais dans la pratique c’est contraignant et si c’est pour au final toujours préfixer par sudo ça sert à rien. Donc, pour moi cette pratique dépend surtout si tu fais autres choses que de l’adminsys en ligne de commande ou pas.

15

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.