2016-11-12 6 views
2

Сначала я пытался использовать возможность для развертывания после создания gitlab CI, но в результате он отображает «хост недостижимый».В Gitlab CI build, я не могу ssh в AWS EC2 по закрытому ключу

После некоторых проб и ошибок я выяснил, что проблема заключается в разрешении ssh, когда ssh с помощью закрытого ключа в мой экземпляр AWS EC2 развертывается.

Мой .gitlab-ci.yml конфигурации что-то вроде этого:

.gitlab-ci.yml

image: ansible/ubuntu14.04-ansible:stable 

stages: 
    - deploy 

deploy_web: 
    stage: deploy 
    script: 
    - "echo Ansible" 
    - "echo Environment: ${ENV}" 
    - "echo TAG: ${TAG}" 

    - "echo ${VAULT_PASS} > vault_pass.txt" 
    - "mkdir sshkey" 
    - "echo ${SSH_KEY_APP} > ./sshkey/app-key.pem" 
    - "chmod 600 ./sshkey/app-key.pem" 
    - "export SSH_KEY_DIR=`pwd`/sshkey" 
    - "export ANSIBLE_HOST_KEY_CHECKING=False" 
    - "ssh-keyscan foobar.io >> ~/.ssh/known_hosts" 
    - "ssh -v -i ./sshkey/app-key.pem [email protected]" // for debugging 

    - "ansible-playbook -i ${ENV} servers.yml --vault-password-file vault_pass.txt -vvvv --tags=${TAG}" 

Когда gitlab CI строит это, в основном дает эти сообщения об ошибках SSH:

OpenSSH_6.6.1, OpenSSL 1.0.1f 6 Jan 2014 
debug1: Reading configuration data /etc/ssh/ssh_config 
debug1: /etc/ssh/ssh_config line 19: Applying options for * 
Pseudo-terminal will not be allocated because stdin is not a terminal. 
debug1: Connecting to foobar.io [12.34.56.78] port 22. 
debug1: Connection established. 
debug1: permanently_set_uid: 0/0 
debug1: identity file ./sshkey/app-key.pem type -1 
debug1: identity file ./sshkey/app-key.pem-cert type -1 
debug1: Enabling compatibility mode for protocol 2.0 
debug1: Local version string SSH-2.0-OpenSSH_6.6.1p1 Ubuntu-2ubuntu2.3 
debug1: Remote protocol version 2.0, remote software version OpenSSH_6.6.1p1 Ubuntu-2ubuntu2.7 
debug1: match: OpenSSH_6.6.1p1 Ubuntu-2ubuntu2.7 pat OpenSSH_6.6.1* compat 0x04000000 
debug1: SSH2_MSG_KEXINIT sent 
debug1: SSH2_MSG_KEXINIT received 
debug1: kex: server->client aes128-ctr [email protected] none 
debug1: kex: client->server aes128-ctr [email protected] none 
debug1: sending SSH2_MSG_KEX_ECDH_INIT 
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY 
debug1: Server host key: ECDSA be:b1:53:76:aa:bf:65:ea:b4:1b:7a:8f:cc:7c:2a:79 
debug1: Host 'foobar.io' is known and matches the ECDSA host key. 
debug1: Found key in /root/.ssh/known_hosts:2 
Warning: Permanently added the ECDSA host key for IP address '12.34.56.78' to the list of known hosts. 
debug1: ssh_ecdsa_verify: signature correct 
debug1: SSH2_MSG_NEWKEYS sent 
debug1: expecting SSH2_MSG_NEWKEYS 
debug1: SSH2_MSG_NEWKEYS received 
debug1: Roaming not allowed by server 
debug1: SSH2_MSG_SERVICE_REQUEST sent 
debug1: SSH2_MSG_SERVICE_ACCEPT received 
debug1: Authentications that can continue: publickey 
debug1: Next authentication method: publickey 
debug1: Trying private key: ./sshkey/app-key.pem 
debug1: key_parse_private2: missing begin marker 
debug1: key_parse_private_pem: PEM_read_PrivateKey failed 
debug1: read PEM private key done: type <unknown> 
debug1: read_passphrase: can't open /dev/tty: No such device or address 
debug1: No more authentication methods to try. 

Permission denied (publickey). 

пытался Кроме того, используя абсолютный путь:

$ cat /builds/foobar/bar/sshkey/app-key.pem 
-----BEGIN RSA PRIVATE KEY----- 
...(the key)... 
-----END RSA PRIVATE KEY----- 

$ ssh -v -i /builds/foobar/bar/sshkey/app-key.pem [email protected] 
Permission denied (publickey). 

Это то, что я пробовал:

  • попробуйте использовать оболочку исполнителя для gitlab CI бегуна ->не удалось
  • запускать скрипты в локальном контейнере Докер ->успех
  • SSH (не через CI) и запустить сценарии в оболочке ->Успех
  • ssh в runner instan в.п. вручную и запустить скрипты в Докер контейнере ->успех

В заключение - это не удается только при ведении gitlab CI, поэтому мне интересно, если есть какие-либо дополнительные настройки я не заметил, чтобы делать вещи как это ...

Большое спасибо всем, кто может помочь!

Реальная проблема заключается в

Когда эхо-ки многострочный переменной среды, необходимы кавычки. Таким образом, каждая строка ключа заканчивается символом^M, который корректно отображается в консоли gitlab, но фактически не может быть проанализирован ssh.

ответ

2

Если это не удается при запуске GilabCI, это означает, что пользователь, используемый GitLab CI, не совпадает с тем, который использовался при запуске ssh в исполняемом экземпляре.

Смотри, например, "AWS SSH connection error: Permission denied (publickey)"

Другая вещь, чтобы проверить это PermitRootLogin и AllowUsers в /etc/ssh/sshd_config.

Это debug1: key_parse_private2: missing begin marker appears даже после успешной авторизации ключа, если ваш пользователь ограничен.

Проверка после вручную SSH на удаленном компьютере:

tail -f -n 80 /var/log/auth.log 

OP DarkBtf добавляет in the comments:

Когда эхо-ки многострочный переменной среды, необходимы кавычки.
Таким образом, каждая строка ключа заканчивается ^M, которая корректно отображается в консоли gitlab, но фактически не может быть проанализирована ssh.

+0

При использовании исполнителя gklab CI docker пользователь является root. Я не ввел ключ в .ssh, поэтому я указал идентификатор как «-i app-key.pem» в команде ssh. Есть ли проблемы для этого? – DarkBtf

+0

@DarkBtf Единственная проблема: «где app-key.pem»? Не могли бы вы попытаться с абсолютным путем (и добавить команду, которая гарантирует, что абсолютный путь будет видимым, например 'cat/full/path/to/app-key.pem') – VonC

+0

Я пробовал использовать абсолютный путь (редактирование основного сообщения), все еще разрешение отклонено. – DarkBtf