[SOLVED] Using regular Git ssh not working


#1

Hi

For some reason the SSH url that Gitea provides is wrong as in

user@192.168.5.5:user/testrepo

Well, this does not work because there is no path in ~/user/testrepo so i thought that I will just push like old the cool dudes do it

The real repo is under “/media/REPO/GIT”, so that is is also given to the git repository settings in Gitea

git clone user@192.168.5.5/media/REPO/GIT/testrepo/

I can clone the repo, add my stuff and push it back. But after I push it back, i do not see anything in the Gitea interface, it seems like it does not get the updates. I tried looking into hooks thingy but it is out of my league.

Can you help me so that I can push using regular git way?

I am using it on Debian Wheezy, git version 1.7.10.4

thanks


Wrong ssh url path
#2

Hi,

To clarify the SSH url: the stuff after the colon is for internal use in gitea. Gitea itself provides the mapping to the actual repository location.
So what you do when using the original path is bypassing gitea, which shouldn’t be possible at all!

One reason this happens is that you set your SSH key in the authorized_keys file yourself with e.g. ssh-copy-id. However that’s wrong and you should definitely let gitea handle this file.
Furthermore everytime a user adds an SSH key via gitea web-UI the authorized_keys file gets overwritten.

Another thing is that usually the user from the SSH url is git or whatever is configured in the app.ini and not the actual gitea-user itself.

The first thing you should try now is to go into the Admin settings on the gitea UI and execute:

  1. Update the ‘.ssh/authorized_keys’ file with Gitea SSH keys. (Not needed for the built-in SSH server.)
  2. Resynchronize pre-receive, update and post-receive hooks of all repositories.

After that you HAVE to set your SSH keys through gitea web-UI.

Hopefully that solves your issue!


#3

Hi

Thanks for your reply. I gained some insight but I am still not sure about what is going on here. So please bear with me while I provide more info about my setup.

I installed Gitea on an existing system that has ssh server already in place. I am also using my own existing system/login user with Gitea since I want my commits to be shown with my own user name, also helpful for the existing ssh.

my login user = MYUSER
my ssh user = MYUSER
gitea run_user = MYUSER

system git repo = /media/REPO/GIT
gitea ROOT = /media/REPO/GIT

I already added MYUSER public key in Gitea. And I see that Gitea added an extra line (at the bottom) to .ssh/authorized_keys

So I assumed that my setup is correct but like I said Gitea is not intercepting MYUSER@PC:MYUSER/TestRepo (TestRepo is created in Gitea). I tried either cloning, or pushing directly using this url but ssh cannot find the path. So I am really not sure how this is supposed to work. That is why I was trying to push to the repos directly using the standard ssh way.

You said not needed for “buit in ssh server” for not adding the ssh keys. Do you mean built in Gitea, or built in system ssh?


#4

built-in ssh server is one built into Gitea.

By looking at your comment above, you use MYUSER for multiple operations (regular use, and for running Gitea). You should run Gitea as a different user (for example Git)


#5

Hi

Thanks for the reply.

Yes I am using my user for login/git commits/gitea user .

When you say run gitea with different user do you mean running the process with different user but still use MYUSER for “RUN_USER” or do you mean something else?

The thing is that if I use with a different user, would not my commits also show up as “git” user commits?

thanks


#6

Ok here is my app config.

I also created a gitea user from scratch on the system and I still cant clone using gitea urls :frowning: I ran the command line with “sudo -u gitea ./gitea”

I added MYUSER authkey to “Deploy Key” and tried updating the hooks. No luck.

I still do not understand why I need to run this under “gitea” user. it gives me a url like gitea:192.168.2.100:/MYUSER/repo and I just cant clone it, same issue I had in the first place.

Why am I needing to ssh to a system “gitea” user, that has already MYUSER setup? if that is how it is supposed to be" Let alone it does not work for me.

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

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

[database]
DB_TYPE  = sqlite3
HOST     = 127.0.0.1:3306
NAME     = gitea
USER     = gitea
PASSWD   = 
SSL_MODE = disable
PATH     = data/gitea.db

[repository]
ROOT = /home/gitea/gitea-repositories

[server]
SSH_DOMAIN       = 192.168.2.100
DOMAIN           = 192.168.2.100
HTTP_PORT        = 3000
ROOT_URL         = http://192.168.2.100:3000/
DISABLE_SSH      = false
SSH_PORT         = 22
LFS_START_SERVER = true
LFS_CONTENT_PATH = /opt/gitea/data/lfs
LFS_JWT_SECRET   = 8-YU6LQG2Lb_cDbv5wLq8e08aC7DOEnCIf_3ZXJbGUM
OFFLINE_MODE     = false

[mailer]
ENABLED = false

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

[picture]
DISABLE_GRAVATAR        = true
ENABLE_FEDERATED_AVATAR = false

[openid]
ENABLE_OPENID_SIGNIN = false
ENABLE_OPENID_SIGNUP = false

[session]
PROVIDER = file

[log]
MODE      = file
LEVEL     = Info
ROOT_PATH = /opt/gitea/log

#7

“gitea” is defined in the ~/.ssh/config as a hostname on the pc that I am conencting from (which uses MYUSER with the same MYUSER keys on the gitea pc). I added MYUSER’s id_rsa.pub to the ssh keys in the web gui.

git clone gitea:MYUSER/testing.git                                                                                                                                                                 
Cloning into 'testing'...
gitea@192.168.2.100: Permission denied (publickey).
fatal: Could not read from remote repository.

#8

Hi sikonium,

I will try to give you a thorough explanation to the ssh configuration and the need for a seperate gitea user.

First of all: The user running gitea, the RUN_USER from app.ini and the ssh user are all the same.
The RUN_USER configuration just tells gitea that it should promote this user for its ssh clone urls as users have to connect by this special user to the server.
The only reason for this is that this user has a special ssh configuration in his authorized_keys file.
This configuration prevents users from accessing any other part on the system besides git related ones from gitea! This is especially important for security!

Because you used your own user instead of a separate one gitea only appended the public key and other vital parts in the authorized_keys file, which means your manually imported public key is on top. And that’s the problem here.
So what happens if you clone with your user is that the ssh server is granted permission to access the server because of your manually imported key and it doesn’t get to the line written by gitea.
So gitea is left out of the process.

For that reason your path behind the colon doesn’t work as gitea would be responsible for extracting the actual user of the connection and the repository bath.
But you don’t get an alert either as you obviously have established an ssh connection with your server.

The important part here to remember that not the ssh user is used to map the author of a commit but the public key added via gitea and the maintained authorized_keys file.
Also IMHO it would be insane to create a system user for each gitea user :wink:

To come to an end:
Use your MYUSER to access the server normally and create/use a separate user, favorably git for gitea.
After that you should clean up the authorized_keys file from the user MYUSER.

Best regards
daviian


#9

Hi daviian

Thanks for the detailed explanation. I appreciate that you are bveing patient with me. It is making sense now.

I actually did what you said in your reply, if you see my previous replies. Please check out the post where I pasted my app.ini I created “gitea” user and I use it to run both gitea and is also set in the app.ini.

After all that I still cant get the ssh path work.

Here is my second attempt with the special gitea user setup. Please tell me what am I missing here if you can

  • I created “gitea” user

  • I set it in the app.ini as RUN_USER (see the app.ini above)

  • I ran Gitea with “gitea” user

  • I created MYUSER as first user during initial setup

  • I added MYUSER public key in the settings

  • I created a repo

  • I go to my other pc that has a login with MYUSER, which also has the same priv key for MYUSER on Gitea pc.

  • I try to clone the repo created

    git clone gitea:MYUSER/testing.git
    Cloning into ‘testing’…
    gitea@192.168.2.100: Permission denied (publickey).
    fatal: Could not read from remote repository.


#10

Hi sikonium

You’re welcome! I hope we can solve this for you. :slight_smile:

