Mon serveur YunoHost
Matériel: Serveur Dédié Kimsufi KS-4 (OVH)
Version de YunoHost: 3.7.0.12
J’ai accès à mon serveur : Par la webadmin et en SSH en temps normal
Êtes-vous dans un contexte particulier ou avez-vous effectué des modificiations particulières sur votre instance ? : non
Description du problème
Bonjour à tous,
Il y a quelques jours installé Gitlab sur mon instance Yunohost.
J’ai restauré une sauvegarde Gitlab qui était présente sur un serveur qui n’était pas sur Yunohost.
Jusqu’ici aucun problème, Gitlab fonctionne très bien.
Sauf que depuis l’installation, impossible de me connecter en SSH à mon serveur.
La connexion se fait bien et le serveur me demande un mot de passe. Mais même avec le bon mot de passe il est systématiquement refusé.
Ayant un accès à l’interface admin j’ai essayé de le modifier mais toujours le même problème. Le compte admin ne fonctionne pas non plus.
L’accès Git fonctionne très bien avec ma clef publique. Mais étant donné que c’est un accès git je n’ai pas accès au shell.
Ayant le mot de passe admin et les services d’API fonctionnel j’ai donc décidé d’ajouter une clef publique à mon utilisateur principale. Malheureusement même une fois la clef ajouté, SSH me demande un mot de passe.
A travers l’API j’ai aussi tenté l’exécution de commande Python mais j’ai une erreur venant du serveur. Il n’est pas précisé l’URL à utilisé et je pense que c’est pour ca.
Je me suis basé sur cette documentation: https://github.com/YunoHost/yunohost/blob/stretch-unstable/data/actionsmap/yunohost.yml
Je pense vraiment que le problème vient de ma conf sshd mais je ne suis pas vraiment sur.
En cogitant j’ai réussi à extraire le fichier de conf depuis Nextcloud en créant un stockage externe local.
Le voici:
# This configuration has been automatically generated
# by YunoHost
Protocol 2
Port 22
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
# ##############################################
# 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
# Use kernel sandbox mechanisms where possible in unprivileged processes
UsePrivilegeSeparation sandbox
# 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 no
StrictModes yes
PubkeyAuthentication yes
PermitEmptyPasswords no
ChallengeResponseAuthentication no
UsePAM yes
AllowUsers pouet, git
AuthorizedKeysFile /var/opt/gitlab/.ssh/authorized_keys
# 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_*
# SFTP stuff
Subsystem sftp internal-sftp
Match User sftpusers
ForceCommand internal-sftp
ChrootDirectory /home/%u
AllowTcpForwarding no
GatewayPorts no
X11Forwarding no
# 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,*mon_ip_a_moi*
PermitRootLogin yes
Malheureusement Nginx n’ayant pas les droits sur le fichier, impossible de le modifier.
J’ai eu une idée qui pourrai fonctionner si j’arrive à exécuter des commandes au travers de l’API:
- Créer un dépôt git de test
- Uploader un script bash ou python qui modifiera le fichier /etc/ssh/sshd_config
- Exécuter un commande au travers de l’API qui lancera ce fameux script
Par contre je pense que même si j’arrive à exécuter une commande au travers de l’API, un problème de droit risque encore de se poser.
Si vous avez des suggestions je suis preneur.
Merci beaucoup.