Erreur ssh lors du diagnostique

Bon, alors j’ai fait un : sudo yunohost tools regen-conf ssh --dry-run --with-diffet obtenu :

> sudo yunohost tools regen-conf ssh --dry-run --with-diff
> Warning: The configuration file '/etc/ssh/sshd_config' has been manually modified and will not be updated
> ssh: 
>   applied: 
>   pending: 
>     /etc/ssh/sshd_config: 
>       diff: @@ -17,13 +17,13 @@
>  # https://infosec.mozilla.org/guidelines/openssh
>  # ##############################################
>  
> -# Keys, ciphers and MACS
> -KexAlgorithms curve25519-sha256@libssh.org,ecdh-sha2-nistp521,ecdh-sha2-nistp384,ecdh-sha2-nistp256,diffie-hellman-group-exchange-sha256
> -Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr
> -MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-512,hmac-sha2-256,umac-128@openssh.com
>  
> -# Use kernel sandbox mechanisms where possible in unprivileged processes
> -UsePrivilegeSeparation sandbox
> +  # By default use "modern" Mozilla configuration
> +  # Keys, ciphers and MACS
> +  KexAlgorithms curve25519-sha256@libssh.org,ecdh-sha2-nistp521,ecdh-sha2-nistp384,ecdh-sha2-nistp256,diffie-hellman-group-exchange-sha256
> +  Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr
> +  MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-512,hmac-sha2-256,umac-128@openssh.com
> +
>  
>  # LogLevel VERBOSE logs user's key fingerprint on login.
>  # Needed to have a clear audit track of which key was using to log in.
> @@ -62,14 +62,40 @@
>  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
> -Match User sftpusers
> -        ForceCommand internal-sftp
> -        ChrootDirectory /home/%u
> -        AllowTcpForwarding no
> -        GatewayPorts no
> -        X11Forwarding no
> +
> +# 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
> @@ -77,21 +103,4 @@
>  # 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##-> my_webapp
> -# Hardening user connection
> -Match User webapp1
> -  ChrootDirectory %h
> -  ForceCommand internal-sftp
> -  AllowTcpForwarding no
> -  PermitTunnel no
> -  X11Forwarding no
> -##<- my_webapp
> -##-> my_webapp__2
> -# Hardening user connection
> -Match User webapp2
> -  ChrootDirectory %h
> -  ForceCommand internal-sftp
> -  AllowTcpForwarding no
> -  PermitTunnel no
> -  X11Forwarding no
> -##<- my_webapp__2
> +    PermitRootLogin yes
>       status: modified

J’imagine que c’est cela qui pose problème ? :

-##<- my_webapp__2

  • PermitRootLogin yes
    status: modified

Mais que dois-je faire avec ? :

because it contains no ‘AllowGroups’ or ‘AllowUsers’ directive to limit access to authorized users.

Je ne comprends pas ce que cela veut dire.

Merci.