Can't use ssh with gitea after upgrade to yunohost 11

manal · September 14, 2022, 2:12pm

Mon serveur YunoHost

Matériel: Vieil ordinateur
Version de YunoHost: 11.0.9
J’ai accès à mon serveur : En SSH et Shell in a box
Êtes-vous dans un contexte particulier ou avez-vous effectué des modificiations particulières sur votre instance ? : oui
Si oui, expliquer: Je pense avoir activé l’accès sftp dans la configuration du serveur ssh. Je dis «je pense» car yunohost m’a signalé lors de la màj que le fichier sshd_config a été modifié, mais je ne me rappelle plus très bien pourquoi

Description du problème

Bonjour à tous.
Tout d’abord, merci pour le travail fantastique que vous faites avec Yunohost.

Je m’adresse à vous car mes compétences arrivent à leur limite.

J’utilise l’application gitea (packagée pour yunohost). Avant la màj de yunohost 4 vers 11, j’accédais à mes dépôts git via ssh.
Je n’entre pas dans les détails de cette configuration, mais en deux mots (pour ceux qui ne connaissent pas git), j’ai fourni à gitea une clé ssh publique qu’il associe à un compte utilisateur. Ainsi on peut demander à git sur le pc possédant la clé privée d’accéder au dépôt en utilisant l’identification gitea@monserveur.tld

Depuis la mise à jour vers yunohost 11 (a priori), je ne peux plus me connecter à mes dépôts git via ssh.
Le message d’erreur est :

gitea@monserveur.tld: Permission denied (publickey).
fatal: Impossible de lire le dépôt distant.

Ma configuration ssh classique fonctionne dans le sens où je n’ai pas de problème pour me connecter au compte admin via la commande ssh admin@monserveur.tld

Pour plus de log, la commande ssh -vT gitea@monserveur.tld donne

