Gitea: Impossible to pull / push via ssh gitea

[ghost]

• Gitea version (or commit ref): 1.6.0 built with: bindata, sqlite
• Git version: 2.17.1
• Operating system: Linux version 4.4.59+
• Database (use [x]):
  
  
  
  • [ ] PostgreSQL
  
  
  • [x] MySQL
  
  
  • [ ] MSSQL
  
  
  • [ ] SQLite
  
  
• Can you reproduce the bug at https://try.gitea.io:
  
  
  
  • [ ] Yes (provide example URL)
  
  
  • [x] No
  
  
  • [ ] Not relevant
  
  
• Log gist:

Description

Installed Gitea on NAS Synology DS918+

When I want to clone a repository:

git clone [email protected]_domain.ru:vlad.bitrix/layout.git
Cloning into 'layout'...
[email protected]_domain.ru's password:
Permission denied, please try again.
[email protected]_domain.ru's password:
[email protected]_domain.ru: Permission denied (publickey,password).
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.

If you use HTTPS:

git clone https://git.my_domain.ru:3000/vlad.bitrix/layout.git
Cloning into 'layout'...
remote: Counting objects: 2127, done.
remote: Compressing objects: 100% (650/650), done.
remote: Total 2127 (delta 1433), reused 2127 (delta 1433)
Receiving objects: 100% (2127/2127), 5.00 MiB | 7.46 MiB/s, done.
Resolving deltas: 100% (1433/1433), done.
iMac-Vlad-2:test vladbaranov$

Everything works successfully!

if you enter: ssh -v git.my_domain.ru

OpenSSH_7.6p1, LibreSSL 2.6.2
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 48: Applying options for *
debug1: Connecting to git.my_domain.ru port 22.
debug1: Connection established.
debug1: identity file /Users/vladbaranov/.ssh/id_rsa type 0
debug1: key_load_public: No such file or directory
debug1: identity file /Users/vladbaranov/.ssh/id_rsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /Users/vladbaranov/.ssh/id_dsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /Users/vladbaranov/.ssh/id_dsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /Users/vladbaranov/.ssh/id_ecdsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /Users/vladbaranov/.ssh/id_ecdsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /Users/vladbaranov/.ssh/id_ed25519 type -1
debug1: key_load_public: No such file or directory
debug1: identity file /Users/vladbaranov/.ssh/id_ed25519-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_7.6
debug1: Remote protocol version 2.0, remote software version OpenSSH_7.4
debug1: match: OpenSSH_7.4 pat OpenSSH* compat 0x04000000
debug1: Authenticating to git.my_domain.ru:22 as 'vladbaranov'
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:RocgmrS0uNfyudnDDcWDdJrgsNhKEkd5Ans9bW0rAXTn4
debug1: Host 'git.my_domain.ru' is known and matches the ECDSA host key.
debug1: Found key in /Users/vladbaranov/.ssh/known_hosts:21
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_EXT_INFO received
debug1: kex_input_ext_info: server-sig-algs=
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Offering public key: RSA SHA256:sosF7LQODaGgdfjqwfDOpdCgaRGs4Ylva3WuygFc/Ioapk /Users/vladbaranov/.ssh/id_rsa
debug1: Authentications that can continue: publickey,password
debug1: Trying private key: /Users/vladbaranov/.ssh/id_dsa
debug1: Trying private key: /Users/vladbaranov/.ssh/id_ecdsa
debug1: Trying private key: /Users/vladbaranov/.ssh/id_ed25519
debug1: Next authentication method: password
[email protected]_domain.ru's password:

How I installed Gitea:

1. Create a file SPK https://github.com/flipswitchingmonkey/gitea-spk (version gitea-1.6.0-linux-amd64)
2. Installed on Synology http://joxi.ru/Grq7BL5UQMpOn2. Installation was successful.
3. File app.ini:

APP_NAME = Gitea: Git with a cup of tea
RUN_USER = gitea
RUN_MODE = prod

[security]
INTERNAL_TOKEN = xxxxxxxxxxx
INSTALL_LOCK = true
SECRET_KEY = xxxxxxxxxxx

[database]
DB_TYPE = mysql
HOST = 127.0.0.1:3307
NAME = gitea
USER = gitea
PASSWD = my_pass
SSL_MODE = disable
PATH = data/gitea.db

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

[server]
SSH_DOMAIN = git.my_domain.ru
DOMAIN = git.my_domain.ru
HTTP_PORT = 3000
ROOT_URL = https://git.my_domain.ru:3000/
DISABLE_SSH = false
SSH_PORT = 22
LFS_START_SERVER = true
LFS_CONTENT_PATH = /usr/local/gitea/gitea/data/lfs
LFS_JWT_SECRET = xxxxxxxxx
OFFLINE_MODE = false
PROTOCOL = https
CERT_FILE = /usr/local/gitea/gitea/custom/https/cert.pem
KEY_FILE = /usr/local/gitea/gitea/custom/https/key.pem

[mailer]
ENABLED = true
HOST = mail.my_domain.ru:587
FROM = office@my_domain.ru
USER = my_login
PASSWD = my_pass

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

[picture]
DISABLE_GRAVATAR = false
ENABLE_FEDERATED_AVATAR = false

[openid]
ENABLE_OPENID_SIGNIN = true
ENABLE_OPENID_SIGNUP = true

[session]
PROVIDER = file

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

1. Rights to /usr/local/gitea/gitea/.ssh (700) and /usr/local/gitea/gitea/.ssh/authorized_keys (600)
2. Run - Update the '.ssh/authorized_keys' file with Gitea SSH keys. (Not needed for the built-in SSH server.)
3. Run - Resynchronize pre-receive, update and post-receive hooks of all repositories.
4. SSH-key installed http://joxi.ru/J2bWX1jIXa3OeA

Help please understand, for 2 days I can not understand why it does not work on SSH and works on HTTPS.
...

Screenshots

[lunny]

Check your publickey permission or .ssh permission settings.

[ghost]

Проверьте свое publickeyразрешение или .sshнастройки разрешения.

rights to the .ssh 700 folder and to author_keys 600

[ghost]

if I enter the password my Gitea account, then all the same nothing works, although the password is correct.

[aphroteus]

Would you add below setting at section [server] of app.ini
START_SSH_SERVER = true

After apply above setting, restart gitea service, and try again in below command in git bash
git clone ssh://[email protected]_domain.ru:22/vlad.bitrix/layout.git

[zeripath]

Ok, I'm assuming you have actually got openssh or some external (to gitea) SSH server running. You won't be able to run the internal SSH server on port 22 unless you have specifically allowed gitea to open that port as it's under 1000. If you want to use the internal SSH server you need to set the port to something higher like 2222.

Now, assuming you're using openssh externally, where is the gitea user's home directory? You imply that it's /usr/local/gitea/gitea is that actually correct? Check /etc/passwd.

Is it possible to actually login as the gitea user? What is the shell at the end of the gitea line in /etc/passwd? If it's /bin/false or /usr/sbin/nologin that's your problem. You need to have gitea have a normal shell, the .ssh/authorized_keys will take care of ensuring only reasonable users get logged in and get a restricted shell.

Gitea needs to own the .ssh directory and the repositories. Make sure it does. Make sure you're actually running gitea under the gitea user.

Hope this helps.

[alsmnn]

I stumbled across the same problem and for me this worked:

After installing gitea on the Synology, the user gitea will be added. The home directory of the gitea user is /var/packages/Gitea/target/gitea , but in /etc/passwd it is /var/packages/Gitea/target. If you change this to the correct folder, everything works flawlessly.

Best regards,
Aljoscha

[zeripath]

@ghost does this solve your issue?

[lunny]

@zeripath that account has been deleted I think.

[zeripath]

D'oh.

Ok, so in terms of resolving this issue - do we think there's anything Gitea can do here?

I mean it's extremely odd that there's a system out there with a different $HOME than the one in /etc/passed. Perhaps it just needs a documentation PR?

@AljoLe would you be able to send a documentation PR? Perhaps based in the troubleshooting section (I hope one exists)

[zeripath]

@lunny otherwise I think we close this issue.

[alsmnn]

@zeripath I never did a PR before, but there's a first time for anything, right?
The $HOME of all other users on the synology system are in /var/services/homes/, only the gitea´s $HOME is in /var/packages/Gitea/target/gitea.
This is a specialty of the Synology system, so I think a hint in the docs would be nice and enough.

[moxxio]

