DS918+ - Impossible to clone / pull / push via SSH Gitea

[sebsn86]

• Gitea version (or commit ref): 1.12.3
• Git Server version: 2.26.2
• Operating system: DSM 6.2.3-25426 Update 2 (x64)
• Database (use [x]):
  • PostgreSQL
  • MySQL
  • MSSQL
  • SQLite
• Can you reproduce the bug at https://try.gitea.io:
  • Yes (provide example URL)
  • No
  • Not relevant
• Log gist:

Description

As this issue, I cannot clone, pull / push via SSH Gitea on my Synology
I did all the steps described in the ticket 5497, but I have this error :

`
git clone ssh://gitea@domain.local:7999/xxxxxx/project-example.git
Clonage dans 'project-example'...
Permission denied, please try again.
fatal: Impossible de lire le dépôt distant.

Veuillez vérifier que vous avez les droits d'accès
et que le dépôt existe.
`

But when i try to clone by HTTP mode, it's working perfectly.

What I have done :

I installed Gitea on my Synology by following these steps :

• Create .spk file with https://github.com/flipswitchingmonkey/gitea-spk
• Install MariaDB 10, Git Server, PHPMyAdmin, Web Station and Gitea spk on my Synology
• I created my MySQL Database called "gitea" and created User mysql called "gitea"
• I configured Gitea during install process with my private domain and custom HTTP and SSH ports.
• I configured SSH port on my Synology so that it's identical to the one indicated in gitea
• I copied / pasted the public SSH key from my local machine in Gitea UI profile.
• I applied rights on /usr/local/gitea/gitea/.ssh (700) and /usr/local/gitea/gitea/.ssh/authorized_keys (600)
• I runed "Update the '.ssh/authorized_keys' file with gitea SSH keys"
• I added /gitea in /etc/passwd after /var/packages/Gitea/target
• I changed /sbin/nologin by /bin/sh in /etc/passwd
• I checked wheter PubkeyAuthentication is enabled in /etc/sshd_config
• I appended gitea to the administrators group in /etc/group

Here my app.ini :

...
[server]
SSH_DOMAIN                  = domain.local
DOMAIN                            = domain.local
HTTP_PORT                     = 8080
ROOT_URL                       = https://domain.local/
DISABLE_SSH                  = false
SSH_PORT                       = 7999
LFS_START_SERVER      = true
LFS_CONTENT_PATH      = /usr/local/gitea/gitea/data/lfs
LFS_JWT_SECRET          = xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
OFFLINE_MODE               = false
START_SSH_SRVER        = true
BUILTIN_SSH_SERVER_USER = 
SSH_LISTEN_PORT          = %(SSH_PORT)s
SSH_CREATE_AUTHORIZED_KEYS_FILE = true
...

[sebsn86]

Here my ssh log :

