Использование SSH-ключей в Gitlab CI |
[исправить] |
Многие хотят использовать ssh ключи в своих CI/CD (не одобряю), но давайте делать это правильно:
before_script:
- '[[ ! -d /root/.ssh ]] && mkdir /root/.ssh && chmod 700 /root/.ssh'
- '[[ -f /.dockerenv ]] && echo -e "Host *\\n\\tStrictHostKeyChecking no\\n\\n" > ~/.ssh/config'
- 'which ssh-agent || (yum install openssh-clients -y; yum clean all -y )'
- eval $(ssh-agent -s)
- ssh-add <(echo "$SSH_PRIVATE_KEY")
- mkdir -p ~/.ssh
В $SSH_PRIVATE_KEY устанавливаем "protected" переменную в интерфейсе самого
Gitlab (repo->settings->ci/cd-> vars )
Данный сниппет рассчитан на CentOS, но легко адаптируется по любую ОС, работает
в докер окружении (см. строку #2). При таком подходе больше нет нужды помещать
id_rsa в репозитории (ему там и не место).
|
|
|
|
Раздел: Корень / Безопасность / SSH |
1.2, pXeL (?), 10:10, 26/02/2020 [ответить]
| +/– |
были ситуации когда через агент очень не удобно работать с ключиком.
думаю кому надо, то тот и без этой трех-этажерки знает что делает :)))
| |
1.3, Аноним (3), 23:41, 27/02/2020 [ответить]
| +/– |
Самое главное ты забыл:
export SSH_PRIVATE_KEY=WIPED;
| |
|
|
3.7, Аноним (7), 10:34, 13/03/2020 [^] [^^] [^^^] [ответить]
| +/– |
Чтобы во время сборки нельзя было угнать ключ через /proc/$pid/environ.
| |
|
|
1.5, Дмитрий (??), 14:14, 11/03/2020 [ответить]
| +/– |
Есть намного проще вариант.
Добавляем ключ в CI переменных с именем SSH_KEY и типом "File"
chmod 600 "${SSH_KEY}"
ssh -i ${SSH_KEY} -o trictHostKeyChecking=no user@server "deploy cmd"
| |
|
2.8, Прыгающий Ленивец (?), 02:42, 22/03/2023 [^] [^^] [^^^] [ответить]
| +/– |
В этом варианте ключ оказывается на фс контейнера с раннером. В это время его оттуда можно прочитать да и после завершения пайплайна никто не обещал, что данные на диске не останутся. Правда вариант с ssh-add < (echo …) тож кривой, т.к. на время выполнения этой команды ключик будет красоваться в выводе ps, но тут оно хотя бы в персистентное хранилище не пишется
| |
|
|