Gitlab на защищенном сервере 2FA + openssh - PullRequest
0 голосов
/ 22 февраля 2019
System: Ubuntu 18.04.2 LTS Server 

Gitlab: 11.7.5-ee

У меня есть новый локальный сервер (установка для глубокого обучения), на котором также должен быть размещен Gitlab, поскольку эта машина может легко справиться с этим на стороне.

Сервер, конечно, должен быть максимально безопасным, поэтомуЯ изменил конфигурацию сервера, чтобы вход в систему был возможен только для ssh-key + google 2FA (в соответствии с этим уроком https://www.digitalocean.com/community/tutorials/how-to-set-up-multi-factor-authentication-for-ssh-on-ubuntu-16-04

Впоследствии установил gitlab и импортировал проект, настроил CI, добавил ssh-ключи. На веб-интерфейсе все работает отличнохорошо, также работают CI и web-portal-login снова 2FA работает как положено sidenote: сам Gitlab доступен только через внутренний IP (предназначен).

Локально я переключил ветки с помощью:

git remote set-url origin git@IP:USERNAME/REPOSITORY.git

НО, сейчас не работает ни клон, ни pull, ни push. Я (и все остальные пользователи) получаю:

git@IP's password:

Конечно, у меня нет этого пароля.

Создание

sudo gitlab-rake gitlab:check

Checking GitLab subtasks ...

Checking GitLab Shell ...

GitLab Shell: ... GitLab Shell version >= 8.4.4 ? ... OK (8.4.4)
Running /opt/gitlab/embedded/service/gitlab-shell/bin/check
Check GitLab API access: OK
Redis available via internal API: OK

Access to /var/opt/gitlab/.ssh/authorized_keys: OK
gitlab-shell self-check successful

Checking GitLab Shell ... Finished

Checking Gitaly ...

Gitaly: ... default ... OK

Checking Gitaly ... Finished

Checking Sidekiq ...

Sidekiq: ... Running? ... yes
Number of Sidekiq processes ... 1

Checking Sidekiq ... Finished

Checking Incoming Email ...

Incoming Email: ... Reply by email is disabled in config/gitlab.yml

Checking Incoming Email ... Finished

Checking LDAP ...

LDAP: ... LDAP is disabled in config/gitlab.yml

Checking LDAP ... Finished

Checking GitLab App ...

Git configured correctly? ... yes
Database config exists? ... yes
All migrations up? ... yes
Database contains orphaned GroupMembers? ... no
GitLab config exists? ... yes
GitLab config up to date? ... yes
Log directory writable? ... yes
Tmp directory writable? ... yes
Uploads directory exists? ... yes
Uploads directory has correct permissions? ... yes
Uploads directory tmp has correct permissions? ... yes
Init script exists? ... skipped (omnibus-gitlab has no init script)
Init script up-to-date? ... skipped (omnibus-gitlab has no init script)
Projects have namespace: ...
Administrator / salesbeat ... yes
Redis version >= 2.8.0? ... yes
Ruby version >= 2.3.5 ? ... yes (2.5.3)
Git version >= 2.18.0 ? ... yes (2.18.1)
Git user has default SSH configuration? ... yes
Active users: ... 4
Elasticsearch version 5.6 - 6.x? ... skipped (elasticsearch is disabled)

Checking GitLab App ... Finished


Checking GitLab subtasks ... Finished

Проверка через sh -Tv git@192.168.0.113

sh -Tv git@192.168.0.113
OpenSSH_7.6p1 Ubuntu-4, OpenSSL 1.0.2n  7 Dec 2017
debug1: Reading configuration data /home/user/.ssh/config
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: Connecting to 192.168.0.113 [192.168.0.113] port 22.
debug1: Connection established.
debug1: identity file /home/user/.ssh/id_rsa type 0
debug1: key_load_public: No such file or directory
debug1: identity file /home/user/.ssh/id_rsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/user/.ssh/id_dsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/user/.ssh/id_dsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/user/.ssh/id_ecdsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/user/.ssh/id_ecdsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/user/.ssh/id_ed25519 type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/user/.ssh/id_ed25519-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_7.6p1 Ubuntu-4
debug1: Remote protocol version 2.0, remote software version OpenSSH_7.6p1 Ubuntu-4ubuntu0.2
debug1: match: OpenSSH_7.6p1 Ubuntu-4ubuntu0.2 pat OpenSSH* compat 0x04000000
debug1: Authenticating to 192.168.0.113:22 as 'git'
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: curve25519-sha256
debug1: kex: host key algorithm: ecdsa-sha2-nistp256
debug1: kex: server->client cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none
debug1: kex: client->server cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ecdsa-sha2-nistp256 SHA256:TubIbvzKzAsDNbW4WYmmLss4Jo7q089SmJmhdvdyhl8
debug1: Host '192.168.0.113' is known and matches the ECDSA host key.
debug1: Found key in /home/user/.ssh/known_hosts:16
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_EXT_INFO received
debug1: kex_input_ext_info: server-sig-algs=<ssh-ed25519,ssh-rsa,rsa-sha2-256,rsa-sha2-512,ssh-dss,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521>
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Offering public key: RSA SHA256:8Nkt7JyhE9zQKv6EIXfSMRLgzg8dh+eSzuPqvrSgpLw /home/user/.ssh/id_rsa
debug1: Server accepts key: pkalg rsa-sha2-512 blen 535
Authenticated with partial success.
debug1: Authentications that can continue: password,keyboard-interactive
debug1: Next authentication method: keyboard-interactive
debug1: Authentications that can continue: password,keyboard-interactive
debug1: Next authentication method: password
git@192.168.0.113's password: 

Можетне найти решение и не хватаетидеи.Похоже, ключ обнаружен и предложен, но затем он переходит к следующему методу аутентификации: пароль. Единственная причина, по которой я могу придумать, - это 2FA от самого сервера, но я, очевидно, не могу отключить его из-за соображений безопасности.

1 Ответ

0 голосов
/ 22 февраля 2019

Ваш журнал SSH указывает, что шаг keyboard-interactive (который будет включать приглашение токена TOTP) на самом деле ничего не делал, возможно, это означает, что ваша настройка TOTP неверна или неполна.Эта часть обрабатывается libpam-google-authenticator;возможно, вам удастся найти дополнительные журналы в /var/log/auth.log (или в другом месте, в зависимости от настроек журналирования вашей системы).

Моя догадка: настройка, показанная в руководстве, создает файл .google_authenticator, убедитесь, что он оказался вправильное место (/var/opt/gitlab, если вы используете стандартные местоположения).

Поскольку это операция по устранению неполадок, я не могу дать полный ответ, но это должно дать вам еще несколько вещей для проверки.


Кроме того, просто напоследок, это, вероятно, невозможно сделать так, как вы себе представляете.

GitLab работает внутри, используя единую системную учетную запись git и связывая всеSSH ключи с этой учетной записью.Аутентификация через SSH с определенным открытым ключом позволяет GitLab определить, к какому пользователю GitLab этот ключ принадлежит, применить правильную идентификацию и авторизацию для вас на уровне приложения (т. Е. Для операций Git).

Модуль PAMдля Google Authenticator ничего не знает об этом.Он может связывать только один ключ TOTP для любой системной учетной записи, это означает, что все пользователи GitLab будут использовать одни и те же токены - это сильно снижает преимущество использования токенов TOTP.

Примечание:Я никогда не видел Git-сервер, который требовал бы TOTP в дополнение к аутентификации ключа SSH.Это также невероятно раздражает на практике, потому что это означает, что каждая операция Git будет запрашивать токен, тогда как при правильной настройке ключа SSH с ключевым агентом вам будет предлагаться только один раз в день (дать или взять).Возможно, вы захотите снизить свои стандарты и принять два фактора: зашифрованный ключ SSH и ключевую фразу (что, безусловно, является гораздо более высоким уровнем безопасности, чем просто пароль).

...