There are now two things that come to my mind.

  1. Does the .ssh folder under /home/gitea/ have correct permissions? Normally it should be 700 and 600 for the authorized_keys file.
  2. Does your authorized_keys file only (besides commented ones) have lines starting with command="<gitea-folder>/gitea serv?
  3. Can you try your clone command with -vv and report back the output?

kind regards
daviian


#11

Hi

#1 gitea .ssh and authorized_keys are 700 and 600 respectfully

#2 I am sorry but I am confused about which authorized_key file are you talking about MYUSER or gitea? gitea user’s auth key file has 2 lines that start with “command=”/opt/gitea/gitea serv key-2 --config=’/opt/gitea/custom/conf/app.ini…’"

#3 I will try the clone command.

Here is another question, how do I properly create the authorized_keys file for gitea user? Normally I would “cat id_rsa.pub > authorized_keys” but this command would not have any custom gitea stuff in it.

thanks


#12

Yes I meant the authorized_keys file from gitea as this is the one used when cloning with gitea@host:port/user/repo.git.

This file is completely managed by gitea. You should never touch this file manually! Gitea writes to this file every time a user adds an ssh key in his user settings (on web UI) or a deploy key is added in a repository (also from web UI).

Please report the output from that command!

kind regards
daviian


#13

Hi