OpenSSH_8.2p1 Ubuntu-4ubuntu0.1, OpenSSL 1.1.1f 31 Mar 2020
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 domain.local [192.168.1.33] port 7999.
debug1: Connection established.
debug1: identity file /home//.ssh/id_rsa type 0
debug1: identity file /home//.ssh/id_rsa-cert type -1
debug1: identity file /home//.ssh/id_dsa type -1
debug1: identity file /home//.ssh/id_dsa-cert type -1
debug1: identity file /home//.ssh/id_ecdsa type -1
debug1: identity file /home//.ssh/id_ecdsa-cert type -1
debug1: identity file /home//.ssh/id_ecdsa_sk type -1
debug1: identity file /home//.ssh/id_ecdsa_sk-cert type -1
debug1: identity file /home//.ssh/id_ed25519 type -1
debug1: identity file /home//.ssh/id_ed25519-cert type -1
debug1: identity file /home//.ssh/id_ed25519_sk type -1
debug1: identity file /home//.ssh/id_ed25519_sk-cert type -1
debug1: identity file /home//.ssh/id_xmss type -1
debug1: identity file /home//.ssh/id_xmss-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_8.2p1 Ubuntu-4ubuntu0.1
debug1: Remote protocol version 2.0, remote software version OpenSSH_7.4
debug1: match: OpenSSH_7.4 pat OpenSSH_7.0,OpenSSH_7.1*,OpenSSH_7.2*,OpenSSH_7.3*,OpenSSH_7.4*,OpenSSH_7.5*,OpenSSH_7.6*,OpenSSH_7.7* compat 0x04000002
debug1: Authenticating to domain.local:7999 as 'gitea'
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: curve25519-sha256
debug1: kex: host key algorithm: ecdsa-sha2-nistp256
debug1: kex: server->client cipher: chacha20-poly1305@openssh.com MAC: compression: none
debug1: kex: client->server cipher: chacha20-poly1305@openssh.com MAC: compression: none
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ecdsa-sha2-nistp256 SHA256:PkEQMVjoBj7jO+z7HT/rsryBkJ+TK00WFuiDQ7TjYmw
debug1: Host '[domain.local]:7999' is known and matches the ECDSA host key.
debug1: Found key in /home//.ssh/known_hosts:5
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: Will attempt key: /home//.ssh/id_rsa RSA SHA256:Lu4KT00G1PKNxX4PtshTNgygI7bSB1pBGQ2Nd+FM0Is agent
debug1: Will attempt key: /home//.ssh/id_dsa
debug1: Will attempt key: /home//.ssh/id_ecdsa
debug1: Will attempt key: /home//.ssh/id_ecdsa_sk
debug1: Will attempt key: /home//.ssh/id_ed25519
debug1: Will attempt key: /home//.ssh/id_ed25519_sk
debug1: Will attempt key: /home//.ssh/id_xmss
debug1: SSH2_MSG_EXT_INFO received
debug1: kex_input_ext_info: server-sig-algs=<ssh-ed25519,ssh-rsa,ssh-dss,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521>
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Offering public key: /home//.ssh/id_rsa RSA SHA256:Lu4KT00G1PKNxX4PtshTNgygI7bSB1pBGQ2Nd+FM0Is agent
debug1: Server accepts key: /home//.ssh/id_rsa RSA SHA256:Lu4KT00G1PKNxX4PtshTNgygI7bSB1pBGQ2Nd+FM0Is agent
debug1: Authentication succeeded (publickey).
Authenticated to domain.local. ([192.168.1.xx]:7999).
debug1: channel 0: new [client-session]
debug1: Requesting no-more-sessions@openssh.com
debug1: Entering interactive session.
debug1: pledge: network
debug1: client_input_global_request: rtype hostkeys-00@openssh.com want_reply 0
debug1: Remote: Forced command.
debug1: Remote: Port forwarding disabled.
debug1: Remote: X11 forwarding disabled.
debug1: Remote: Agent forwarding disabled.
debug1: Remote: PTY allocation disabled.
debug1: Remote: Forced command.
debug1: Remote: Port forwarding disabled.
debug1: Remote: X11 forwarding disabled.
debug1: Remote: Agent forwarding disabled.
debug1: Remote: PTY allocation disabled.
debug1: Sending environment.
debug1: Sending env LANG = fr_FR.UTF-8
Permission denied, please try again.
debug1: client_input_channel_req: channel 0 rtype exit-status reply 0
debug1: client_input_channel_req: channel 0 rtype eow@openssh.com reply 0
debug1: channel 0: free: client-session, nchannels 1
Transferred: sent 2848, received 3232 bytes, in 0.1 seconds
Bytes per second: sent 50033.3, received 56779.3
debug1: Exit status 1

[zeripath]

debug1: Sending env LANG = fr_FR.UTF-8
Permission denied, please try again.

That suggests that the setting of the environment variable is the problem.

Now why it should be I'm not sure.

The code for the internal SSH server is:

gitea/modules/ssh/ssh.go

Lines 151 to 188 in e4b3f35

	func Listen(host string, port int, ciphers []string, keyExchanges []string, macs []string) {
	// TODO: Handle ciphers, keyExchanges, and macs
	srv := ssh.Server{
	Addr: fmt.Sprintf("%s:%d", host, port),
	PublicKeyHandler: publicKeyHandler,
	Handler: sessionHandler,
	// We need to explicitly disable the PtyCallback so text displays
	// properly.
	PtyCallback: func(ctx ssh.Context, pty ssh.Pty) bool {
	return false
	},
	}
	keyPath := filepath.Join(setting.AppDataPath, "ssh/gogs.rsa")
	if !com.IsExist(keyPath) {
	filePath := filepath.Dir(keyPath)
	if err := os.MkdirAll(filePath, os.ModePerm); err != nil {
	log.Error("Failed to create dir %s: %v", filePath, err)
	}
	err := GenKeyPair(keyPath)
	if err != nil {
	log.Fatal("Failed to generate private key: %v", err)
	}
	log.Trace("New private key is generated: %s", keyPath)
	}
	err := srv.SetOption(ssh.HostKeyFile(keyPath))
	if err != nil {
	log.Error("Failed to set Host Key. %s", err)
	}
	go listen(&srv)
	}

And doesn't have any code that would clearly reject based on environment variables being sent - but equally doesn't have a handler for it.

If there is any way to test not sending the LANG that would be useful to confirm that this is the problem. I will take a look at the SSH dependency.

[zeripath]

Interestingly there shouldn't be any negative response against the Lang environment request:

https://github.com/gliderlabs/ssh/blob/76cadaa318fd00fe3936af0243cb5daa9df84c73/session.go#L286-L294

Implies that it just gets set - even if we ignore it at present

[zeripath]

Ok ignore my first few comments.

Could you please explain which server is intended to service SSH requests? Is it Gitea's internal SSH server or an openSSH server that is running on Synology.

Gitea can run its own SSH server or it can integrate with an already running openSSH server.

