Feature Request: modified authorized keys

[927589452]

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 [[ $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

[zeripath]

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]

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

[927589452]

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.

[zeripath]

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]

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.