I have the same setup as the deleted ghost users has and I encountered exactly the same problem. (I also followed the same installation process.) The SSH server denies my permission when authenticating by pubkey (and then prompts a password). The verbose SSH output is analogous. Unfortunately the actions described by @alsmnn did not solve the problem. Everything works fine except the pubkey authenticated SSH-login with the user gitea. Note that I can SSH into my NAS on every other user.

Like @alsmnn mentioned, the user directory for gitea is in /var/packages/Gitea/target/gitea. Here is what I have done so far:

• I ran Update the '.ssh/authorized_keys' file with Gitea SSH keys. (Not needed for the built-in SSH server.) and Resynchronize pre-receive, update and post-receive hooks of all repositories..
• I checked the file permissions in /var/packages/Gitea/target/gitea. The folder .ssh is owned by gitea (group is also gitea) with permissions 700. The file authorized_keys is owned by gitea (group is also gitea) with permissions 600.
• I appended /gitea to the gitea home path in /etc/passwd.
• I changed the shell in /etc/passwd from /sbin/nologin to bin/sh.
• I checked whether PubkeyAuthentication is enabled in /etc/sshd_config.
  But the server still rejects a SSH connection with gitea as above.

My guess is that this is some SSH server setup issue. Somehow SSH does not find the authorized_keys for the user gitea. But I have no idea what measures I can try next. Any help is appreciated :)

EDIT 1
A tip from here mentioned changing the permissions of the home directory to 744. Now the SSH server actually accepts the authentication but I still get permission denied. So it is some sort of file/folder permission problem.

The log output:

user@pc:~$ ssh -v -T -l gitea -p 5022 my.domain.com
OpenSSH_7.6p1 Ubuntu-4ubuntu0.3, OpenSSL 1.0.2n  7 Dec 2017
debug1: Reading configuration data /home/user/.ssh/config
debug1: /home/user/.ssh/config line 7: Applying options for my.domain.com
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: Connecting to my.domain.com [xxx.xxx.xxx.xxx] port 5022.
debug1: Connection established.
debug1: identity file /home/user/.ssh/id_file type 0
debug1: key_load_public: No such file or directory
debug1: identity file /home/user/.ssh/id_file-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_7.6p1 Ubuntu-4ubuntu0.3
debug1: Remote protocol version 2.0, remote software version OpenSSH_7.4
debug1: match: OpenSSH_7.4 pat OpenSSH* compat 0x04000000
debug1: Authenticating to my.domain.com:5022 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: <implicit> compression: none
debug1: kex: client->server cipher: [email protected] MAC: <implicit> compression: none
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ecdsa-sha2-nistp256 SHA256:ftvSb5conKTG7Ba2ZUpCcEqnlN8o7dGWxZJ6KYZ4klY
debug1: Host '[my.domain.com]:5022' is known and matches the ECDSA host key.
debug1: Found key in /home/user/.ssh/known_hosts:1
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: rekey after 134217728 blocks
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
debug1: Next authentication method: publickey
debug1: Offering public key: RSA SHA256:OXUhb...ZA8Ic /home/user/.ssh/id_file
debug1: Server accepts key: pkalg ssh-rsa blen 279
Enter passphrase for key '/home/user/.ssh/id_file': 
debug1: Authentication succeeded (publickey).
Authenticated to my.domain.com ([xxx.xxx.xxx.xxx]:5022).
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 LC_MEASUREMENT = de_DE.UTF-8
debug1: Sending env LC_PAPER = de_DE.UTF-8
debug1: Sending env LC_MONETARY = de_DE.UTF-8
debug1: Sending env LANG = en_US.UTF-8
debug1: Sending env LC_NAME = de_DE.UTF-8
debug1: Sending env LC_ADDRESS = de_DE.UTF-8
debug1: Sending env LC_NUMERIC = de_DE.UTF-8
debug1: Sending env LC_TELEPHONE = de_DE.UTF-8
debug1: Sending env LC_IDENTIFICATION = de_DE.UTF-8
debug1: Sending env LC_TIME = de_DE.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 3188, received 3464 bytes, in 0.2 seconds
Bytes per second: sent 16461.1, received 17886.2
debug1: Exit status 1

EDIT 2
I solved the problem. During trying things out and restarting the SSH server with the DSM of my NAS, I stumbled over the information that SSH logins are only supported from users belonging to the administrators group. (Apparently this is a security feature of Synology.) I appended gitea to the administrators group in /etc/group and it worked.

I hope this helps other users running a gitea server on their Synology NAS.