1. I created user 'git-server'
  2. Installed openssh-server
  3. Modified /etc/ssh/sshd_config added PasswordAuthentication no
  4. Added to .ssh/authorized_keys public case of my colleagues


  • Is 'git-server' user secure for my system? What is the worst scenario for system if malefactor gets access to 'git-server', providing the fact 'git-server' is sudoer
  • How can I forbid to 'git-server' all operations apart git commands?

You should change default shell of user git-server to git-shell.


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.


Well, lets look at how you set up that git-server account on the system.

Modified /etc/ssh/sshd_config added PasswordAuthentication no

because you set password authentication to no, then trying to log into the system under that name remotely is virtually impossible without a valid SSH key. As far as I am aware, I don't think ssh keys have been cracked granted it does depend on the cipher and cipher complexity you are using to determine that.

So now that fact is out of the way, if someone managed to get access to that account. It would most likely mean, someone who already had access to your system that was given privileges to use su would have done it, or somehow if you locked down your system properly, someone gained access to root which is more impossible than gaining access to the git-server account. But if that isn't the case and they did log into that account remotely using SSH, then everyone using SSH is in trouble as that would mean anyones system that uses ssh would be vulnerable. Now the most damage that can be done is the same amount of damage you can cause with your normal account with sudo privileges.


Some variables to set if there's any need to follow along with suggestions...


... which'll be written from the perspective of your server admin account.

  1. I created user 'git-server'

By chance did ya lock it and make it a system account?

sudo adduser\
 --gecos ''\
 --shell "$(which git-shell)"\
 --home "${_git_home_base,,}/${_git_user,,}"\
 --ingroup "${_git_group}"\

Note, if $(which git-shell) resolves to a file path but --shell option pops errors then...

if [ -e "$(which git-shell)" ] && ! grep -q -- "$(which git-shell)" /etc/shells; then
    sudo tee -a /etc/shells 1>/dev/null <<<"$(which git-shell)"

... may be helpful in appending the git-shell path to the /etc/shells file

  1. Installed openssh-server
  2. Modified /etc/ssh/sshd_config added PasswordAuthentication no

Have you disabled root password authentication over SSH?

/etc/ssh/sshd_config bits that may be helpfull...

permitrootlogin without-password

## Additionally consider locking-down other unneeded features
Match Group git-devs
  AllowTcpForwarding no
  AllowStreamLocalForwarding no
  PermitOpen none

  1. Added to .ssh/authorized_keys public case of my colleagues

Where precisely did you add their public keys?

Here's some example commands for setting up three Git accounts...

declare -a _accounts_keys=(

for _name in "${!_accounts_keys[@]}"; do
    sudo su --login "${_name}" --shell /bin/bash <<EOF
mkdir .ssh
tee -a .ssh/authorized_keys 1>/dev/null <<<"$(<"${_accounts_keys[${_name}]}")"
chmod 600 .ssh/authorized_keys

Is 'git-server' user secure for my system? What is the worst scenario for system if malefactor gets access to 'git-server', providing the fact 'git-server' is sudoer

No and if you've added everyone's keys to the same account, and that account is a sudoer, then the amount of nightmare fuel I could douse this situation with is near limitless...

How can I forbid to 'git-server' all operations apart git commands?

Add git-shell-commands/no-interactive-login script to each Git account...

for _name in "${!_accounts_keys[@]}"; do
    sudo su --login "${_name}" --shell /bin/bash <<EOC
tee 'git-shell-commands/no-interactive-login' 1>/dev/null <<'EOF'
#!/usr/bin/env bash
printf 'Hi %s, you have successfully authenticated!\n' "${USER}"
printf 'However, there is not an interactive shell here.\n'
exit 128

chmod u+x 'git-shell-commands/no-interactive-login'

... so long as there are no other executable files within the git-shell-command directory the account will be limited to non-interactive git commands; provided that the account's shell is also set correctly.

The above isn't the most secure but balanced with convenience;

  • git-devs group should be different for each account if the cross cloning is not wanted, eg name-one could (when the primary group is shared between accounts), git clone name-two@server:/srv/git-devs/name-two/project-name if they knew how things where structured server side.

Note, if permissions where 600 this could be disabled per-project within an individual account, and if permissions where 660 that would enable the shared group to push as well as pull to a repository... personally I find 640 to be the best of both options as this allows a group to share code among one another without to much fear of a stray git push -f from another account messing things up.

  • For examples on other git-shell-commands scripts consider checking the git-utilities/git-shell-commands repository, where the above tips where adapted from, though that would tip things even more towards convenience.

In short don't add the above linked scripts if ya cannot trust clients to not try and pop-ah-shell because such things are designed so that the need for an interactive shell isn't as prevalent.

Bonus points

  • check out man --pager='less -p "ChrootDirectory"' sshd_config for hints on what can be done to further secure the SSH server

  • check man git-shell and man git-daemon for related documentation; there be some useful options for both locking things down and/or making the server a little easier to communicate with, eg. --strict-paths, --base-path=<path>, and --listen=<host_or_ipaddr> might be worth looking into further

If there's something questionable about the above consider commenting so that this answer may be improved.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.