Em 27-06-2011 10:25, Benjamin Podszun escreveu:
Hi

On Mon, Jun 27, 2011 at 4:18 PM, Rodrigo Rosenfeld Rosas
<rr.ro...@gmail.com>  wrote:
Em 27-06-2011 08:33, Benjamin Podszun escreveu:
Hi there

On Mon, Jun 27, 2011 at 11:17 AM, Marius Mårnes Mathiesen
<marius.mathie...@gmail.com>    wrote:
On Sun, Jun 26, 2011 at 10:16 AM, martin<mar...@siamect.com>    wrote:
I don't understand why you are concerned about the dedicated git user
account... just lock it down properly. You have exactly the same
situation on every ssh server on the planet.
As I mentioned above, I suspect most users running their own Gitorious
servers have sshd running as the root user, since otherwise they'd need a
separate IP address/port in order to do maintenance on their servers. I
don't think it's reasonable to assume people looking for a way to
collaborate on code have experience in locking down a SSH daemon on their
server.
Since this came up several times now: Can you explain that part? I
wonder if you'd consider my environment at risk...
What Marius is trying to say is that *if you're exposing your Gitorious
installation to the web* you *must* make sure you protect it adequately.
If you need to expose Gitorious, than it makes sense to disable SSH and go
with HTTPS if you don't want to expose SSH to the Internet. Otherwise, you
should probably disable password authentication for all users. It would also
be a great idea to disallow SSH login with the root account and create
another one for logging in instead. Not that SSH is unreliable, but these
are best practices if your security concerns are high.
Could be. I'm not sure. We're probably all non-native english
speakers. I read 'have sshd running as the root user' as 'running the
process sshd with effective uid 0', which is the default, with some
twists (see the privilege separation thing). I don't know any problems
with this and would love to hear any issues that gitorious.org had
with this in the past. Maybe I adapt my own setup afterwards.

If it the point was purely about securing the box/service itself,
disallowing root logins etc, as you understood it, then my point is
moot and everything's good/I agree totally.

I think it is not currently possible to listen on port 22 with effective uid other than 0 in Unix-like systems, but I may be wrong since I'm not really a security specialist.

If we set it up to run in another port, than instead of 'git@some.server/some/repo' we would have 'git@some.server:2222/some/repo'.

Maybe someone here with better knowledge on security could state otherwise how to listen on port 22 without running the service with an unprivileged account.

--
To post to this group, send email to gitorious@googlegroups.com
To unsubscribe from this group, send email to
gitorious+unsubscr...@googlegroups.com

Reply via email to