Gitea shows wrong repo SSH URLS when using builtin SSH #1037

New Issue

GiteaMirror · 2025-11-02T03:46:10-06:00

GiteaMirror commented

2025-11-02 03:46:10 -06:00

Originally created by @smckown on GitHub (Sep 1, 2017).

Gitea version (or commit ref): 1.2.0-rc1 (binary install)
Git version: 2.11.0
Operating system: Ubuntu Linux 16.04 amd64
Database (use [x]):
- PostgreSQL
- MySQL
- MSSQL
- SQLite
Can you reproduce the bug at https://try.gitea.io:
- Yes (provide example URL)
- No
- Not relevant
Log gist: None relevant

Description

I'm using gitea configured with built-in SSH. Server section from custom/conf/app.ini:

[server]
PROTOCOL         = https
SSH_DOMAIN       = proj.nowhere.com
DOMAIN           = proj.nowhere.com
HTTP_PORT        = 10443
ROOT_URL         = https://proj.nowhere.com:10443/
DISABLE_SSH      = false
SSH_PORT         = 10022
START_SSH_SERVER = true
OFFLINE_MODE     = true
CERT_FILE        = custom/https/cert.pem
KEY_FILE         = custom/https/key.pem

In the UI, repository SSH URLs are always shown with the same username, smckown, regardless of the user currently logged into Gitea. Here's one of those URLs, copied and pasted:

ssh://smckown@proj.nowhere.com:10022/Sporian/ucshared.git

Since we are trialing Gitea with a small number of users, I've let them know how to adjust the URL, and in doing so all users are able to perform git operations against Gitea via SSH with no problem.

It may be relevant that user smckown was the first user added to the system (and so the first administrator), and also the user that created all the current repositories in Gitea by using the Migrations feature, migrated from bare git repos on the same machine served by the system that Gitea may replace.

On searching to see if this issue is already present, I don't really see anyone using the built-in SSH server. Is there any particular reason to avoid its use? Thanks!

Originally created by @smckown on GitHub (Sep 1, 2017). - Gitea version (or commit ref): 1.2.0-rc1 (binary install) - Git version: 2.11.0 - Operating system: Ubuntu Linux 16.04 amd64 - Database (use `[x]`): - [ ] PostgreSQL - [ ] MySQL - [ ] MSSQL - [x] SQLite - Can you reproduce the bug at https://try.gitea.io: - [ ] Yes (provide example URL) - [ ] No - [x] Not relevant - Log gist: None relevant ## Description I'm using gitea configured with built-in SSH. Server section from custom/conf/app.ini: ``` [server] PROTOCOL = https SSH_DOMAIN = proj.nowhere.com DOMAIN = proj.nowhere.com HTTP_PORT = 10443 ROOT_URL = https://proj.nowhere.com:10443/ DISABLE_SSH = false SSH_PORT = 10022 START_SSH_SERVER = true OFFLINE_MODE = true CERT_FILE = custom/https/cert.pem KEY_FILE = custom/https/key.pem ``` In the UI, repository SSH URLs are always shown with the same username, smckown, regardless of the user currently logged into Gitea. Here's one of those URLs, copied and pasted: ``` ssh://smckown@proj.nowhere.com:10022/Sporian/ucshared.git ``` Since we are trialing Gitea with a small number of users, I've let them know how to adjust the URL, and in doing so all users are able to perform git operations against Gitea via SSH with no problem. It may be relevant that user smckown was the first user added to the system (and so the first administrator), and also the user that created all the current repositories in Gitea by using the Migrations feature, migrated from bare git repos on the same machine served by the system that Gitea may replace. On searching to see if this issue is already present, I don't really see anyone using the built-in SSH server. Is there any particular reason to avoid its use? Thanks!

GiteaMirror closed this issue

2025-11-02 03:46:11 -06:00

GiteaMirror commented

2025-11-02 03:46:11 -06:00

@lunny commented on GitHub (Sep 2, 2017):

maybe you can find RUN_USER

@lunny commented on GitHub (Sep 2, 2017): maybe you can find RUN_USER

GiteaMirror commented

2025-11-02 03:46:11 -06:00

@smckown commented on GitHub (Sep 3, 2017):

