☰

Безопасность: git-сервер с аутентификацией ssh

tag-icon • tag-icon linux ssh security unix
Безопасность: git-сервер с аутентификацией ssh
  1. Я создал пользователя 'git-server'
  2. Установленopenssh-server
  3. Изменено /etc/ssh/sshd_configдобавленоPasswordAuthentication no
  4. Добавлено в .ssh/authorized_keysпубличное дело моих коллег

Вопросы:

  • Безопасен ли пользователь 'git-server' для моей системы? Какой наихудший сценарий для системы, если злоумышленник получит доступ к 'git-server', при условии, что 'git-server' являетсяsudoer
  • Как запретить «git-server» все операции, кроме gitкоманд?

решение1

Вам следует изменить оболочку по умолчанию пользователя git-server на git-shell.

https://git-scm.com/docs/git-shell.html

Это оболочка входа для учетных записей SSH, обеспечивающая ограниченный доступ к Git. Она позволяет выполнять только серверные команды Git, реализующие функциональность pull/push, а также пользовательские команды, представленные в подкаталоге git-shell-commands в домашнем каталоге пользователя.

решение2

Что ж, давайте посмотрим, как настроить учетную запись git-сервера в системе.

Изменен /etc/ssh/sshd_config добавлен PasswordAuthentication нет

поскольку вы устанавливаете аутентификацию по паролю на no, то попытка войти в систему под этим именем удаленно практически невозможна без действительного ключа SSH. Насколько мне известно, я не думаю, что ключи ssh были взломаны, учитывая, что это зависит от шифра и сложности шифра, который вы используете для определения этого.

Итак, теперь этот факт упущен, если кто-то сумел получить доступ к этой учетной записи. Скорее всего, это будет означать, что кто-то, у кого уже был доступ к вашей системе, которому были предоставлены привилегии для использования su, сделал бы это, или каким-то образом, если вы должным образом заблокировали свою систему, кто-то получил доступ к root, что более невозможно, чем получить доступ к учетной записи git-server. Но если это не так, и они вошли в эту учетную запись удаленно с помощью SSH, то все, кто использует SSH, в беде, поскольку это будет означать, что любая система, использующая ssh, будет уязвима. Теперь максимальный ущерб, который может быть нанесен, - это тот же ущерб, который вы можете нанести с помощью своей обычной учетной записи с привилегиями sudo.

решение3

Некоторые переменные, которые следует задать, если есть необходимость следовать предложениям...

_git_user='git-user'
_git_group='git-devs'
_git_home_base="/srv/${_git_group}"
_client_certs_root='/home/admin/client-certs'

... который будет написан с точки зрения вашей учетной записи администратора сервера.

  1. Я создал пользователя 'git-server'

Вы случайно не заблокировали его и не сделали системной учетной записью?

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

Обратите внимание, если $(which git-shell)разрешается путь к файлу, но --shelloption выдает ошибки, то...

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

... может быть полезно добавить git-shellпуть к /etc/shellsфайлу

  1. Установленopenssh-server
  2. Изменено /etc/ssh/sshd_configдобавленоPasswordAuthentication no

Вы отключили?rootаутентификация по паролю через SSH?

/etc/ssh/sshd_configнемного информации, которая может быть полезна...

permitrootlogin without-password


## Additionally consider locking-down other unneeded features
Match Group git-devs
  AllowTcpForwarding no
  AllowStreamLocalForwarding no
  PermitOpen none
  1. Добавлено в .ssh/authorized_keysпубличное дело моих коллег

Куда именно вы добавили их открытые ключи?

Вот несколько примеров команд для настройки трех учетных записей Git...

declare -a _accounts_keys=(
    ["name-one"]="${_client_certs_root}/${_git_group}/name-one/ssh.pub"
    ["name-two"]="${_client_certs_root}/${_git_group}/name-two/ssh.pub"
    ["name-three"]="${_client_certs_root}/${_git_group}/name-three/ssh.pub"
)



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
EOF
done

Безопасен ли пользователь 'git-server' для моей системы? Какой наихудший сценарий для системы, если злоумышленник получит доступ к 'git-server', при условии, что 'git-server' являетсяsudoer

Нет, и если вы добавили ключи всех пользователей к одной и той же учетной записи, и эта учетная запись является sudoer, то суммакошмарное топливоЯ мог бы разрешить эту ситуацию практически безгранично...

Как запретить «git-server» все операции, кроме команд git?

Добавьте git-shell-commands/no-interactive-loginскрипт в каждую учетную запись Git...

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
EOF

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

... пока в каталоге нет других исполняемых файлов, git-shell-commandучетная запись будет ограничена неинтерактивными командами git; при условии, что оболочка учетной записи также настроена правильно.

Вышеуказанный вариант не самый безопасный, но он сбалансирован с удобством;

  • git-devsгруппа должна быть разной для каждой учетной записи, если перекрестное клонирование нежелательно, например, если бы они знали, как все структурировано на стороне сервера name-one(когда основная группа является общей для нескольких учетных записей) .git clone name-two@server:/srv/git-devs/name-two/project-name

Обратите внимание, если разрешения, в которых 600это можно было бы отключить для каждого проекта в рамках отдельной учетной записи, и если разрешения, в которых 660это позволило бы общей группе, pushа также pullрепозиторию... лично я считаю, 640что этолучшийиз обоих вариантов, поскольку это позволяет группе обмениваться кодом друг с другом, не опасаясь, что что-то git push -fиз другого аккаунта что-то испортит.

  • Для примеров других git-shell-commandsсценариев рассмотрите возможность проверкиgit-utilities/git-shell-commandsрепозиторий, откуда были адаптированы приведенные выше советы, хотя это было быкончиквещи еще больше приближаются к удобству.

Суммируянедобавьте приведенные выше скрипты, если вы не можете доверять клиентам и не хотите, чтобы они пыталисьпоп-а-ракушкапотому что такие вещи созданы так, чтонуждатьсядля интерактивной оболочки не так распространен.

Бонусные очки

  • ознакомьтесь man --pager='less -p "ChrootDirectory"' sshd_configс советами о том, что можно сделать для дополнительной защиты сервера SSH.

  • проверьте man git-shellи man git-daemonдля соответствующей документации; есть некоторые полезные опции как для блокировки вещей, так и для того, чтобы сделать сервер немного более удобным для связи, например, --strict-paths, --base-path=<path>, и --listen=<host_or_ipaddr>, возможно, стоит рассмотреть их подробнее

Если в вышеизложенном есть какие-либо сомнения, пожалуйста, оставьте комментарий, чтобы этот ответ можно было улучшить.

Связанный контент