github-starred/gitea
2
0
Fork 0
mirror of https://github.com/go-gitea/gitea.git synced 2026-03-12 02:24:21 -05:00
Code Issues 2.6k Packages Projects Releases 100 Wiki Activity

Impossible to pull / push via ssh gitea #2639

New Issue
Closed
opened 2025-11-02 04:43:03 -06:00 by GiteaMirror · 12 comments
GiteaMirror commented 2025-11-02 04:43:03 -06:00
Owner
Copy Link

Originally created by @ghost on GitHub (Dec 8, 2018).

  • 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
    • MySQL
    • MSSQL
    • SQLite
  • Can you reproduce the bug at https://try.gitea.io:
    • Yes (provide example URL)
    • No
    • Not relevant
  • Log gist:

Description

Installed Gitea on NAS Synology DS918+

When I want to clone a repository:

git clone gitea@git.my_domain.ru:vlad.bitrix/layout.git
Cloning into 'layout'...
gitea@git.my_domain.ru's password:
Permission denied, please try again.
gitea@git.my_domain.ru's password:
gitea@git.my_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: 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: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=<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: 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
vladbaranov@git.my_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

Originally created by @ghost on GitHub (Dec 8, 2018). <!-- 1. Please speak English, this is the language all of us can speak and write. 2. Please ask questions or configuration/deploy problems on our Discord server (https://discord.gg/NsatcWJ) or forum (https://discourse.gitea.io). 3. Please take a moment to check that your issue doesn't already exist. 4. Please give all relevant information below for bug reports, because incomplete details will be handled as an invalid report. --> - 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 gitea@git.my_domain.ru:vlad.bitrix/layout.git Cloning into 'layout'... gitea@git.my_domain.ru's password: Permission denied, please try again. gitea@git.my_domain.ru's password: gitea@git.my_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: 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: 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=<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: 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 vladbaranov@git.my_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 4. Rights to /usr/local/gitea/gitea/.ssh (700) and /usr/local/gitea/gitea/.ssh/authorized_keys (600) 5. Run - Update the '.ssh/authorized_keys' file with Gitea SSH keys. (Not needed for the built-in SSH server.) 6. Run - Resynchronize pre-receive, update and post-receive hooks of all repositories. 7. 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 <!-- **If this issue involves the Web Interface, please include a screenshot** -->
GiteaMirror added the type/question label 2025-11-02 04:43:03 -06:00
GiteaMirror commented 2025-11-02 04:43:04 -06:00
Author
Owner
Copy Link

@lunny commented on GitHub (Dec 9, 2018):

Check your publickey permission or .ssh permission settings.

@lunny commented on GitHub (Dec 9, 2018): Check your `publickey` permission or `.ssh` permission settings.
GiteaMirror commented 2025-11-02 04:43:04 -06:00
Author
Owner
Copy Link

@ghost commented on GitHub (Dec 10, 2018):

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

rights to the .ssh 700 folder and to author_keys 600

@ghost commented on GitHub (Dec 10, 2018): > Проверьте свое `publickey`разрешение или `.ssh`настройки разрешения. rights to the .ssh 700 folder and to author_keys 600
GiteaMirror commented 2025-11-02 04:43:04 -06:00
Author
Owner
Copy Link

@ghost commented on GitHub (Dec 10, 2018):

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

@ghost commented on GitHub (Dec 10, 2018): if I enter the password my Gitea account, then all the same nothing works, although the password is correct.
GiteaMirror commented 2025-11-02 04:43:05 -06:00
Author
Owner
Copy Link

@aphroteus commented on GitHub (Dec 20, 2018):

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://gitea@git.my_domain.ru:22/vlad.bitrix/layout.git

@aphroteus commented on GitHub (Dec 20, 2018): 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://gitea@git.my_domain.ru:22/vlad.bitrix/layout.git
GiteaMirror commented 2025-11-02 04:43:05 -06:00
Author
Owner
Copy Link

@zeripath commented on GitHub (Dec 20, 2018):

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.

@zeripath commented on GitHub (Dec 20, 2018): 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.
GiteaMirror commented 2025-11-02 04:43:05 -06:00
Author
Owner
Copy Link

@alsmnn commented on GitHub (Jan 14, 2019):

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

@alsmnn commented on GitHub (Jan 14, 2019): 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
GiteaMirror commented 2025-11-02 04:43:05 -06:00
Author
Owner
Copy Link

@zeripath commented on GitHub (Jan 14, 2019):

@ghost does this solve your issue?

@zeripath commented on GitHub (Jan 14, 2019): @ghost does this solve your issue?
GiteaMirror commented 2025-11-02 04:43:06 -06:00
Author
Owner
Copy Link

@lunny commented on GitHub (Jan 14, 2019):

@zeripath that account has been deleted I think.

@lunny commented on GitHub (Jan 14, 2019): @zeripath that account has been deleted I think.
GiteaMirror commented 2025-11-02 04:43:06 -06:00
Author
Owner
Copy Link

@zeripath commented on GitHub (Jan 14, 2019):

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 commented on GitHub (Jan 14, 2019): 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)
GiteaMirror commented 2025-11-02 04:43:06 -06:00
Author
Owner
Copy Link

@zeripath commented on GitHub (Jan 14, 2019):

@lunny otherwise I think we close this issue.

@zeripath commented on GitHub (Jan 14, 2019): @lunny otherwise I think we close this issue.
GiteaMirror commented 2025-11-02 04:43:06 -06:00
Author
Owner
Copy Link

@alsmnn commented on GitHub (Jan 14, 2019):

@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.

@alsmnn commented on GitHub (Jan 14, 2019): @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.
GiteaMirror commented 2025-11-02 04:43:07 -06:00
Author
Owner
Copy Link

@johannesrauch commented on GitHub (Mar 18, 2020):

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: 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: 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 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 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 eow@openssh.com 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.

@johannesrauch commented on GitHub (Mar 18, 2020): 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](https://unix.stackexchange.com/questions/36540/why-am-i-still-getting-a-password-prompt-with-ssh-with-public-key-authentication) 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: 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: 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 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 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 eow@openssh.com 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.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
$20
$250
$50
$500
backport/done
💎 Bounty
docs-update-needed
good first issue
hacktoberfest
issue/bounty
issue/confirmed
issue/critical
issue/duplicate
issue/needs-feedback
issue/not-a-bug
issue/regression
issue/stale
issue/workaround
lgtm/need 2
modifies/api
modifies/translation
outdated/backport/v1.18
outdated/theme/markdown
outdated/theme/timetracker
performance/bigrepo
performance/cpu
performance/memory
performance/speed
pr/breaking
proposal/accepted
proposal/rejected
pr/wip
pull-request
Mirrored from GitHub Pull Request
 reviewed/wontfix
💰 Rewarded
skip-changelog
status/blocked
topic/accessibility
topic/api
topic/authentication
topic/build
topic/code-linting
topic/commit-signing
topic/content-rendering
topic/deployment
topic/distribution
topic/federation
topic/gitea-actions
topic/issues
topic/lfs
topic/mobile
topic/moderation
topic/packages
topic/pr
topic/projects
topic/repo
topic/repo-migration
topic/security
topic/theme
topic/ui
topic/ui-interaction
topic/ux
topic/webhooks
topic/wiki
type/bug
type/deprecation
type/docs
type/enhancement
type/feature
type/miscellaneous
type/proposal
type/question
type/refactoring
type/summary
type/testing
type/upstream
No Label type/question
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
GiteaMirror ninjasurge
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/gitea#2639
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?