Skip to content

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

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
2 of 7 tasks
sebsn86 opened this issue Sep 7, 2020 · 12 comments
Closed
2 of 7 tasks

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

sebsn86 opened this issue Sep 7, 2020 · 12 comments

Comments

@sebsn86
Copy link

sebsn86 commented Sep 7, 2020

  • 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://[email protected]: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
Copy link
Author

sebsn86 commented Sep 8, 2020

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: [email protected] MAC: compression: none
debug1: kex: client->server cipher: [email protected] 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 [email protected]
debug1: Entering interactive session.
debug1: pledge: network
debug1: client_input_global_request: rtype [email protected] 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 [email protected] 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

This comment has been minimized.

@zeripath

This comment has been minimized.

@zeripath
Copy link
Contributor

zeripath commented Sep 8, 2020

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 zeripath closed this as completed Sep 8, 2020
@zeripath zeripath reopened this Sep 8, 2020
@zeripath
Copy link
Contributor

zeripath commented Sep 8, 2020

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
Copy link
Author

sebsn86 commented Sep 8, 2020

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
Copy link
Author

sebsn86 commented Sep 8, 2020

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

@sebsn86
Copy link
Author

sebsn86 commented Sep 8, 2020

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    = [email protected]
USER    = [email protected]
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
Copy link
Author

sebsn86 commented Sep 8, 2020

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
Copy link
Author

sebsn86 commented Sep 8, 2020

Here all files :

/var/packages/Gitea/target/gitea :
permission-ssh-folder

/var/packages/Gitea/target/gitea/.ssh/ :
permission-authorized-keys

/etc/group :
synology-administrator-group

/etc/ssh/sshd_config :
config.log

/etc/passwd :
synology-passwd

@sebsn86
Copy link
Author

sebsn86 commented Sep 8, 2020

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

@sebsn86
Copy link
Author

sebsn86 commented Sep 8, 2020

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

Thanks a lot @zeripath to helped me !

@sebsn86 sebsn86 closed this as completed Sep 8, 2020
@go-gitea go-gitea locked and limited conversation to collaborators Nov 24, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants