Feature Request: modified authorized keys #3709

New Issue

GiteaMirror · 2025-11-02T05:22:33-06:00

GiteaMirror commented

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

Originally created by @927589452 on GitHub (Aug 1, 2019).

Description

Add an option to modify, what is written to the authorized_keys, so gitea can be used with the same key, which is also used for accessing the server.
An example for such a modification is this

command="if [ -t 0 ]; then bash; elif [[ $SSH_ORIGINAL_COMMAND =~ ^(scp|rsync|mysqldump).* ]]; then eval $SSH_ORIGINAL_COMMAND; else /home/<username>/gitea/gitea serv key-1 --config='/home/<username>/gitea/custom/conf/app.ini'; fi",no-port-forwarding,no-X11-forwarding,no-agent-forwarding ssh-...

this is useful for shared hosting scenarios like the guide by @luto, where i copied this line from.

I would imagine an option
SSH_RESTRICT: %(giteacmd)s
and used like this
SSH_RESTRICT: if [ -t 0 ]; then bash; elif rsync; then eval $SSH_ORIGINAL_COMMAND; else %(giteacmd)s ; fi",no-port-forwarding,no-X11-forwarding,no-agent-forwarding
for shared hosting, generating a line as describe above

Originally created by @927589452 on GitHub (Aug 1, 2019). ## Description Add an option to modify, what is written to the `authorized_keys`, so gitea can be used with the same key, which is also used for accessing the server. An example for such a modification is this ``` command="if [ -t 0 ]; then bash; elif [[ $SSH_ORIGINAL_COMMAND =~ ^(scp|rsync|mysqldump).* ]]; then eval $SSH_ORIGINAL_COMMAND; else /home/<username>/gitea/gitea serv key-1 --config='/home/<username>/gitea/custom/conf/app.ini'; fi",no-port-forwarding,no-X11-forwarding,no-agent-forwarding ssh-... ``` this is useful for shared hosting scenarios like the [guide](https://lab.uberspace.de/guide_gitea.html) by @luto, where i copied this line from. I would imagine an option `SSH_RESTRICT:` **%(giteacmd)s** and used like this `SSH_RESTRICT:` _if [ -t 0 ]; then bash; elif [[ $SSH_ORIGINAL_COMMAND =~ ^(scp|rsync|mysqldump).* ]]; then eval $SSH_ORIGINAL_COMMAND; else_ **%(giteacmd)s** _; fi",no-port-forwarding,no-X11-forwarding,no-agent-forwarding_ for shared hosting, generating a line as describe above

GiteaMirror added the type/proposal label 2025-11-02 05:22:33 -06:00

GiteaMirror closed this issue

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

GiteaMirror commented

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

@zeripath commented on GitHub (Aug 1, 2019):

You should consider using the AuthorizedKeysCommand gitea keys - parse the output and adjust it as per necessary.

See https://docs.gitea.io/en-us/command-line/#keys

Either that or you can parse the output of gitea's authorized_keys file.

Take a look at the techniques used in bozaro/git-as-svn https://bozaro.github.io/git-as-svn/htmlsingle/git-as-svn.html#_gitea_2

@zeripath commented on GitHub (Aug 1, 2019): You should consider using the AuthorizedKeysCommand `gitea keys` - parse the output and adjust it as per necessary. See https://docs.gitea.io/en-us/command-line/#keys Either that or you can parse the output of gitea's authorized_keys file. Take a look at the techniques used in bozaro/git-as-svn https://bozaro.github.io/git-as-svn/htmlsingle/git-as-svn.html#_gitea_2

GiteaMirror commented

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

@zeripath commented on GitHub (Aug 1, 2019):

You can also shadow the gitea binary - so that when gitea serv is called you can do what you like with it.

@zeripath commented on GitHub (Aug 1, 2019): You can also shadow the gitea binary - so that when `gitea serv` is called you can do what you like with it.

GiteaMirror commented

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

@927589452 commented on GitHub (Aug 1, 2019):

You should consider using the AuthorizedKeysCommand gitea keys - parse the output and adjust it as per necessary.
See https://docs.gitea.io/en-us/command-line/#keys

This is sadly of the table, as this is a shared host; so no root for me.
But I will have a look at the other solutions.

@927589452 commented on GitHub (Aug 1, 2019): > You should consider using the AuthorizedKeysCommand `gitea keys` - parse the output and adjust it as per necessary. > See https://docs.gitea.io/en-us/command-line/#keys This is sadly of the table, as this is a shared host; so no root for me. But I will have a look at the other solutions.