START_SSH_SERVER=true would be used to switch on the internal server and it looks from your app.ini that you were intending this but then from your comments above it looks like you're trying to set up openSSH.

Which is it?

[zeripath]

Assuming you actually intend to use openSSH get rid of the START_SSH_SRVER line in your config as it is a) incorrect b) unnecessary and c) confusing.

Now, searching for this exact bug implies that there might be some firewall rules that your Synology has.

https://www.nas-forum.com/forum/topic/56853-r%C3%A9solussh-permission-denied-connection-closed/

J'ai enlevé toutes les règles sur mon routeur, et du coup j'ai récupéré mon accès SSH :

Implying that these might be the problem but read the earlier comments in that thread in case there's something else missing.

[sebsn86]

Hi,

I tried to deactivate SSH in DSM Panel to use gitea SSH server and now, the SSH connection failed. I tried to change SSH port to :

OpenSSH_8.2p1 Ubuntu-4ubuntu0.1, OpenSSL 1.1.1f 31 Mar 2020
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 domain.local [192.168.1.33] port 7998.
debug1: connect to address 192.168.1.xx port 7998: Connection refused
ssh: connect to host domain.local port 7998: Connection refused

The Synology's Firewall is currently deactivated but it's change nothing.

[sebsn86]

I deleted the START_SSH_SERVER line too, stop and restart Gitea service, but nothing change

[sebsn86]

Here my complete app.ini file :

APP_NAME = Gitea: Näser repo
RUN_USER = gitea
RUN_MODE = prod

[oauth2]
JWT_SECRET = <hidden>
[security]
INTERNAL_TOKEN = <hidden>
INSTALL_LOCK   = true
SECRET_KEY     = <hidden>

[database]
DB_TYPE  = mysql
HOST     = 127.0.0.1:3307
NAME     = gitea
USER     = gitea
PASSWD   = xxxxxxxxx
SCHEMA   = 
SSL_MODE = disable
CHARSET  = utf8
PATH     = /usr/local/gitea/gitea/data/gitea.db

[repository]
ROOT = /usr/local/gitea/gitea/gitea-repositories

[server]
SSH_DOMAIN       = domain.local
DOMAIN           = domain.local
HTTP_PORT        = 8080
ROOT_URL         = https://domain.local/
DISABLE_SSH      = false
SSH_PORT         = 7999
LFS_START_SERVER = true
LFS_CONTENT_PATH = /usr/local/gitea/gitea/data/lfs
LFS_JWT_SECRET   = <hidden>
OFFLINE_MODE     = false
BUILTIN_SSH_SERVER_USER = 
SSH_LISTEN_PORT  = %(SSH_PORT)s
SSH_CREATE_AUTHORIZED_KEYS_FILE = true

[mailer]
ENABLED = true
HOST    = mail.infomaniak.com
FROM    = synology@domain.local
USER    = synology@domain.local
PASSWD  = xxxxxxxxxxxxxx

[service]
REGISTER_EMAIL_CONFIRM            = true
ENABLE_NOTIFY_MAIL                = true
DISABLE_REGISTRATION              = false
ALLOW_ONLY_EXTERNAL_REGISTRATION  = false
ENABLE_CAPTCHA                    = false
REQUIRE_SIGNIN_VIEW               = true
DEFAULT_KEEP_EMAIL_PRIVATE        = false
DEFAULT_ALLOW_CREATE_ORGANIZATION = true
DEFAULT_ENABLE_TIMETRACKING       = true
NO_REPLY_ADDRESS                  = noreply.localhost

[picture]
DISABLE_GRAVATAR        = false
ENABLE_FEDERATED_AVATAR = true

[openid]
ENABLE_OPENID_SIGNIN = true
ENABLE_OPENID_SIGNUP = true

[session]
PROVIDER = file

[log]
MODE      = file
LEVEL     = info
ROOT_PATH = /usr/local/gitea/gitea/log

[sebsn86]

Assuming you actually intend to use openSSH get rid of the START_SSH_SRVER line in your config as it is a) incorrect b) unnecessary and c) confusing.

Now, searching for this exact bug implies that there might be some firewall rules that your Synology has.

https://www.nas-forum.com/forum/topic/56853-r%C3%A9solussh-permission-denied-connection-closed/

J'ai enlevé toutes les règles sur mon routeur, et du coup j'ai récupéré mon accès SSH :

Implying that these might be the problem but read the earlier comments in that thread in case there's something else missing.

If I had this person's concern, the classic SSH connection should be refused too, right?

[sebsn86]

Here all files :

/var/packages/Gitea/target/gitea :

/var/packages/Gitea/target/gitea/.ssh/ :

/etc/group :

/etc/ssh/sshd_config :
config.log

/etc/passwd :

[sebsn86]

@zeripath Do you have any idea ? What have I missed ?

[sebsn86]

okay... weird !
I just restart the synology and all works perfectly !!

Thanks a lot @zeripath to helped me !