I am totally puzzled by this. I am really sure I did every step right

  • I deleted the authorized_keys in gitea/.ssh to make sure it is created properly. Then in my own MYUSER added my id_rsa.pub in the settings.

  • Then I check the gitea/.ssh/authorized_keys file and it was created from scratch properly like you said, with the content below

    gitea public key

    command="/opt/gitea/gitea serv key-3 --config=’/opt/gitea/custom/conf/app.ini’",no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAQCxYohck5+aKgPxTpuBkcL03nZpbotgvlVxrZfm064M/hxmMLZyJoC9OmzcnOnVbS3AB+wNcUi2ORv0asWlUAHbSjpw6vYo/9GI/znhEWB7ExvleePjXihzPOuc+H/aMDkzH2bpLkZhneXQ1CJQzH+sWRWFWf9xNddVLBS2/s0wSJsY9Otbc0iMIvv/hUNtJn3podHOhSDHW4NyhYw7e897LLnhA9NI/LLx/7jtWrM3y0fU0jLe/+NVtH9fT7zWk4YG/wRq3+yCBQNq9IdVphjMPOpFFbcvBfzP6qv3UJGGukMnTSPh2fgRCp4hMpcYlzqXFmk+iDUxnCVOE1n2ymuKq4DHBIY4ZlCBeSfh93b/Dur/ybXHuWBi8j9sjkhFimsX5PKM0TMroghqzZbXTrlpXdI2XbXdrINNSKitKv4DQvedxe0GCvbLZmtgbIrFrtjfe374iTPhskmHqhkyh5c8WzPGjFOirTifmvmawjpyXlD4Xsysr5ExmKGQeEnuF1pv+kyBTPmyI6YMxrc5MmM0WpzFI4g8OcHnbvzR6U/RDMnbxAN3LyY09TvVl8QtTAeCiKO2NPDba0LX3Fp2l6BAo5PXnsgOSJnYx02LxXdCpy/6yzhMX+DXS0PX9bE/wIkyrHJ4W+0/MPMbOSnK4vypffddOgSSeWi8PPB40wCY/Q== MYUSER@gc

    gitea public key

    command="/opt/gitea/gitea serv key-3 --config=’/opt/gitea/custom/conf/app.ini’",no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAQCxYohck5+aKgPxTpuBkcL03nZpbotgvlVxrZfm064M/hxmMLZyJoC9OmzcnOnVbS3AB+wNcUi2ORv0asWlUAHbSjpw6vYo/9GI/znhEWB7ExvleePjXihzPOuc+H/aMDkzH2bpLkZhneXQ1CJQzH+sWRWFWf9xNddVLBS2/s0wSJsY9Otbc0iMIvv/hUNtJn3podHOhSDHW4NyhYw7e897LLnhA9NI/LLx/7jtWrM3y0fU0jLe/+NVtH9fT7zWk4YG/wRq3+yCBQNq9IdVphjMPOpFFbcvBfzP6qv3UJGGukMnTSPh2fgRCp4hMpcYlzqXFmk+iDUxnCVOE1n2ymuKq4DHBIY4ZlCBeSfh93b/Dur/ybXHuWBi8j9sjkhFimsX5PKM0TMroghqzZbXTrlpXdI2XbXdrINNSKitKv4DQvedxe0GCvbLZmtgbIrFrtjfe374iTPhskmHqhkyh5c8WzPGjFOirTifmvmawjpyXlD4Xsysr5ExmKGQeEnuF1pv+kyBTPmyI6YMxrc5MmM0WpzFI4g8OcHnbvzR6U/RDMnbxAN3LyY09TvVl8QtTAeCiKO2NPDba0LX3Fp2l6BAo5PXnsgOSJnYx02LxXdCpy/6yzhMX+DXS0PX9bE/wIkyrHJ4W+0/MPMbOSnK4vypffddOgSSeWi8PPB40wCY/Q== MYUSER@gc

  • I tried to clone with the settings above

      git clone -vv gitea@192.168.2.100:MYUSER/testrepo.git                                                                                                                                                      ⏎
      Cloning into 'testrepo'...
      gitea@192.168.2.100: Permission denied (publickey).
      fatal: Could not read from remote repository.
    
      Please make sure you have the correct access rights
    
  • Then I saw that both keys in the auth key for both lines were same, then I thought maybe I should add giteas’s own id_rsa.pub in Gitea by logging in as gitea user add its own pub key first which I did. Then I added MYUSER’s pub key after logging in as MYUSER to Gitea. The result

    gitea public key

    command="/opt/gitea/gitea serv key-4 --config=’/opt/gitea/custom/conf/app.ini’",no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDO2oGmDu2ephhy7y7g2rDV7z4Jhh6AoheezntVNGDl3g09xNAtsg3ByMYGGUY6e6iRxo2jS9Hav0WdoGDxZMx6j4FQfaW9po9o9zLDMGw1i/vbtAeSGhOSolfZ20WSupR0yeyEZARGzbUJKwWbPPfiAQd9dQTpBo1tc3NU0cpjKfqLjUXNsBLrXF9dzJX7VagJQoCamJoSHPU7DbM7PhKY1//AeJNiv0dK9bdtg6uu6ZrhZESuQqRKDQs2KMdAHI6Dvfx2lE+kZUA2xkywSD4SjLSS5T6Q0l0iealGu5eiDV69+okxEdHuJsNwGICXhwpbQV6T7KH/FW4e6DQKuoFN gitea@GITEAPC

    gitea public key

    command="/opt/gitea/gitea serv key-5 --config=’/opt/gitea/custom/conf/app.ini’",no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAQCxYohck5+aKgPxTpuBkcL03nZpbotgvlVxrZfm064M/hxmMLZyJoC9OmzcnOnVbS3AB+wNcUi2ORv0asWlUAHbSjpw6vYo/9GI/znhEWB7ExvleePjXihzPOuc+H/aMDkzH2bpLkZhneXQ1CJQzH+sWRWFWf9xNddVLBS2/s0wSJsY9Otbc0iMIvv/hUNtJn3podHOhSDHW4NyhYw7e897LLnhA9NI/LLx/7jtWrM3y0fU0jLe/+NVtH9fT7zWk4YG/wRq3+yCBQNq9IdVphjMPOpFFbcvBfzP6qv3UJGGukMnTSPh2fgRCp4hMpcYlzqXFmk+iDUxnCVOE1n2ymuKq4DHBIY4ZlCBeSfh93b/Dur/ybXHuWBi8j9sjkhFimsX5PKM0TMroghqzZbXTrlpXdI2XbXdrINNSKitKv4DQvedxe0GCvbLZmtgbIrFrtjfe374iTPhskmHqhkyh5c8WzPGjFOirTifmvmawjpyXlD4Xsysr5ExmKGQeEnuF1pv+kyBTPmyI6YMxrc5MmM0WpzFI4g8OcHnbvzR6U/RDMnbxAN3LyY09TvVl8QtTAeCiKO2NPDba0LX3Fp2l6BAo5PXnsgOSJnYx02LxXdCpy/6yzhMX+DXS0PX9bE/wIkyrHJ4W+0/MPMbOSnK4vypffddOgSSeWi8PPB40wCY/Q== MYUSER@gc

  • Then I tried to clone

      git clone -vv gitea@192.168.2.100:MYUSER/testrepo.git                                                                                                                                                      ⏎
      Cloning into 'testrepo'...
      gitea@192.168.2.100: Permission denied (publickey).
      fatal: Could not read from remote repository.
    
      Please make sure you have the correct access rights
    
  • I also deleted the authorized keys one last time and used “Update the ‘.ssh/authorized_keys’ file with Gitea SSH keys. (Not needed for the built-in SSH server.)” setting, which created the auth key again. But that did not help with cloning too.

