Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Empty authorized_keys after delete user key #424

Closed
xoxys opened this issue Dec 20, 2016 · 10 comments · Fixed by #906
Closed

Empty authorized_keys after delete user key #424

xoxys opened this issue Dec 20, 2016 · 10 comments · Fixed by #906
Labels
type/enhancement An improvement of existing functionality
Milestone

Comments

@xoxys
Copy link
Contributor

xoxys commented Dec 20, 2016

Hi,
i have multiple ssh-keys in my authorized_keys file on the server. If i delete a key from gitea user in the web frontend my authorized_keys file is empty. Deleting a user key in the frontend does not delete only the gitea key, it also deletes all other keys in authorized_keys...

Thanks for your work.
Robert

--- Want to back this issue? **[Post a bounty on it!](https://www.bountysource.com/issues/40238058-empty-authorized_keys-after-delete-user-key?utm_campaign=plugin&utm_content=tracker%2F47456670&utm_medium=issues&utm_source=github)** We accept bounties via [Bountysource](https://www.bountysource.com/?utm_campaign=plugin&utm_content=tracker%2F47456670&utm_medium=issues&utm_source=github).
@tboerger
Copy link
Member

This is the current behavior, you should anyway use a dedicated user for Gitea. I will keep this issue open, maybe we will add some kind of marker to this file to prevent the deletion of existing keys in the future.

@tboerger tboerger added the type/enhancement An improvement of existing functionality label Dec 20, 2016
@tboerger tboerger added this to the 1.x.x milestone Dec 20, 2016
@xoxys
Copy link
Contributor Author

xoxys commented Dec 20, 2016

Sure normal behavior would be to use a dedicated user. But some of us (like me) use gogs/gitea in a shared hoster environment (for me it is uberspace.de) so it is not possible to run applications with a different user. Also there is an other fact (maybe im wrong) but if i run gitea with a generic user for example "git" the SSH keys for multiple gitea users are in the same authorized_key file (/home/git/authorized_keys) right? If one user deletes bis SSH key from the web gui, all other users will lose his keys too because all keys are in the same file? If this is right there is a big Problem for multi user environments.

@tboerger
Copy link
Member

But the behavior is the same for Gogs and Gitea. And the file is shared for all Gitea users, but it gets regenerated if a user deletes his key from the UI.

@xoxys
Copy link
Contributor Author

xoxys commented Dec 20, 2016

You are right. Nice to here the file will be regenerated, that makes much more sense :)

@xoxys
Copy link
Contributor Author

xoxys commented Dec 20, 2016

Would it be possible to add a custome file to the config? In this file users can add static non-git ssh-keys and if gitea regenerates the authorized_keys the keys from this file will be merged with the git-ssh keys.

@tboerger
Copy link
Member

IMHO some marker within the file makes more sense

@travnick
Copy link

It's more like a bug rather than enhancement. If gogs dos it too then it also has a bug.
Why bug? Because it does things that is not suppose to do - gitea should not touch things that belongs to others.

I've got my authorized_keys wiped out without using any "key" feature in gitea.

@strk
Copy link
Member

strk commented Feb 12, 2017 via email

@strk
Copy link
Member

strk commented Feb 12, 2017 via email

@tboerger
Copy link
Member

Yeah, this issue will be resolved when #906 gets merged.

@lunny lunny closed this as completed in #906 Mar 2, 2017
@go-gitea go-gitea locked and limited conversation to collaborators Nov 23, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
type/enhancement An improvement of existing functionality
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants