Do not overwrite authorized_keys when using built in server

[pgaskin]

• Gitea version (or commit ref): f2afed3

Description

The admin action for rewriting authorized keys currently overwrites authorized_keys, even when using the built in server.

This should not happen because it may lock users out if running it as their main system user with the same authorized keys for ssh and gitea.

[noerw]

Holy shit, this is bad.
This happened to me, I guess I have to call support of my hoster now..

Can we please

• label this as bug
• make the option to override authorized_keys unavailable when using native SSH
• or: add a hook to revert to original authorized_keys via the frontend?

To help me explain to support: How is gitea even able to take over the SSH daemon?

edit:
Alright, I manged to ssh back into my machine by adding a new ssh-key to authorized_keys via the web interface of my hosting provider. This is bad none the less

Btw, I clicked that button, as this was suggested in order to make the advertised ssh clone URL work!

[lunny]

I think this has been fixed by #3377. @noerw which version did you use?

[lafriks]

Yes, this is fixed by #3377

[noerw]

@lunny This happened with v1.4.3. Thanks for the feedback!

It seems I misunderstood how it works then, I was not using the built in SSH server, and locked myself out anyway.
Later I found warnings about this in the documentation, but IMO there should be a big red sign next to the button and not in some document. Or better (as described above), provide a way to undo the action.

[lunny]

@noerw #3377 has fixed this actual issue but not hide the rewrite public key item on Admin Panel. But in fact, if you are using internal SSH and you click that button, it will do nothing. see https://github.com/go-gitea/gitea/pull/3377/files#diff-bc1f3a75a0a9d450f654cec20fd672e9R541

[lafriks]

@noerw you should never be using same account you log into system for any system service