Error loading key stdin error in libcrypto

ssh: Error loading key «./id_rsa»: invalid format

For some reason one of my ssh keys «just broke» — it just stopped working:

Copying the key inside a clean VM, the key does work. Even with the exact same ssh version (OpenSSH_7.8p1, OpenSSL 1.1.0i-fips 14 Aug 2018 on Fedora 28). So it must be related to some config on my system I assume.

Also peculiar: GNOME somehow manages to add the key on login with seahorse. Then ssh-add -L does list the key but it is not usable:

8 Answers 8

Traditionally OpenSSH used the same private key format is identical to the older PEM format used by OpenSSL. (Because it uses OpenSSL for parsing the key, it will accept the newer PKCS#8 format as well.)

So the issue can be one of:

Your OpenSSL version refuses to load this key format. Perhaps it has accidentally enabled FIPS mode and refuses any algorithms except those part of its original FIPS validation?

Try loading the key into the openssl command-line tool (which, yes, might also be linked to a different libcrypto, and you should check with ldd):

Try converting it to PKCS#8 format:

Your OpenSSH has been built without OpenSSL support. Even though ssh -V says the support was enabled, that does not automatically mean the ssh-add binary is the same – it might come from a different partial installation.

Use type -a ssh and type -a ssh-add to compare installation locations.

Once you know the path, use ldd /usr/bin/ssh-add to verify that it’s linked to libcrypto.so (the OpenSSL cryptographic library).

If nothing works at all, try converting your key to the new OpenSSH-proprietary format using. PuTTY. Install the putty package for Fedora, and use:

Also peculiar: GNOME somehow manages to add the key on login with seahorse.

Older GNOME Keyring versions have an internal copy of the SSH agent code and are independent from the system OpenSSH. So they will accept keys that your OpenSSH won’t. (But on the other hand, this means severe lagging in terms of feature support (such as Ed25519 keys), and the latest GNOME Keyring just uses the system ssh-agent instead.)

Источник

gitlab-ci SSH key invalid format

Questions : gitlab-ci SSH key invalid format

I would like run deploy script with gitlab-ci, but step ssh-add $SSH_PRIVATE_KEY return an error :

You can see my .gitlab-ci.yml :

On my project setting, i’ve been add SSH_PRIVATE_KEY variable, with the id_rsa from my production server cat

Anyone can help me ?

Answers 1 : of gitlab-ci SSH key invalid format

In my case, it was because I had made my SSH_PRIVATE_KEY variable protected. When I disabled the Protected state, it worked without any error.

Answers 2 : of gitlab-ci SSH key invalid format

In my case I had to put a new line at the end of the SSH_PRIVATE_KEY variable

Answers 3 : of gitlab-ci SSH key invalid format

I made a stupid mistake and added the key without ——BEGIN RSA PRIVATE KEY—— and ——END RSA PRIVATE KEY—— clauses.

Summing up, you should add:

Also, ensure the newline after the closing is present.

Answers 4 : of gitlab-ci SSH key invalid format

It works with variable expansion (curly brackets in double string quotation):

While keeping the SSH_PRIVATE_KEY variable protected!

This approach is simply a less ambiguous method for printing variables; in this case it prevents trimming of the last line break.

Answers 5 : of gitlab-ci SSH key invalid format

It is the SSH public key in

/.ssh/id_rsa.pub by default.

The private key is contained in

Answers 6 : of gitlab-ci SSH key invalid format

If you export key from PuTTYgen, to get key content use its command Conversations — Export OpenSSH key (force new file format)

And trim last spaces and add new line.

Answers 7 : of gitlab-ci SSH key invalid format

You must copy the entire contents of the file(id_rsa), including the final blank line. I solve the problem this way.

Answers 8 : of gitlab-ci SSH key invalid format

Make sure that the newline after the end of the file variable is present. If not, the following error would have appeared:

The ID_RSA was my file variable in this example.

Answers 9 : of gitlab-ci SSH key invalid format

I got it working with a protected variable.

If the variable is file, echo won’t work anymore:

Otherwise; if variable is NOT file, use the following:

Answers 10 : of gitlab-ci SSH key invalid format

for all people reaching this post not finding a solution yet.

Try to make the branch protected, because its a must for protected variables.

Protected: Only exposed to protected branches or protected tags.

Add a CI/CD variable to a project

Answers 11 : of gitlab-ci SSH key invalid format

In my case, it was because I had made my SSH_PRIVATE_KEY variable available in a specific enviroment. I changed it to the one I was using (or you can change it to All, depending on your setup).

Answers 12 : of gitlab-ci SSH key invalid format

I had this issue on gitlab and bitbucket, both were solved adding a n by the end of the key file.

Answers 13 : of gitlab-ci SSH key invalid format

it possible you didn’t copy the content of the public key to the authorized_keys

Answers 14 : of gitlab-ci SSH key invalid format

I had the same problem and after spending some hours trying to understand what was wrong I found that my private key was encrypted (and my computer had the password in cache for so long that I had forgotten that it was encrypted). It’s not so easy to understand if it’s encrypted or not by just looking at the key. You should decrypt the key (set an empty password) and then paste it on a GitLab variable. Then in your .gitlab-ci.yml you can have a similar configuration:

*** Note that if you don’t want to write the key in a file, you can just put it inside the ssh agent with:

*** Note 2: In the Gitlab panel, make sure you have created a variable (and not a file); normally, it should be protected if you want to make it visible in the main branch.

*** Important: For security reasons change the following line:

putting only your host/s (and don’t permit all connections like this). If you put:

when connecting to any host, the ssh-agent will not check the signature and this can be a big vulnerability!

Источник

SSH Key Format Issues and Fixing the “invalid format” Error

Last modified: November 30, 2022

1. Introduction

Due to the widespread use of asymmetric cryptography, end users can employ and leverage it more easily. Still, even the ubiquitous Secure Shell (SSH) algorithm isn’t resistant to user mistakes.

In this tutorial, we talk about issues with the format of keys when establishing an SSH session. First, we generate a sample key pair. Next, we discuss key authorization and the pitfalls around it. After that, we consider reasons for supplying an incorrect identity by mistake when authenticating. Finally, we discuss proper handling to avoid key format issues.

For brevity and security reasons, we only consider the newest iteration of SSH version 2 (SSHv2) implemented by OpenSSH.

We tested the code in this tutorial on Debian 11 (Bullseye) with GNU Bash 5.1.4. It should work in most POSIX-compliant environments.

2. Generate Key Pair

Notably, we use a non-standard path instead of the usual $HOME/.ssh.

At this point, we have one example set of two keys:

• private key: /non-standard/id_rsa
• public key: /non-standard/id_rsa.pub

Critically, we require the correct permissions for each key:

Following chmod for restricting access to our keys, let’s output them with cat:

After generating a pair, we can explore potential format issues with the use of our new keys for public key authentication.

Usually, we add the public key to the authorized_keys file for our user with a dedicated tool or directly.

3.1. ssh-copy-id

Let’s see how to authorize a key with ssh-copy-id:

Due to our non-standard path outside $HOME/.ssh, ssh-copy-id can’t automatically locate the local keys. Hence, we use the -i argument to specify /non-standard/id_rsa as we did during generation:

Here, ssh-copy-id appends the .pub suffix automatically. Further, when our keys are in their standard location, ssh-copy-id uses the public key (id_rsa.pub) by default.

These mechanisms prevent mistakes when authorizing the key.

3.2. Manual Key Authorization Problems

Unlike ssh-copy-id, the cat command doesn’t perform any checks:

In this case, it might not be easy to spot the problem: supplying /non-standard/id_rsa doesn’t self-rectify to /non-standard/id_rsa.pub, meaning we incorrectly place our private key in the authorized_keys file, resulting in several problems:

• the format of authorized_keys is now invalid, so public key authentication seizes to work for our user
• our private key is exposed in a public file
• the key isn’t authorized

Because of these potential security holes, it’s highly recommended to use ssh-copy-id and the default SSH key paths.

4. Using the Correct Key

Another common problem with public key authentication is the identity file we supply during session setup.

In particular, we might mix up the private and public keys:

If we supply the public instead of the private key as the identity during session establishment, our SSH client tells us that the format is invalid. Of course, the same would happen for any file that’s not a private key in the proper format:

Depending on the key pair naming scheme, this error might not be very helpful. Also, we can experience issues even with the proper key file if we tamper with the format.

5. Handling Keys Properly

Of course, mishandling sensitive and strictly structured data such as SSH keys can lead to security issues.

5.1. Key Naming

The default names of public and private keys depend on the exact key type. For example, when using RSA, the defaults are id_rsa and id_rsa.pub, respectively.

In most cases, the public key has the name of the private key but with a .pub extension. In fact, the .pub suffix can be critical for the correct key detection and use. Moreover, preserving the proper naming scheme can be vital in general.

This is especially important when transferring key data.

5.2. Key Transfer and Streaming

When relocating key content, any formatting must be preserved along with the data. In other words, no changes to the key contents are allowed apart from the public key comments.

While the public key is usually a single line, private keys are longer and spread across multiple lines, so they are more prone to issues:

After confirming the current format of our private key with cat, we use the same command in a subshell to assign that to a variable. At this point, we lose the newlines since we don’t use quotes around $(). Thus, the $prk variable contains an incorrect value, which we transfer to /non-standard/id_rsa_bad.

Finally, using that key as an identity results in an invalid format error. Naturally, any other reason for bad formatting will result in the same.

6. Summary

In this article, we looked at common causes for malformed SSH keys, as well as their consequences.

In conclusion, although we can generate and use key pairs fairly easily, there are ways to do it incorrectly and methods to avoid such mistakes.

If you have a few years of experience in the Linux ecosystem, and you’re interested in sharing that experience with the community, have a look at our Contribution Guidelines.

Источник

ssh: ошибка загрузки ключа»./ id rsa»: неверный формат

Почему-то один из моих ssh ключей «просто сломался» — он просто перестал работать:

копировать ключ внутри чистый ВМ, ключ работает. Даже с точно такой же версией ssh (OpenSSH_7.8p1, OpenSSL 1.1.0 i-fips 14 Aug 2018 в Fedora 28). Поэтому оно должно быть связано с некоторым config на моей системе я предполагаю.

также своеобразно: GNOME каким-то образом умудряется добавлять ключ на логин с seahorse. Тогда ssh-add -L перечислены ключ, но это не используется:

1 ответов

традиционно OpenSSH использовал тот же формат закрытого ключа, что и более старый формат PEM, используемый OpenSSL. (Поскольку он использует OpenSSL для разбора ключа, он также принимает новый формат PKCS#8.)

так что вопрос может быть один из:

ваша версия OpenSSL не загружает этот формат ключа. Возможно, он случайно включил режим FIPS и отказывается от любых алгоритмов, кроме тех, которые являются частью его первоначальной проверки FIPS?

попробуйте загрузить ключ в openssl инструмент командной строки (который, Да, также может быть связан с другим libcrypto, и вы должны проверить с ldd):

попробуйте преобразовать его в формат PKCS#8:

ваш OpenSSH был построен без поддержки OpenSSL. Хотя бы ssh -V говорит, что поддержка была включена, что не означает the ssh-add двоичный то же самое – это может произойти из другой частичной установки.

использовать type -a ssh и type -a ssh-add для сравнения мест установки.

как только вы знаете путь, используйте ldd /usr/bin/ssh-add чтобы убедиться, что он связан с libcrypto.so (криптографическая библиотека OpenSSL).

если ничего не работает, попробуйте преобразовать ключ в новый формат OpenSSH. замазка. Установите putty пакет для Fedora, и использование:

также своеобразно: GNOME каким-то образом умудряется добавлять ключ на логин с seahorse.

более старые версии Gnome Keyring имеют внутреннюю копию кода агента SSH и независимы от системы OpenSSH. Таким образом, они будут принимать ключи, которые ваш OpenSSH не будет. (Но, с другой стороны, это означает серьезное отставание с точки зрения поддержки функций (таких как ключи Ed25519), а последний Gnome Keyring просто использует систему вместо этого ssh-агент.)

Источник

SSH Внезапно возвращается неверный формат

Некоторое время назад я настроил сервер на AWS и использовал их сгенерированный ключ SSH. Я сохранил ключ в Lastpass и успешно извлек его оттуда, и он заработал. Однако, попробовав сегодня снова, я не могу заставить его работать.

-rw——- 1 itsgreg users 1674 Jun 6 12:51 key_name

Я пробовал ssh -i key_name , ssh-keygen -f key_name но ничего не работает, я всегда получаю это сообщение об ошибке:

Load key «key_name»: invalid format

Есть ли способ это исправить?

Проверьте содержимое key_name , если агент говорит invalid format , что с ключом что-то не так — как . Вы уверены, что это правильный ключ? Даже если вам нужен не секретный ключ, агент ssh не вернется, invalid format если ключ работает, вы просто не сможете подключиться. Возможно, вы по какой-то причине поместили туда свой открытый ключ. Проверь это!

Что я сделал, чтобы исправить эту проблему, так это то, что я использую для преобразования PPK-файл, используя PuttyGen .

Сначала загрузите urkey.PPK , затем в меню конвертации выберите экспорт в формат файла Openssh. Это создаст файл newkey.

в настоящее время, ssh -i «newkey» user@127.0.0.1

Выполнено. Надеюсь, это поможет.

Я просил openssh использовать определенный файл идентификации, указав его в файле .ssh / config.

Исходная рабочая конфигурация имела

Это перестало работать без каких-либо изменений. Немного подумав, я заменил «путь к файлу открытого ключа» выше на «путь к файлу закрытого ключа». Это сработало. Причина заключается в том, что файлы открытого и закрытого ключей имеют большие числа, связанные с преступным преступлением, согласно алгоритму RSA. Если вы замените файл закрытого ключа файлом открытого ключа, эти криптографические числа не будут правильно извлечены из блока base64, сохраненного в файлах ключей. Кажется, некоторые версии ssh могут определить расширение .pub и использовать его для определения правильного файла закрытого ключа — а другие версии этого не делают. Это еще один способ, которым эта ошибка может произойти. Надеюсь, это кому-нибудь поможет.

У меня была та же проблема, и оказалось, что у меня в файле по какой-то причине были разделители строк в стиле Windows (CRLF).

Кроме того, файл должен заканчиваться одним LF.

Починить эти сделанные вещи снова.

Вы должны преобразовать ваш ключ .ppk в ключ OpenSSH

Вот как вы это делаете :

1. Загрузите PuttyGen и создайте свою пару ключей (если у вас нет готовой пары ключей). Сохраните закрытый ключ в вашу папку (.ppk)
2. Если у вас уже есть закрытый ключ, загрузите файл закрытого ключа (.ppk), нажав кнопку «Загрузить». В противном случае пропустите этот шаг
3. В меню «Конверсии» выберите «Экспортировать ключ OpenSSH» и сохраните его в своей папке.
4. Теперь вы готовы использовать ключ для входа на сервер без ввода пароля (я предполагаю, что вы уже поместили открытый ключ в /root/.ssh/authorized_keys, chmod 600 /root/.ssh/authorized_keys и перезапущенный демон SSH)

Я только что столкнулся с этим сегодня, когда писал несколько утилит git tagging для моего конвейера CI.

Вот разница между моими двумя ключами:

Я изменил свой код так:

И теперь мой ключ ssh работает.

TL; DR — Я думаю, у вас должен быть символ новой строки в конце вашего закрытого ключа.

Источник

According to the docs at
https://docs.gitlab.com/ee/ci/ssh_keys/

I can add a private ssh key as CI Variable and add it for my pipeline with

- eval $(ssh-agent -s)
- echo "$SSH_PRIVATE_KEY" | tr -d 'r' | ssh-add -

However, I get an error

Error loading key «(stdin)»: incomplete message

I used following command to generate the key pair:

ssh-keygen -t rsa -b 2048

and tried several things to resolve the issue:

a) With and without blank line at the end of the variable
b) Change type of variable to file
c) Change the way the key is generated (different -t and -b options)
d) First write to file and then add from file
e) Change encoding
f) Edit /etc/ssh/ssh_config and add the lines

