Allow admins full ssh access

[docwhat]

This feature allows anyone who is an admin in gitlab normal SSH
access, including starting a tty session; in effect causing
gitlab-shell to become transparent to admins.

I wrote this so capistrano will continue to work without major
kludges (like sudo).

If GitLab isn't running, then gitlab-shell will deny access
to admins (unfortunately).

This feature requires a new GitLab internal api call, "admin", to
check if a given SSH key belongs to an unblocked admin.

When I made these changes, I also replaced system() calls with
Kernel::exec() because there is no need to keep the ruby process
around once we've authenticated the user.

[coveralls]

Coverage increased (+0.28%) when pulling db5bcb6 on docwhat:admin-sh-access into e8d93d0 on gitlabhq:master.

View Details

[docwhat]

This commit requires GitLab pull request #3219 to work.

[docwhat]

@randx commented on Gitlab #3219:

I am not sure I want to give full ssh access to any admin. Also stealing/hacking admin account may have terrible effects in this case

Then may I suggest that a config.yml option be added to turn this feature on?

The problem I'm trying to solve is that the instructions to deploy GitLab 5.0 have the user put the GitLab web account and gitlab-shell both in the git account on the system.

This breaks capistrano as soon as you run rake gitlab:shell:setup because the authorized_keys is overwritten.

You can tell capistrano to use sudo over to a different user, but not all the commands in capistrano have their run lines include the #{sudo}.... at the beginning. In addition, this breaks SSH Agent Forwarding.

Let me think about this and see if I can come up with an alternative way to specify people who can get full SSH access.

[dzaporozhets]

I think we should deploy from user different from git. Allowing ssh access to admins is potential security issue i cannot allow. I hope you understand.

[docwhat]

@randx -- I don't think you can run gitlab-shell and gitlabhq from different user accounts. Not without setting the setuid bits on gitlab-shell commands and some other really tricky Unix admin setups.

[dzaporozhets]

I am not talking about running gitlabhq and gitlab-shell from different users. They must run from same user git.
I talk that you can deploy with other user than git. Ex create sudo user deploy and do deploy staff from it

[docwhat]

@randx -- I haven't had success with that in capistrano. I used something like this in my deploy.rb:

set :sudo, 'sudo -i -u git'
set :use_sudo, true

This had two problems:

1. Not everything in capistrano uses try_sudo. See capistrano bug #306.
2. SSH agent forwarding is lost -- If you store gitlab within gitlab, then you could get away with specifying the location of the repository.

[docwhat]

Oh, and the third issue is that config/deploy.rb.example would break because foreman is trying to use sudo to become root to install upstart commands.

[dzaporozhets]

In this case capistrano is not actually what we need. So I'll remove capistrano examples from GitLab.

[docwhat]

Yeah, capistrano's default deploy mechanisms don't seem like they can handle the case of logging in with one user and switching via sudo to another on every command. The bug I mentioned above was just for things meant to sudo to root, not to an arbitrary user.

I suppose you could set up a 'deploy' user who has their shell set to 'sudo -i -u git' but that seems like asking for trouble.

[docwhat]

In this case capistrano is not actually what we need. So I'll remove capistrano examples from GitLab.

@randx what do you propose then?

If gitlab-shell knew about users, then you could add user-ids to the config.yml of people who could bypass all the checks and get full shell access.

[docwhat]

@randx

Okay, how is this for a proposal:

1. GitLab will call Gitlab:Shell::add_key(key_id, key_content, username)
2. This calls bin/gitlab-keys add-key #{key_id} "#{key_content}" "#{username}"
3. gitlab-shell will have a list of usernames that are allowed full shell access.

Pros:

• This works even if gitlab (we can avoid calling the gitlab API at all if the user is listed in config.yml)

Cons:

• User renames: You can lock yourself out this way or you could allow someone else to nab full ssh access by taking your username.
• User deletes: if a full ssh access user is deleted, someone can take that username.

Alternative:

• Specify user_id instead of username.
• Allow either a user_id or a username to specified in the config.yml

[dzaporozhets]

I dont like any alternative of providing full ssh access to git user at all. It should be only git commands

[dzaporozhets]

So my suggestion still the same - use other sudo user for deploy.

[docwhat]

@randx

That's not very friendly to people who want to deploy via capistrano. By requiring some settings in the config.yml this makes it "opt-in".

What's wrong with letting people opt-in to this? People who don't want to let anyone have full ssh access can just not use this feature. People who want it (for example, for capistrano installs) can turn it on.

[dzaporozhets]

@docwhat I'm sorry that some tools does not work well with our software.
Also I'm sure its not so much people who deploy their GitLab instances with capistrano to add this settings.
Also I dont want this feature at all because again if someone steal your account he will get full ssh access.
So I wont merge it even as an option disabled by default.
Also capistrano is not the only tool for deploy. I'm sure we can find tool that works properly with user switching during deploy

[dzaporozhets]

thank you for discussion but I'm closing this one

[docwhat]

Okay. One more try...

How about a list of public SSH keys that are allowed full access. They can be either dropped in a directory or put in the config.yml.

If a gitshell-keys add adds a matching SSH key, then it'll enable full access for those keys only.

With that configuration, even if all gitlab accounts are compromised, no unauthorized users can get full ssh access since they won't have the private SSH keys. The worst that can be done is that public keys can be deleted from gitlab which would lock the full-access users out of the git account.

Does that address your concern?

[docwhat]

Heck. It doesn't even need to do anything on gitshell-keys add. It can do it all when running bin/gitlab-shell.

[PierrePaul]

You could use a command="sudo -i -u git" in the .ssh/authorized_keys of the deploy user. You would not need to hack capistrano this way. Unless I'm missing something?

[docwhat]

@PierrePaul The problem is that you can't use sudo for scp/sftp operations, which capistrano makes use of.

[westberliner]

If you don't need ssh access for a service, you can still login via "ssh user@host -o PubkeyAuthentication=no".

[docwhat]

@westberliner True enough. But in the case I was trying to do I need ssh access. The sshd is set, by our security policy, to reject password logins. I don't even know if the account has a password.