6

I have setup a git server, by creating a user "git" and then creating a local repository in the git user's directory.

The git server works great, I can pull, push, etc. I allowed users to interact with the git repo by adding their public keys to to the 

 .ssh/authorized_keys

file. I have disabled password based logins. But the problem is that these users can login to the server via ssh since their keys are on the authorized keys list. Okay, the permissions are set to be pretty restricted for the git user, but still, I would prefer it if there was no way for git to login directly.

Is there a way to disable logins for the "git" user, but maintain the ability for the git user to accept pushes and pull through git/ssh?

Improve this question
0

3 Answers 3

Reset to default
11

You can use git-shell to restrict access to SSH user accounts. From the documentation page:

This is a login shell for SSH accounts to provide restricted Git access. It permits execution only of server-side Git commands implementing the pull/push functionality, plus custom commands present in a subdirectory named git-shell-commands in the user’s home directory.

git-shell is non-interactive by default. Setting a user's default shell to git-shell will allow you to prevent users from interactively logging into your server, while keeping the functionality of git intact. Some level of customization is possible, which is documented on the same page, under the 'EXAMPLES' section.

git-shell should be installed along with git at /usr/bin/git-shell. You can set this as a user's default shell using usermod:

usermod -s /usr/bin/git-shell username
Improve this answer
4

I'm not convinced that having all your users log in as the "git" user is the best idea from a security standpoint, but it's certainly possible to do what you want through the ForceCommand configuration option. For example, to only let the user named "git" run the "git" command, you'd add the following to your /etc/ssh/sshd_config file:

Match User git
    ForceCommand /usr/bin/git
    AllowTCPForwarding no
    X11Forwarding no

Read the sshd_config man page and adjust as needed for your specific situation.

Improve this answer
5
  • Hi Mark. You're right, I believe that what I'm doing is awful from a security point of view. I simply followed a guide from digital ocean, but the guide was for setting up a private (which I imagine means not shared) git repo. Would you mind recommending a better option? I wouldn't mind at all if users of the git repo could not login at all, but could still sync with a "main" git repo.
    – Jonathan Gallagher
    Dec 20, 2018 at 17:08
  • Is it necessary to have a user 'git'?
    – Stephen Boston
    Feb 13, 2020 at 14:56
  • But this will just run git once without any arguments and then logout again. What's the point?
    – JosefScript
    Jun 3, 2020 at 19:33
  • @JosefScript, the point is that the 'git' program on your computer makes an ssh connection to the 'git' program on the other computer, and then streams data back and forth using standard I/O. The other point is that if you use the 'ssh' program on your computer to make a ssh connection to the other computer, you'll wind up connected to the 'git' program on the other computer, and be unable to use standard shell commands to do anything.
    – Mark
    Jun 3, 2020 at 22:51
  • git isn't interactive, though. It's likely that the connecting user would just receive the git basic help output and be disconnected. Might as well set /bin/true as your shell.
    – Brian White
    Jan 15 at 19:34
3

If you install gitlab-ce it explicitly states that a non-standard user-level ssh config can cause weird breakage and it wants to fix it.

What gitlab-ce does do though is that when adding a key via the web interface, it adds some config info at the same time -

# cat ~git/.ssh/authorized_keys
command="/opt/gitlab/embedded/service/gitlab-shell/bin/gitlab-shell key-1",no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty ssh-rsa AA...restofkeysnip!

Note the git user has no ~/.bashrc or ~/.profile or other dot files, and the shell is set to be /bin/sh, and there is no modification done to the sshd_config.

Improve this answer
2
  • 1
    Thanks. I didn't realize you could put code in the authorized_keys file. Is that a potential security risk?
    – Jonathan Gallagher
    Dec 20, 2018 at 17:11
  • 1
    I don't think so, since it is using ssh's options based on what key was used to authenticate as that user. Don't know if just using the options vs. also specifying a command is what you need for your situation, since I'm not sure of a single command you could specify that would allow normal git stuff to happen but not depend on a pty, etc. I'd try wiht the options, not using a command option, and see if you can git push/pull/etc but not actually connect and spawn a shell. The gitlab-shell I think is a busybox -like interpreter with a fixed, short, git-related only command list.
    – ivanivan
    Dec 20, 2018 at 21:51

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .