Add information on how to activate git ssh connection

[d-ahrens]

I used your script some days ago and set up gitea 1.2.0rc2.

I had to manually edit the config file because the automatic path for the .ssh user folder was wrong. It pointed to "/usr/local/gitea/gitea/.ssh" (the package folder) instead of "/usr/local/gitea/.ssh" (the user folder).

sudo vi /usr/local/gitea/gitea/custom/conf/app.ini insert at the bottom of the [server] section SSH_ROOT_PATH=/usr/local/gitea/.ssh

And i also had to edit the "/etc/passwd" file to allow login for the gitea user.

sudo vi /etc/passwd old: gitea: ... :/var/packages/Gitea/target:/sbin/nologin new: gitea: ... :/var/packages/Gitea/target:/bin/sh

But some security function or whatever seems to overwrite the passwd file from time to time so i need to do this change again. I'm trying to figure out why this happens.

Maybe you can include these two steps in the description.

[ahahn94]

How did you get Gitea to load the modified config file? Restarting the package via the package center as well as restarting the whole NAS did not reload the config file... I am using version 1.4.0...

[symgryph]

See wiki. It bypasses the ssh madness completely by using built-in ssh server on a non-privilaged port.

[Kasurus]

The solution in the first post worked perfectly fine for me, but i also had to use the re-write „.ssh/authorized_keys“ option from the admin Dashboard.

[approximate]

Hi, I am trying to follow the solution from the first post, but sshd does not seem to let my gitea user in. HTTPS works just fine.

What I did so far:

• uploaded a working SSH key via GUI (tested via copy/pasting into ~/.ssh/authorized_keys for a normal user and trying to ssh as that user)
• created a ~gitea/.ssh symlink pointing to the Gitea-managed .ssh directory (usually ~gitea/gitea/.ssh)
• added gitea user to administrators group using synogroup --member administrators admin gitea
• restarted sshd a bunch of times
• replaced gitea user's shell with /bin/sh

What does not work:

• normal SSH login as gitea using either password (which is not known and cannot be set for internal users) or SSH keys
• running a command instead of dropping into shell: i tried ssh [email protected] /bin/id with that command set up in authorized_keys analogous to how Gitea does it.
• git clone, obviously

What irks me is that I can see in 'ssh -v [email protected]` log that the authentication seems to work (see the first line without debug1 prefix) , but anythign else still doesn't work:

debug1: Authentications that can continue: publickey,password                         
debug1: Next authentication method: publickey                                         
debug1: Offering RSA public key: /home/knze/.ssh/id_rsa                               
debug1: Server accepts key: pkalg ssh-rsa blen 279                                    
debug1: Enabling compression at level 6.                                              
debug1: Authentication succeeded (publickey).                                         
Authenticated to diskstation.local ([192.168.1.2]:22).                                      
debug1: setting up multiplex master socket                                            
debug1: channel 0: new [/home/knze/.ssh/ctrl]                                         
debug1: channel 1: new [client-session]                                               
debug1: Entering interactive session.                                                 
debug1: pledge: id                                                                    
debug1: client_input_global_request: rtype [email protected] want_reply 0       
debug1: Sending environment.                                                          
debug1: Sending env LANG = en_US.UTF-8                                                
debug1: Sending command: /bin/id                                                      
Permission denied, please try again.                                                  

I slowly develop a feeling that the gitea user somehow is not allowed to do anything using SSH, but I can't put my finger on it. Something Synology-specific perhaps?

Any ideas?

PS: I would much rather have Gitea listen on a normal SSH port 22, and don't want to go the custom port route as long as I have other options. The advice in the wiki will be my nuclear option if I won't manage to make normal SSH work.

[crf8472]

I have a similar (or in fact the same) problem with SSH.

I altered the login shell for user 'gitea' to /bin/sh to ensure that user gitea can call the binary and perform the git actions via SSH. Motivation is to use the SSH-URLs as provided by Gitea.

Whenever I do a

$ git clone gitea@MyOrga:myrepo.git

user 'gitea' succeeds in establishing the SSH connection with every of the authorized_keys from the Gitea application users. The interception by Gitea seems to work and the right repository is picked. But on the actual git operation I get a 'Permission denied' when trying to do a git-receive-pack or git-upload-pack.

I would like to try whether this problem can be solved by granting user 'gitea' permission to use the 'Git Server' package. (It seems, only users explicitly permitted in the allowlist of the Git Server package can actually perform git actions?)

However, being a "Package User", 'gitea' does not show up in the permission list of the Git Server package. I have no idea how to grant the relevant permission to 'gitea'. Can anyone help?

EDIT: It was not correct to use the git-shell as login shell since user gitea has to call the gitea binary while git-shell can only execute git actions.