GiteaMirror commented

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

@zeripath commented on GitHub (Aug 1, 2019):

Shadowing the Gitea binary and running that is probably the easiest thing to do.

In your Shadow you need to exec gitea to get it to refer to the shadow in the authorized_keys etc.

@zeripath commented on GitHub (Aug 1, 2019): Shadowing the Gitea binary and running that is probably the easiest thing to do. In your Shadow you need to exec gitea to get it to refer to the shadow in the authorized_keys etc.

GiteaMirror commented

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

@zeripath commented on GitHub (Oct 13, 2019):

To be more explicit on how to shadow gitea - here's the technique:

Assuming you have gitea started by running /app/gitea/gitea
Move the original gitea from /app/gitea/gitea to /app/gitea/gitea.shadow
Create a new bash script /app/gitea/gitea:

#!/bin/bash

############################################################
# Gitea shadow script
# 
# Detects calls to gitea serv and expands the allowed SSH_ORIGINAL_COMMANDS
############################################################
SHADOWED_GITEA_PATH="/app/gitea/gitea.shadow"
KEY="$2"
SUBCOMMAND="$1"
OUR_SHELL_PATH="/app/gitea/gitea"

# If we're not running serv just pass straight to gitea
if [ "$SUBCOMMAND" != "serv" ]; then
    exec -a "$OUR_SHELL_PATH" "$SHADOWED_GITEA_PATH" "$@"
fi

# OK this is a call to `gitea serv` - i.e. from authorized_keys
# So now we need to check if the original command is in our set of an additional allowed commands

# Split the Original command in to its separate components
SSH_ORIGINAL_COMMANDS=($SSH_ORIGINAL_COMMAND)

if [ -n "$SSH_ORIGINAL_COMMAND" ] && [ "${SSH_ORIGINAL_COMMANDS[0]}" =~ ^(scp|rsync|mysqldump) ] ; then
    ################################################################
    # THIS IS YOUR RESPONSIBILITY TO CHECK THAT THIS IS THE RIGHT THING TO DO
    # I'm not sure the eval is quite right here it might need to be exec 
    ################################################################
    eval $SSH_ORIGINAL_COMMAND
else
    exec -a "$OUR_SHELL_PATH" "$SHADOWED_GITEA_PATH" "$@"
fi

Finally make sure that you only ever call /app/gitea/gitea and never the shadow.

Apart from this I cannot see another way to safely or reliably add this functionality, so with that I'll close this issue.

@zeripath commented on GitHub (Oct 13, 2019): To be more explicit on how to shadow gitea - here's the technique: * Assuming you have gitea started by running `/app/gitea/gitea` * Move the original gitea from `/app/gitea/gitea` to `/app/gitea/gitea.shadow` * Create a new bash script `/app/gitea/gitea`: ```bash #!/bin/bash ############################################################ # Gitea shadow script # # Detects calls to gitea serv and expands the allowed SSH_ORIGINAL_COMMANDS ############################################################ SHADOWED_GITEA_PATH="/app/gitea/gitea.shadow" KEY="$2" SUBCOMMAND="$1" OUR_SHELL_PATH="/app/gitea/gitea" # If we're not running serv just pass straight to gitea if [ "$SUBCOMMAND" != "serv" ]; then exec -a "$OUR_SHELL_PATH" "$SHADOWED_GITEA_PATH" "$@" fi # OK this is a call to `gitea serv` - i.e. from authorized_keys # So now we need to check if the original command is in our set of an additional allowed commands # Split the Original command in to its separate components SSH_ORIGINAL_COMMANDS=($SSH_ORIGINAL_COMMAND) if [ -n "$SSH_ORIGINAL_COMMAND" ] && [ "${SSH_ORIGINAL_COMMANDS[0]}" =~ ^(scp|rsync|mysqldump) ] ; then ################################################################ # THIS IS YOUR RESPONSIBILITY TO CHECK THAT THIS IS THE RIGHT THING TO DO # I'm not sure the eval is quite right here it might need to be exec ################################################################ eval $SSH_ORIGINAL_COMMAND else exec -a "$OUR_SHELL_PATH" "$SHADOWED_GITEA_PATH" "$@" fi ``` * Finally make sure that you only ever call `/app/gitea/gitea` and never the shadow. Apart from this I cannot see another way to safely or reliably add this functionality, so with that I'll close this issue.

GiteaMirror referenced this issue

2025-11-02 12:25:12 -06:00

[PR #3709] [CLOSED] Fix goreportcard badge link #17053

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/gitea#3709