Евгений Хлебников

гитлаб указан в тегах верно?
поместите эти параметры в CICD переменные (поддерживаются в том числе файлы, а так же маскировка секретов), лимитировав их использование конкретным ENV-ом
https://docs.gitlab.com/ci/environments/
ну и укажите в деплой шагах ENV-ы (можно брать из имени бранча динамически)
хранить в репе все таки не стоит

к серваку не будет доступа по ssh в рабочем режиме

если нет выхода - уходите через вход
если нельзя запушить апдейт на сервер, значит на сервере что-то должно пуллить обновления.
Это может быть скедулированный скрипт, забирающий артефакты из надежного места, проверяющий их подписи, раскладывающий по правильным местам и перезапускающий сервисы (если надо).
Это так же может быть некий агент, который будет отчитываться управляющему серверу (однако обычно именно сервер дает команду агенту на деплой, а без доступа - если закрыт ssh то и другие порты скорее всего будут недоступны, контур то закрытый - мы опять приходим к скедулированным процессам апдейта)

Опять же вызывает вопросы "закрытость" контура: закрыт он от доступа извне или доступ наружу изнутри контура тоже отсутствует? Как тогда предполагается доставлять изменения?

а откуда scp берет ключ?

• он не указан в команде через ключ -i
  
• в вопросе нет указаний на настройку конфига ssh чтобы указать ключ для этого хоста и пользователя
  

Ключ должен лежать на файловой системе и иметь права не больше 600, иначе scp и ssh будут ругаться "permissions are too open"

В соседнем ответе в комментариях добрались до истины: dynamic-child-pipelines
Есть определенные ограничения: типа лучше засовывать CI переменные в генерируемый пайплайн при его генерации, а так же есть определенные сложности при передаче артефактов генерируемых динамическим пайплайном обратно в общий CI.
Но если хочется делать однотипные пайплайны без копипасты блока в .gitlab-ci.yml то это - решение

Есть два варианта развития событий: вы распределяете последовательность выполнения по стейжам или рисуете свой граф выполнения
В первом случае последовательность стейжей важна - джобы параллелятся в рамках одного стейжа и следующий стейж не запустится пока не выполнятся все джобы предыдущего.
.pre всегда запускается перед пользовательскими стейжами,
Во втором - вы можете запланировать свой граф выполнения с помощью needs
Я не нашел в документации, что .pre все еще будет выполняться первой, если ее джобы участвуют в вашем собственном графе, так что возможно это решение. В случае использования needs (и gitlab 14.2+ или gitlab.com 14.1) можно вообще не прописывать стейжи. В случае gitlab <=14.0 стейжи все еще нужны, потому что needs не будет работать с джобами одного стейжа.
Внимательно прочитайте требования к needs https://docs.gitlab.com/ee/ci/yaml/#requirements-a... соответственно вашей версии gitlab

внимательно прочитайте https://docs.gitlab.com/runner/executors/docker_ma...
поставили форк docker-machine?