HostKeyAlgorithms +ssh-rsa
PubkeyAcceptedKeyTypes +ssh-rsa 

=> Could not solve the issue until now.

Related question:

Error loading key «(stdin)»: invalid format Gitlab CI

Some alternative commands that did not work:

echo "$SSH_PRIVATE_KEY" | tr -d 'r' | ssh-add - > /dev/null

echo "$SSH_PRIVATE_KEY" | base64 -d | ssh-add -

Another error message that I got while trying:

Error loading key «(stdin)»: error in libcrypto

Edit

As a workaround, instead of adding the private key as CI variable, I use a shell executor and manually logged in on the gitlab runner host, changed user to «gitlab-runner» and established an ssh connection. My corresponding CI Job looks like this (you need to replace remote-server.de and user@remote-server.de):

job_back_end_deploy:
  stage: deploy
  #variables:
  #  CI_DEBUG_TRACE: "true"  # uncomment this to get more detailed console output
  before_script:
  # In order for this to work, an SSH connection already needs to be manually prepared
  # between the user "gitlab-runner" on the host of the gitlab-runner and on the target server
  # you would like to connect to
  # Also see https://docs.gitlab.com/ee/ci/ssh_keys/#ssh-keys-when-using-the-shell-executor
  # -------------------------------------
  ## change to user "gitlab-runner"
  # su - gitlab-runner
  ## generate ssh key-pair
  # ssh-keygen -t rsa -b 2048
  ## copy public key to the remote server you would like to connect to (asks for password)
  # ssh-copy-id -p 222 -i /home/gitlab-runner/.ssh/id_rsa.pub user@remote-server.de
  # -----------------------------  
  #
  # verify SSH host keys, also see
  # https://docs.gitlab.com/ee/ci/ssh_keys/#verifying-the-ssh-host-keys
  - ssh-keyscan 'remote-server.de' >> ~/.ssh/known_hosts
  script:    
  - echo 'Copying files to remote server...'
  - scp -P 222 -r ./back_end/ user@remote-server.de:./public_html/back_end/   # add -v option to see more output if you want
  tags:
    - visualization 