OpenSSH_8.9p1 Ubuntu-3, OpenSSL 3.0.2 15 Mar 2022
debug1: Reading configuration data /home/emmanuel/.ssh/config
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: include /etc/ssh/ssh_config.d/*.conf matched no files
debug1: /etc/ssh/ssh_config line 21: Applying options for *
debug1: Connecting to monserveur.tld [ww.xx.yy.zz] port 22.
debug1: Connection established.
debug1: identity file /home/emmanuel/.ssh/id_rsa type 0
debug1: identity file /home/emmanuel/.ssh/id_rsa-cert type -1
debug1: identity file /home/emmanuel/.ssh/id_ecdsa type -1
debug1: identity file /home/emmanuel/.ssh/id_ecdsa-cert type -1
debug1: identity file /home/emmanuel/.ssh/id_ecdsa_sk type -1
debug1: identity file /home/emmanuel/.ssh/id_ecdsa_sk-cert type -1
debug1: identity file /home/emmanuel/.ssh/id_ed25519 type 3
debug1: identity file /home/emmanuel/.ssh/id_ed25519-cert type -1
debug1: identity file /home/emmanuel/.ssh/id_ed25519_sk type -1
debug1: identity file /home/emmanuel/.ssh/id_ed25519_sk-cert type -1
debug1: identity file /home/emmanuel/.ssh/id_xmss type -1
debug1: identity file /home/emmanuel/.ssh/id_xmss-cert type -1
debug1: identity file /home/emmanuel/.ssh/id_dsa type -1
debug1: identity file /home/emmanuel/.ssh/id_dsa-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_8.9p1 Ubuntu-3
debug1: Remote protocol version 2.0, remote software version OpenSSH_8.4p1 Debian-5+deb11u1
debug1: compat_banner: match: OpenSSH_8.4p1 Debian-5+deb11u1 pat OpenSSH* compat 0x04000000
debug1: Authenticating to monserveur.tld:22 as 'gitea'
debug1: load_hostkeys: fopen /home/emmanuel/.ssh/known_hosts2: No such file or directory
debug1: load_hostkeys: fopen /etc/ssh/ssh_known_hosts: No such file or directory
debug1: load_hostkeys: fopen /etc/ssh/ssh_known_hosts2: No such file or directory
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: curve25519-sha256@libssh.org
debug1: kex: host key algorithm: ssh-ed25519
debug1: kex: server->client cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none
debug1: kex: client->server cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: SSH2_MSG_KEX_ECDH_REPLY received
debug1: Server host key: ssh-ed25519 SHA256:L569lRnrRsIxclCX4CsDljI6DBRvLQWwWK0ZgNV2U0c
debug1: load_hostkeys: fopen /home/emmanuel/.ssh/known_hosts2: No such file or directory
debug1: load_hostkeys: fopen /etc/ssh/ssh_known_hosts: No such file or directory
debug1: load_hostkeys: fopen /etc/ssh/ssh_known_hosts2: No such file or directory
debug1: Host 'manal.xyz' is known and matches the ED25519 host key.
debug1: Found key in /home/emmanuel/.ssh/known_hosts:16
debug1: rekey out after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: rekey in after 134217728 blocks
debug1: get_agent_identities: bound agent to hostkey
debug1: get_agent_identities: agent returned 2 keys
debug1: Will attempt key: /home/emmanuel/.ssh/id_rsa RSA SHA256:nPkSe2KxTLeZe5wcnbf8zK39u/8anjdToRQTn1qzarY agent
debug1: Will attempt key: /home/emmanuel/.ssh/id_ed25519 ED25519 SHA256:NBEeL2KH+th2JrfDt9jarKsyNMmWEH7LCNYx5YSGh54 agent
debug1: Will attempt key: /home/emmanuel/.ssh/id_ecdsa 
debug1: Will attempt key: /home/emmanuel/.ssh/id_ecdsa_sk 
debug1: Will attempt key: /home/emmanuel/.ssh/id_ed25519_sk 
debug1: Will attempt key: /home/emmanuel/.ssh/id_xmss 
debug1: Will attempt key: /home/emmanuel/.ssh/id_dsa 
debug1: SSH2_MSG_EXT_INFO received
debug1: kex_input_ext_info: server-sig-algs=<ssh-ed25519,sk-ssh-ed25519@openssh.com,ssh-rsa,rsa-sha2-256,rsa-sha2-512,ssh-dss,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,sk-ecdsa-sha2-nistp256@openssh.com,webauthn-sk-ecdsa-sha2-nistp256@openssh.com>
debug1: SSH2_MSG_SERVICE_ACCEPT received
Debian GNU/Linux 11
debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Offering public key: /home/emmanuel/.ssh/id_rsa RSA SHA256:nPkSe2KxTLeZe5wcnbf8zK39u/8anjdToRQTn1qzarY agent
debug1: Authentications that can continue: publickey
debug1: Offering public key: /home/emmanuel/.ssh/id_ed25519 ED25519 SHA256:NBEeL2KH+th2JrfDt9jarKsyNMmWEH7LCNYx5YSGh54 agent
debug1: Authentications that can continue: publickey
debug1: Trying private key: /home/emmanuel/.ssh/id_ecdsa
debug1: Trying private key: /home/emmanuel/.ssh/id_ecdsa_sk
debug1: Trying private key: /home/emmanuel/.ssh/id_ed25519_sk
debug1: Trying private key: /home/emmanuel/.ssh/id_xmss
debug1: Trying private key: /home/emmanuel/.ssh/id_dsa
debug1: No more authentication methods to try.
gitea@monserveur.tld: Permission denied (publickey).

On voit bien qu’il détect mes clés rsa et ed25519 (seule ma clé rsa est configurée dans gitea).

La réponse de sshd sur mon serveur :

Sep 14 15:54:38 monserveur sshd[17467]: Connection from 109.190.253.15 port 33396 on 192.168.0.40 port 22 rdomain ""
Sep 14 15:54:39 monserveur sshd[17467]: Failed publickey for gitea from 109.190.253.15 port 33396 ssh2: RSA SHA256:nPkSe2KxTLeZe5wcnbf8zK39u/8anjdToRQTn1qzarY
Sep 14 15:54:39 monserveur sshd[17467]: Failed publickey for gitea from 109.190.253.15 port 33396 ssh2: ED25519 SHA256:NBEeL2KH+th2JrfDt9jarKsyNMmWEH7LCNYx5YSGh54
Sep 14 15:54:39 monserveur sshd[17467]: Connection closed by authenticating user gitea 109.190.253.15 port 33396 [preauth]

Je vous fourni mon sshd_config :

# 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


# 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
AuthorizedKeysFile /home/%u/.ssh/authorized_keys

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

# 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

Merci d’avance
Emmanuel

Kit · September 14, 2022, 2:55pm

Hello,

Attention, on a ton ip et celle de ton serveur, pas sûr que ça soit intentionnel

La ligne suivante m’interpelle :

Ton user gitea fait-il bien partie de l’un de ces groupes ? (j’imagine que oui, sinon les logs indiqueraient sans doute un Illegal User).

La clef est-elle bien présente pour ton user avec les bonnes autorisations (chown ?). On dirait que le serveur cherche la clef pour l’user* emmanuel*

manal · September 14, 2022, 3:19pm

Merci de m’avoir prévenu pour les IP, je laisse celle du client : je suis dans le train.

Je pense que gitea fait bien partie de ssh.app :
sudo groups gitea retourne

gitea : gitea ssh.app

Quand tu vois l’utilisateur emmanuel c’est sur le client. J’ai ajouté ces logs pour plus de détail sur l’erreur obtenue côté client. Mais pour aller plus loin dans ta question, je ne sais pas où gitea stocke les clés publiques. J’imagine que c’est dans une base de donnée.

nounix · September 14, 2022, 8:10pm

Bonjour,

Est-ce qu’il s’agit bien de la dernière version de gitea (1.17.2~ynh1) ?

manal · September 14, 2022, 8:39pm

Bonjour nounix,
Je viens de mettre à jour l’application.
J’ai toujours le même problème.

nounix · September 14, 2022, 10:23pm

Ça ressemble à un problème que j’ai rencontré précédemment, mais à priori la dernière mise à jour corrige le fichier /etc/passwd

[Résolu] Problème d’accès ssh Gitea

tituspijean · September 15, 2022, 10:50am

Peux-tu partager le journal de la mise à jour ?

manal · September 21, 2022, 5:03pm

Salut, j’ai ma réparé mes bêtises.
Grâce à la commande

yunohost tools regen-conf ssh --force

je suis revenu à la configuration de base, et tout roule.

Merci pour le temps que vous avez pris pour me répondre.

system · October 21, 2022, 5:04pm

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