cloneLink SSH generation change #3481

New Issue

GiteaMirror · 2025-11-02T05:14:19-06:00

GiteaMirror commented

2025-11-02 05:14:19 -06:00

Originally created by @CoolGoose on GitHub (Jun 17, 2019).

Hi guys,

This isn't technically a bug, more like a discussion on the topic.
Is it ok to open a merge request for the cloneLink generation to be able to include a custom path in the url ?

Right now as a workaround I am setting up in .bashrc a cd to the repository ROOT , but I guess it would be a better option to just specify that the cloneLink url for SSH is more than SSH_DOMAIN + repo name

Originally created by @CoolGoose on GitHub (Jun 17, 2019). Hi guys, This isn't technically a bug, more like a discussion on the topic. Is it ok to open a merge request for the cloneLink generation to be able to include a custom path in the url ? Right now as a workaround I am setting up in `.bashrc` a cd to the repository `ROOT` , but I guess it would be a better option to just specify that the cloneLink url for SSH is more than SSH_DOMAIN + repo name

GiteaMirror closed this issue

2025-11-02 05:14:19 -06:00

GiteaMirror commented

2025-11-02 05:14:20 -06:00

@zeripath commented on GitHub (Jun 17, 2019):

Er... you shouldn't need to do this.

What happens if you: ssh $GITEA_USER@$GITEA_SERVER ? If you get a terminal prompt - you're not running with a key owned and managed by Gitea and you're going to have lots of problems with the repositories not updating and so on.

@zeripath commented on GitHub (Jun 17, 2019): Er... you shouldn't need to do this. What happens if you: `ssh $GITEA_USER@$GITEA_SERVER` ? If you get a terminal prompt - you're not running with a key owned and managed by Gitea and you're going to have lots of problems with the repositories not updating and so on.

GiteaMirror commented

2025-11-02 05:14:20 -06:00

@CoolGoose commented on GitHub (Jun 17, 2019):

Hi @zeripath thank you for the reply.
The things is that

I am not using gitea's own SSH server
Yes I am getting the bash prompt
Doing a clone and then a push back syncs it nicely right now, maybe it's because it's not the internal SSH ? I'll give it a try with a key as well from under the user account.

/le
It works with a new key as well, and everything seems in sync

@CoolGoose commented on GitHub (Jun 17, 2019): Hi @zeripath thank you for the reply. The things is that 1. I am not using gitea's own SSH server 2. Yes I am getting the bash prompt 3. Doing a clone and then a push back syncs it nicely right now, maybe it's because it's not the internal SSH ? I'll give it a try with a key as well from under the user account. /le It works with a new key as well, and everything seems in sync

GiteaMirror commented

2025-11-02 05:14:20 -06:00

@zeripath commented on GitHub (Jun 17, 2019):

Yeah you really must only commit to Gitea's repositories using a Gitea managed key. It shouldn't matter whether you're using openssh or the internal ssh server.

Take a look at the .ssh/authorized_keys file for the GITEA_USER and you'll see that we run a special command on login overriding the shell thus taking control of the session.

If that command doesn't run then you won't have any access control checked or protected branches checked.

@zeripath commented on GitHub (Jun 17, 2019): Yeah you really must only commit to Gitea's repositories using a Gitea managed key. It shouldn't matter whether you're using openssh or the internal ssh server. Take a look at the .ssh/authorized_keys file for the GITEA_USER and you'll see that we run a special command on login overriding the shell thus taking control of the session. If that command doesn't run then you won't have any access control checked or protected branches checked.

GiteaMirror commented

2025-11-02 05:14:21 -06:00

@CoolGoose commented on GitHub (Jun 17, 2019):

@zeripath it's clearer now (I see the entry for the custom key). So in theory one should never use the default user@ , but to go trough the authorized_keys , right ?

@CoolGoose commented on GitHub (Jun 17, 2019): @zeripath it's clearer now (I see the entry for the custom key). So in theory one should never use the default user@ , but to go trough the authorized_keys , right ?

GiteaMirror commented

2025-11-02 05:14:21 -06:00

@zeripath commented on GitHub (Jun 17, 2019):

If we can get #6961 merged then we can finally change the pre-receive hooks to enforce that people have to have the correct environment set up. (Admittedly if they have shell access they could probably just set it up themselves but at least it will barf sooner.)

@zeripath commented on GitHub (Jun 17, 2019): If we can get #6961 merged then we can finally change the pre-receive hooks to enforce that people have to have the correct environment set up. (Admittedly if they have shell access they could probably just set it up themselves but at least it will barf sooner.)

GiteaMirror commented

2025-11-02 05:14:22 -06:00

@zeripath commented on GitHub (Jun 17, 2019):

@CoolGoose yeah

@zeripath commented on GitHub (Jun 17, 2019): @CoolGoose yeah

GiteaMirror referenced this issue

2025-11-02 12:23:33 -06:00

[PR #3537] [MERGED] Add issue closed time column to fix activity closed issues list #16983

Sign in to join this conversation.