ssh: ошибка загрузки ключа»./ id rsa»: неверный формат

Почему-то один из моих ssh ключей «просто сломался» — он просто перестал работать:

копировать ключ внутри чистый ВМ, ключ работает. Даже с точно такой же версией ssh (OpenSSH_7.8p1, OpenSSL 1.1.0 i-fips 14 Aug 2018 в Fedora 28). Поэтому оно должно быть связано с некоторым config на моей системе я предполагаю.

также своеобразно: GNOME каким-то образом умудряется добавлять ключ на логин с seahorse. Тогда ssh-add -L перечислены ключ, но это не используется:

1 ответов

традиционно OpenSSH использовал тот же формат закрытого ключа, что и более старый формат PEM, используемый OpenSSL. (Поскольку он использует OpenSSL для разбора ключа, он также принимает новый формат PKCS#8.)

так что вопрос может быть один из:

ваша версия OpenSSL не загружает этот формат ключа. Возможно, он случайно включил режим FIPS и отказывается от любых алгоритмов, кроме тех, которые являются частью его первоначальной проверки FIPS?

попробуйте загрузить ключ в openssl инструмент командной строки (который, Да, также может быть связан с другим libcrypto, и вы должны проверить с ldd):

попробуйте преобразовать его в формат PKCS#8:

ваш OpenSSH был построен без поддержки OpenSSL. Хотя бы ssh -V говорит, что поддержка была включена, что не означает the ssh-add двоичный то же самое – это может произойти из другой частичной установки.

использовать type -a ssh и type -a ssh-add для сравнения мест установки.

как только вы знаете путь, используйте ldd /usr/bin/ssh-add чтобы убедиться, что он связан с libcrypto.so (криптографическая библиотека OpenSSL).

если ничего не работает, попробуйте преобразовать ключ в новый формат OpenSSH. замазка. Установите putty пакет для Fedora, и использование:

также своеобразно: GNOME каким-то образом умудряется добавлять ключ на логин с seahorse.

более старые версии Gnome Keyring имеют внутреннюю копию кода агента SSH и независимы от системы OpenSSH. Таким образом, они будут принимать ключи, которые ваш OpenSSH не будет. (Но, с другой стороны, это означает серьезное отставание с точки зрения поддержки функций (таких как ключи Ed25519), а последний Gnome Keyring просто использует систему вместо этого ssh-агент.)

Источник

I tried this action and in the output for the adding ssh-agent step, I see the following message for each key i added:

My comments are in the format git@github.com:Myorg/myrepo.git . I tried it with and without quotes.

Why doesn’t it work?

The text was updated successfully, but these errors were encountered:

Similar issue here. I’m using the same format for the comment, the command is something like ssh-keygen -C «git@github.com:org/repo.git» .
Not sure what’s going on and can’t find alternatives.

I am also not sure where this is coming from, but others reported similar issues before… the key comment seems to be (stdin) (sic!) only.

Can you load your keys into a ssh-agent running locally and then list keys with ssh-add -l ? Does that show the same comment?

With which command did you create keys, and which tool/platform/SSH implementation did you use?

#76 and #88 are similar, but were closed before we could find the root issue and/or document what to watch out for.

the command i used was

ssh-add -l does not show the comment, but should it? the comment is on the public key. i wasn’t aware that private keys could have comments.

By the way, I was following another similar issue, where the poster said he switched from a PEM to an openssh key which got him further, so I tried to convert the PEM key to OpenSSH and it seemed to work

I had tried it previously but it didn’t authenticate, but I think that might have been because I forgot to update the pub key after switching to OpenSSH. With GitHub this is several steps to test different options and very easy to make a mistake 🙁

So maybe this problem can be solved by updating the documentation and removing the PEM mention and switch to OpenSSH?

Источник

SSH Внезапно возвращается неверный формат

Некоторое время назад я настроил сервер на AWS и использовал их сгенерированный ключ SSH. Я сохранил ключ в Lastpass и успешно извлек его оттуда, и он заработал. Однако, попробовав сегодня снова, я не могу заставить его работать.

-rw——- 1 itsgreg users 1674 Jun 6 12:51 key_name

Я пробовал ssh -i key_name , ssh-keygen -f key_name но ничего не работает, я всегда получаю это сообщение об ошибке:

Load key «key_name»: invalid format

Есть ли способ это исправить?

Проверьте содержимое key_name , если агент говорит invalid format , что с ключом что-то не так — как . Вы уверены, что это правильный ключ? Даже если вам нужен не секретный ключ, агент ssh не вернется, invalid format если ключ работает, вы просто не сможете подключиться. Возможно, вы по какой-то причине поместили туда свой открытый ключ. Проверь это!

Что я сделал, чтобы исправить эту проблему, так это то, что я использую для преобразования PPK-файл, используя PuttyGen .

Сначала загрузите urkey.PPK , затем в меню конвертации выберите экспорт в формат файла Openssh. Это создаст файл newkey.

в настоящее время, ssh -i «newkey» user@127.0.0.1

Выполнено. Надеюсь, это поможет.

Я просил openssh использовать определенный файл идентификации, указав его в файле .ssh / config.

Исходная рабочая конфигурация имела

Это перестало работать без каких-либо изменений. Немного подумав, я заменил «путь к файлу открытого ключа» выше на «путь к файлу закрытого ключа». Это сработало. Причина заключается в том, что файлы открытого и закрытого ключей имеют большие числа, связанные с преступным преступлением, согласно алгоритму RSA. Если вы замените файл закрытого ключа файлом открытого ключа, эти криптографические числа не будут правильно извлечены из блока base64, сохраненного в файлах ключей. Кажется, некоторые версии ssh могут определить расширение .pub и использовать его для определения правильного файла закрытого ключа — а другие версии этого не делают. Это еще один способ, которым эта ошибка может произойти. Надеюсь, это кому-нибудь поможет.

У меня была та же проблема, и оказалось, что у меня в файле по какой-то причине были разделители строк в стиле Windows (CRLF).

Кроме того, файл должен заканчиваться одним LF.

Починить эти сделанные вещи снова.

Вы должны преобразовать ваш ключ .ppk в ключ OpenSSH

Вот как вы это делаете :

1. Загрузите PuttyGen и создайте свою пару ключей (если у вас нет готовой пары ключей). Сохраните закрытый ключ в вашу папку (.ppk)
2. Если у вас уже есть закрытый ключ, загрузите файл закрытого ключа (.ppk), нажав кнопку «Загрузить». В противном случае пропустите этот шаг
3. В меню «Конверсии» выберите «Экспортировать ключ OpenSSH» и сохраните его в своей папке.
4. Теперь вы готовы использовать ключ для входа на сервер без ввода пароля (я предполагаю, что вы уже поместили открытый ключ в /root/.ssh/authorized_keys, chmod 600 /root/.ssh/authorized_keys и перезапущенный демон SSH)

Я только что столкнулся с этим сегодня, когда писал несколько утилит git tagging для моего конвейера CI.

Вот разница между моими двумя ключами:

Я изменил свой код так:

И теперь мой ключ ssh работает.

TL; DR — Я думаю, у вас должен быть символ новой строки в конце вашего закрытого ключа.

Источник

GITLAB CI Ошибка загрузки ключа «/ dev / fd / 63»: неверный формат ОШИБКА: сбой задания: код выхода 1

Вот мой код giltlab-ci.yml:

Running with gitlab-runner 11.8.0 (4745a6f3) on Allence-Tunisie-docker-runner sH47eTgb Using Docker executor with image ntfactory/ci-tool:0.0.2 . Pulling docker image ntfactory/ci-tool:0.0.2 . Using docker image sha256:7fe7b170806f6846271eec23b41c4f79202777f62c0d7a32165dc41722900979 for ntfactory/ci-tool:0.0.2 . Running on runner-sH47eTgb-project-11060727-concurrent-0 via a732493b4b94. Cloning repository. Cloning into ‘/builds/allence-tunisie/e-formation’. Checking out 0a6b48ef as feat/gitlab-ci. Skipping Git submodules setup Checking cache for default. No URL provided, cache will not be downloaded from shared cache server. Instead a local version of cache will be extracted. Successfully extracted cache $ which ssh-agent || ( apt-get update -y && apt-get install openssh-client -y ) /usr/bin/ssh-agent $ eval $(ssh-agent -s) Agent pid 12 $ mkdir -p

/.ssh $ echo «$SSH_PRIVATE_KEY» | tr -d ‘r’ | ssh-add — > /dev/null Error loading key «(stdin)»: invalid format ERROR: Job failed: exit code 1

хотя я пробовал — эхо «$ SSH_PRIVATE_KEY» | tr -d ‘ r’ | ssh-add -> / dev / null я получаю эту ошибку

Error loading key «(stdin)»: invalid format

Эта ошибка возникает, когда закрытый ключ в $ SSH_PRIVATE_KEY имеет неправильный формат, вы можете легко протестировать его локально, если добавите в него несколько случайных символов. В частности, это происходит в Travis-CI, когда вы просто копируете и вставляете закрытый ключ в переменную SSH_PRIVATE_KEY в онлайн-форме. Это связано с символами новой строки после и перед блоками —— BEGIN RSA PRIVATE KEY ——, —— END RSA PRIVATE KEY ——. По этой причине я использую кодировку base64, чтобы убедиться, что ключ отформатирован правильно.

Закодируйте свой закрытый ключ RSA

кот my_private_key | base64 -w0

Добавьте строку base64 в переменные вашего проекта.

Источник

[Solved] SSH-Connection / Load key — invalid format #671

Describe the bug
Under «Edit Connection > Connection > Connection Details > Private Key >Private Key file» i select a name.ppk file that works perfectly in putty on Debian.
The output in Asbru-cm is:
Load key «/home/myusername/files/name.ppk»: invalid format :

Renaming the file to just name throws the same message:
Load key «/home/myusername/files/name»: invalid format

ls -la in that folder:
drwxr-xr-x 2 myusername.myusername 4096 Jul 14 21:51 .
drwxr-xr-x 30 myusername.myusername 4096 Jul 14 13:40 ..
-rwx—— 1 myusername.myusername 1482 Jul 14 21:51 name
-rwx—— 1 myusername.myusername 1482 Okt 27 2018 name.ppk

To Reproduce
Steps to reproduce the behavior:
0. Make SSH Connection

1. Go to ‘..Edit Connection > Connection > Connection Details > Private Key >Private Key file.’
2. Add a keyfile > Click on ‘Save and Close.’
3. Choose that connection and connect
4. See error

Expected behavior
Smooth login as in putty:

Screenshots
If applicable, add screenshots to help explain your problem.

Environment (please complete the following information):

Client OS: Debian GNU/Linux 10 (buster)

Ásbrú Version
Ásbrú Connection Manager 6.2.1 (asbru-cm) started with PID 13275
INFO: Desktop environment detected : xfce
INFO: Config directory is ‘/home/myusername/.config/asbru’
INFO: Used config file ‘/home/myusername/.config/asbru/asbru.nfreeze’
INFO: Virtual terminal emulator (VTE) version is 0.54
INFO: Theme directory is ‘/opt/asbru/res/themes/default’

Additional context
this happens on all my external servers where i can ssh to with putty without any problem.
I have to say the the ssh-servers only accept auth with publickey. Anything else is permitted.

The text was updated successfully, but these errors were encountered:

Источник