Многие хотят использовать 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 в репозитории (ему там и не место).
URL:
Обсуждается: http://www.opennet.dev/tips/info/3132.shtml
https://docs.gitlab.com/ee/ci/ssh_keys/
были ситуации когда через агент очень не удобно работать с ключиком.
думаю кому надо, то тот и без этой трех-этажерки знает что делает :)))
Самое главное ты забыл:
export SSH_PRIVATE_KEY=WIPED;
А для чего это ? все делается в настройках репы
Чтобы во время сборки нельзя было угнать ключ через /proc/$pid/environ.
Есть намного проще вариант.
Добавляем ключ в CI переменных с именем SSH_KEY и типом "File"chmod 600 "${SSH_KEY}"
ssh -i ${SSH_KEY} -o trictHostKeyChecking=no user@server "deploy cmd"
В этом варианте ключ оказывается на фс контейнера с раннером. В это время его оттуда можно прочитать да и после завершения пайплайна никто не обещал, что данные на диске не останутся. Правда вариант с ssh-add < (echo …) тож кривой, т.к. на время выполнения этой команды ключик будет красоваться в выводе ps, но тут оно хотя бы в персистентное хранилище не пишется
> StrictHostKeyChecking noЗа это бить надо.