Not much progress there. :frowning:

Also /home/gitea/gitea-repositories/MYUSER/testrepo.git exists with

drwxr-xr-x 7 gitea gitea 4.0K May 19 13:41 testrepo.git

Btw http cloning works.

My App.ini
https://paste.debian.net/hidden/ff8702ad/


#14

In Gitea Admin Panel, run rewrite all public SSH keys. And remember backup your old public SSH keys.


#15

Thanks but I cant find that option anywhere.

If you meant “Update the ‘.ssh/authorized_keys’ file with Gitea SSH keys. (Not needed for the built-in SSH server.)” I already done that which I tried to explain in my long post above.

thanks


#16

This is driving me nuts :frowning: Can someone tell me the basic steps for creating the proper authorized_keys for the “gitea” user (both process runner and an admin user)?

  • I deleted everything.

  • I added “gitea” as the admin user

  • I created “MYUSER” via “gitea” admin priv

  • I logged in as MYUSER

  • I added my ssh pub key

  • I logged back as gitea

  • I ran “Update the ‘.ssh/authorized_keys’ file with Gitea SSH keys”

I then checked the authorized_keys file under /home/gitea/.ssh/ and there is only one line of keyfile and that is for “MYUSER”.

You guys are saying that I should not touch the authorized_keys myself, fine but it does not seem like its adding its own “gitea” user s pub key to the auth keys file since that is not happening, it is failing to connect during ssh cloning :frowning:


#17

Ok, I am crying at the moment, I am so mad at this after so many days I cant make it work. I even tried it with a totally new fresh instal with “git” user.

I quit, unless someone is willing to baby step me with the process from scratch. This is so much time wasting for me :frowning:

EDIT

After failing for days, I thought that maybe it was my old Debian Wheezy causing all this crap. I installed it on Debian Testing and it WORKS. IT just works. I f@ckin wasted days on trying to install it on an older system :frowning:

I wonder if there are issues with i386 builds and older Linux systems,


#18

I’m glad it’s finally working. It was driving me crazy too :joy:

One small thing though, but don’t let me confuse you.
You don’t have to create a ‘gitea’ user inside of ‘gitea’. Just as a user on the host system gitea is running.
And this step can be even omitted if you simply use the ‘git’ user created for you when installing the git package on debian.

Maybe the fresh debian installation “fixed” some weird users stuff.
Another possibility that’s now coming to my mind is that your linux user had not login shell, which is required.

But congrats it is working now!


#19

@daviian

The install on Debian Testing took me like 2 mins which were the exact steps I took on Debian Wheezy. It did not work on Debian Wheezy no matter what I tried.

Thanks for clarifying the gitea user thing, I actually was confused about that too, I created actual gitea user for Gitea as well.

Anyway, thanks for helping out, I guess I was a victim of some old system setup. It looks like I never needed to try much of anything to get this working. I wonder this has some todo with ssh version/git version/bash version.


#20