Thanks @lunny for the clue. The gitea process is running as user smckown. I'm closing the issue, and adding some more information in case others with a similar misunderstanding are searching for clues.

We are currently using GitBlit for repository hosting. It uses a more traditional ssh authentication scheme, where the provided username must match a valid user, and the offered key must match one loaded into that user's account. For this reason, Gitblit shows each user a customized SSH URL, with their username included. I now understand this is not how Gitea works.

I see through experimentation that gitea builtin sshd ignores the username and authenticates only using the offered key. This makes perfect sense for the system sshd case, where all requests come in as the same user (like 'git'), and so the ssh username imparts no useful information to Gitea. It also makes sense to keep things simple and use the same logic for the builtin sshd case too.

This means a Gitea user can clone via builtin sshd using any ssh username. I can clone any of my repos using an invalid Gitea username and it works fine (I previously uploaded my ssh public key to Gitea):

$ git clone ssh://invalid_gitea_user@proj.nowhere.com:10022/smckown/dotfiles.git
Cloning into 'dotfiles'...
remote: Counting objects: 727, done.
remote: Compressing objects: 100% (387/387), done.
remote: Total 727 (delta 384), reused 662 (delta 319)
Receiving objects: 100% (727/727), 324.58 KiB | 27.00 KiB/s, done.
Resolving deltas: 100% (384/384), done.
$

One can also see this by issuing an ssh command to the gitea builtin server via the plain ssh client. Below is an attempt to run a bash shell via the builtin sshd, which will fail of course. However a couple of lines of the verbose output are particularly telling:

$ ssh -v -p 10022 invalid_gitea_user@proj.sporian.com /bin/bash
...
debug1: Authenticating to proj.nowhere.com:10022 as 'invalid_gitea_user'
...
debug1: Authentication succeeded (publickey).
Authenticated to proj.nowhere.com ([192.168.90.23]:10022).

Since the ssh username is ignored, it would be nice if the SSH URLs rendered in Gitea didn't include RUN_USER when using the builtin sshd, but I digress...

@smckown commented on GitHub (Sep 3, 2017): Thanks @lunny for the clue. The gitea process is running as user smckown. I'm closing the issue, and adding some more information in case others with a similar misunderstanding are searching for clues. We are currently using GitBlit for repository hosting. It uses a more traditional ssh authentication scheme, where the provided username must match a valid user, and the offered key must match one loaded into that user's account. For this reason, Gitblit shows each user a customized SSH URL, with their username included. I now understand this is not how Gitea works. I see through experimentation that gitea builtin sshd ignores the username and authenticates only using the offered key. This makes perfect sense for the system sshd case, where all requests come in as the same user (like 'git'), and so the ssh username imparts no useful information to Gitea. It also makes sense to keep things simple and use the same logic for the builtin sshd case too. This means a Gitea user can clone via builtin sshd using any ssh username. I can clone any of my repos using an invalid Gitea username and it works fine (I previously uploaded my ssh public key to Gitea): ``` $ git clone ssh://invalid_gitea_user@proj.nowhere.com:10022/smckown/dotfiles.git Cloning into 'dotfiles'... remote: Counting objects: 727, done. remote: Compressing objects: 100% (387/387), done. remote: Total 727 (delta 384), reused 662 (delta 319) Receiving objects: 100% (727/727), 324.58 KiB | 27.00 KiB/s, done. Resolving deltas: 100% (384/384), done. $ ``` One can also see this by issuing an ssh command to the gitea builtin server via the plain ssh client. Below is an attempt to run a bash shell via the builtin sshd, which will fail of course. However a couple of lines of the verbose output are particularly telling: ``` $ ssh -v -p 10022 invalid_gitea_user@proj.sporian.com /bin/bash ... debug1: Authenticating to proj.nowhere.com:10022 as 'invalid_gitea_user' ... debug1: Authentication succeeded (publickey). Authenticated to proj.nowhere.com ([192.168.90.23]:10022). ``` Since the ssh username is ignored, it would be nice if the SSH URLs rendered in Gitea didn't include RUN_USER when using the builtin sshd, but I digress...

GiteaMirror referenced this issue

2025-11-02 11:53:20 -06:00

[PR #1048] [MERGED] Fix for #1037: Corrected process ID placeholder to PID from Pid #15732

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#1037