GitLab CI: SSH विफल, निजी कुंजी को प्रमाणित करने में असमर्थ
मैंने Gitlab-CI में अपने सर्वर पर SSH की कोशिश करने के लिए इस लिंक का अनुसरण किया । SSH कुंजी के लिए, मैं सर्वर में चला गया, और सार्वजनिक और निजी कुंजी उत्पन्न करता हूं। निजी कुंजी GitLab CI / CD env चर में निकाली गई है।
YAML टेम्प्लेट नीचे दिया गया है, अधिकतर लिंक से कॉपी किया गया है।
image: docker:19.03.8
services:
- docker:19.03.8-dind
deployment:
variables:
ip: <ip-address>
script:
- apk add --update openssh-client sshpass
- eval $(ssh-agent -s) - echo "$SSH_PRIVATE_KEY" | ssh-add - > /dev/null
- mkdir -p ~/.ssh
- chmod 700 ~/.ssh
- export SSHPASS=$AWS_PASSWORD - sshpass -e ssh -o StrictHostKeyChecking=no -vvv ubuntu@$ip echo testing
हालाँकि, मुझे निजी कुंजी तक पहुँचने की कोशिश में एक त्रुटि का सामना करना पड़ा।
debug1: Authentications that can continue: publickey,password
debug1: Trying private key: /root/.ssh/id_rsa
debug3: no such identity: /root/.ssh/id_rsa: No such file or directory
debug1: Trying private key: /root/.ssh/id_dsa
debug3: no such identity: /root/.ssh/id_dsa: No such file or directory
debug1: Trying private key: /root/.ssh/id_ecdsa
debug3: no such identity: /root/.ssh/id_ecdsa: No such file or directory
debug1: Trying private key: /root/.ssh/id_ed25519
debug3: no such identity: /root/.ssh/id_ed25519: No such file or directory
debug1: Trying private key: /root/.ssh/id_xmss
debug3: no such identity: /root/.ssh/id_xmss: No such file or directory
debug2: we did not send a packet, disable method
debug3: authmethod_lookup password
debug3: remaining preferred: ,password
debug3: authmethod_is_enabled password
debug1: Next authentication method: password
debug3: send packet: type 50
debug2: we sent a password packet, wait for reply
debug3: receive packet: type 51
debug1: Authentications that can continue: publickey,password
Permission denied, please try again.
मैं gitlab साझा धावकों का उपयोग कर रहा हूँ, अगर वह मदद करता है।
[अपडेट करें]
उस सर्वर में जोड़ना भूल गया जिसे मैं कनेक्ट करना चाहता हूं, मैंने फाइलों id_rsa.pub
में उत्पन्न सार्वजनिक कुंजी को जोड़ा authorized_keys
।
[संपादित करें 1]
जैसा कि सुझाव दिया गया है, मैंने आउटपुट होस्ट को SSH_KNOWN_GAS चर के रूप में कॉपी करने के लिए ssh-keycan का उपयोग करके ज्ञात होस्ट को जोड़ा है। अद्यतन yaml फ़ाइल के नीचे। हालाँकि मुझे उसी त्रुटि का सामना करना पड़ा।
deployment:
variables:
ip: <ip-address>
script:
- apk add --update openssh-client sshpass
- eval $(ssh-agent -s)
- echo "$SSH_PRIVATE_KEY" | ssh-add - > /dev/null - mkdir -p ~/.ssh - chmod 700 ~/.ssh - touch ~/.ssh/known_hosts - echo "$SSH_KNOWN_HOSTS" >> ~/.ssh/known_hosts
- chmod 644 ~/.ssh/known_hosts
- export SSHPASS=$AWS_PASSWORD - sshpass -e ssh -o StrictHostKeyChecking=no -vvv ubuntu@$ip echo testing
जवाब
मुझे यकीन नहीं है sshpass
, क्योंकि मैं आमतौर पर सार्वजनिक / निजी कुंजी का उपयोग करता हूं। यहां एक नौकरी का एक उदाहरण है जिसे मैं दूरस्थ सर्वर पर चलाने SCP
/ SSH
कमांड करने के लिए सेटअप करूंगा :
deploy:
stage: deploy
variables:
hostname: app-dev
before_script:
# optional step if you decide to use a hostname instead of IP address
- cp -f ./network/etc/hosts /etc/hosts
# Setup SSH
- which ssh-agent || ( apt-get update -y && apt-get install openssh-client -y )
- eval $(ssh-agent -s) - ssh-add <(cat $SSH_PRIVATE_KEY)
- mkdir -p ~/.ssh
- chmod 700 ~/.ssh
- ssh-keyscan $HOSTNAME >> ~/.ssh/known_hosts - chmod 644 ~/.ssh/known_hosts script: # Copy files and execute commands - scp ./scripts/install_package.sh root@$HOSTNAME:/tmp/deploy
- ssh root@$HOSTNAME "/tmp/deploy/install_package.sh && exit"
पाइपलाइन चलाने से पहले , आपको निम्नलिखित कार्य करने होंगे:
- का उपयोग कर ssh प्रमुख जोड़े उत्पन्न करें
ssh-keygen
। एक पासफ़्रेज़ का उपयोग न करें। सार्वजनिक कुंजी समाप्त होती है.pub
, निजी कुंजी का कोई विस्तार नहीं होता है। - दूरस्थ सर्वर पर SSH, सार्वजनिक कुंजी की सामग्री की प्रतिलिपि बनाएँ
~/.ssh/authorized_keys
- GitLab फ़ाइल पर्यावरण चर नामक अपनी निजी कुंजी की सामग्री की प्रतिलिपि बनाएँ
SSH_PRIVATE_KEY
- यदि आप एक
$HOSTNAME
पर्यावरण चर का उपयोग करते हैं, तो अपनी पाइपलाइन में चर को परिभाषित करें और/etc/hosts
अपने पाइपलाइन कंटेनर में फ़ाइल में आईपी / होस्टनाम जोड़ें । अन्यथा, इसके बजाय केवल एक आईपी पते का उपयोग करें।