Ssh add error loading key stdin invalid format

[gitlab] ‘Error loading key «/dev/fd/63»: invalid format’ error #756

On a private repo I keep getting this error (which has prevented me from switching to industrial_ci on Gitlab)

• Got a hint stackoverflow.com#55523151. But I get the same result

• gitlab.com
• SSH_PRIVATE_KEY is supplied by using the repo’s feature (Settings —> CI/CD —> Variables)

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

I believe it’s the same issue as https://gitlab.com/gitlab-examples/ssh-private-key/-/issues/1#note_48526556
And there they suggest echo «$SSH_PRIVATE_KEY» | tr -d ‘r’ | ssh-add

Thanks. I stopped seeing the exact error message above but I still see the following with plusone-robotics/industrial_ci/fix-gitlab-sshkey.

So there might be as well something with actual key data.
Without a public test cases, it hard to tell what’s going wrong.

Tested on a private repo on my personal org (which I don’t mind giving an acecss), unlike the OP that is on a corporate org, I can’t repro this issue. So I assume there’s a difference b/w personal org and corporate org that ICI’s Gitlab tool isn’t yet handling.

Same as OP, SSH_PRIVATE_KEY is supplied by using the repo’s feature (Settings —> CI/CD —> Variables).

Interestingly, btw, I tested deleting SSH_PRIVATE_KEY on Gitlab from the same repo, which I’d expect ICI to fail with the same/similar error in this ticket as ssh key is now unavailable, but the job still went on and passed.

Источник

🔥 Как настроить Gitlab-CI для автоматического развертывания (CD) вашего приложения через SSH

Тестовая схема:

• Gitlab Runner с запущенным и запущенным Docker исполнителем (может быть локально)
• Cервер для развертывания (тоже может быть локально, он должен быть доступен для раннера).
• У вас есть сервер Gitlab, и вы уже создали репозиторий своего проекта с файлом .gitlab-ci.yml.

Необходимые шаги

Подключитесь по ssh к раннеру:

ssh-keygen -t rsa -N ‘’ -f

Получите закрытый ключ раннера:

Добавьте этот закрытый ключ в качестве переменной в свой проект на Gitlab:

Перейдите: Settings > CI/CD > Variables

Решение ошибки Error loading key “/dev/fd/63”: invalid format

Если при выполнении CI/CD возникает ошибка вида:

/.ssh/id_rsa | base64 -w0

Спасибо за гайд, мне помогло!

Но мне пришлось изменить image, вместо “ubuntu-cd:0.0.2 ” я оставил значение “ubuntu-cd:0.0.2 “

Ошибка в прошлом комментарии :
* я оставил значение “ubuntu“

Спасибо за гайд, мне помогло!
Но мне пришлось изменить image, вместо “ubuntu-cd:0.0.2 ” я оставил значение “ubuntu “

Ну образа меняются, это нормально! Рад, что помогло!

Для выполнения команд по SSH мне помогла только такая конфигурация:

“SSH DEPLOY”:
stage: deploy
image: tetraweb/php
before_script:
– ‘which ssh-agent || ( apt-get update -y && apt-get install openssh-client -y )’
– mkdir -p

/.ssh
– eval $(ssh-agent -s)
– ssh-add Ответить

• Аудит ИБ (49)
• Вакансии (12)
• Закрытие уязвимостей (105)
• Книги (27)
• Мануал (2 234)
• Медиа (66)
• Мероприятия (39)
• Мошенники (23)
• Обзоры (800)
• Обход запретов (34)
• Опросы (3)
• Скрипты (109)
• Статьи (336)
• Философия (99)
• Юмор (18)

Anything in here will be replaced on browsers that support the canvas element

Источник

Не удалось открыть файл конфигурации ‘/ dev / fd / 63’, ошибка: нет такого файла или каталога для wpa_supplicant

Когда я делаю это:

Примечание: из-за подстановки процесса вы не можете запустить эту команду с помощью sudo — вам потребуется корневая оболочка.

Вы должны быть в состоянии использовать su -c под sudo так:

Подстановка процесса создает канал, использует /dev/fd для указания пути, эквивалентного дескриптору файла, в котором находится канал, и передает имя файла в качестве аргумента программе. Здесь есть программа sudo , и она передает этот аргумент (который является просто строкой) wpa_supplicant , который обрабатывает его как имя файла.

Проблема в том, что sudo закрывает все файловые дескрипторы, кроме стандартных (stdin = 0, stdout = 1 и stderr = 2). Канал подстановки процесса находится в другом дескрипторе, который закрывается, поэтому при wpa_supplicant попытке открыть его он находит файл, который не существует.

Если ваша политика sudo это позволяет ( closefrom_override опция включена), вы можете запретить закрывать дескрипторы файлов. Но обычно это не так.

Кроме того, поскольку вы не используете стандартный ввод, передайте данные туда.

В качестве альтернативы, запустите оболочку из sudo и поместите подстановку процесса туда. Будьте осторожны с кавычками, если команда содержит специальные символы.

Для тех, кто приходит с веб-поисковой системы: убедитесь, что ваш /dev подключен. Легкая ошибка, которую можно совершить при chrooting, которая может привести к таким ошибкам, как эта.

Источник

«/dev/fd/63 Нет такого файла или каталога»

Я пытался запустить команду в chroot (довольно новый для этого), и я получаю следующий вывод.

4 ответа

TL;DR: скопировать /root папка вне chroot в каталог chroot

Оператор известен как подстановка процесса и является способом запуска команды, вывод которой идет в анонимный канал. Вот что такое /dev/fd/63. Идея состоит в том, чтобы разрешить внешнюю команду (здесь это bash ) обрабатывать вывод других команд, как если бы это был файл. Как правило, форма будет использовать перенаправить этот объект псевдо-файла в bash входной поток.

Это обычно ничем не отличается от wget https://stuff.com/blah | bash , В обоих случаях, как правило, не рекомендуется использовать такие команды, если вы не уверены на сто процентов, что загружаемый скрипт не из поверхностного источника и не является вредоносным.

Тем не менее, так как вы упомянули запуск команды в chroot и сценарий выводит No such file or directory root и потому что bash позволяет запускать сценарии как bash script.sh здесь ваш скрипт выполняется, но нет каталога с именем root в твоей chroot. Вы можете просто исправить это через sudo cp -R /root chrootdir , Для лучших результатов я бы предложил сначала просто прочитать сценарий, посмотреть, что ему нужно, скопировать его в папку chroot и только потом запускать сценарий локально в папке. Не нужно запускать Wget несколько раз

Так что скрипт работает. Ошибки в сценариях оболочки, как правило, в форме : : error message поэтому скрипт временно сохраняется как /dev/fd/63 и запускается, он просто не находит то, что ему нужно.

Источник

[gitlab] ‘Error loading key «/dev/fd/63»: invalid format’ error #756

Comments

130s commented Nov 5, 2021

Issue

On a private repo I keep getting this error (which has prevented me from switching to industrial_ci on Gitlab)

Attempted but doesn’t seem to be working

• Got a hint stackoverflow.com#55523151. But I get the same result

• gitlab.com
• SSH_PRIVATE_KEY is supplied by using the repo’s feature (Settings —> CI/CD —> Variables)

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

mathias-luedtke commented Nov 5, 2021

I believe it’s the same issue as https://gitlab.com/gitlab-examples/ssh-private-key/-/issues/1#note_48526556
And there they suggest echo «$SSH_PRIVATE_KEY» | tr -d ‘r’ | ssh-add

130s commented Nov 9, 2021

Thanks. I stopped seeing the exact error message above but I still see the following with plusone-robotics/industrial_ci/fix-gitlab-sshkey.

mathias-luedtke commented Nov 9, 2021

So there might be as well something with actual key data.
Without a public test cases, it hard to tell what’s going wrong.

130s commented Nov 18, 2021

Tested on a private repo on my personal org (which I don’t mind giving an acecss), unlike the OP that is on a corporate org, I can’t repro this issue. So I assume there’s a difference b/w personal org and corporate org that ICI’s Gitlab tool isn’t yet handling.

Same as OP, SSH_PRIVATE_KEY is supplied by using the repo’s feature (Settings —> CI/CD —> Variables).

Interestingly, btw, I tested deleting SSH_PRIVATE_KEY on Gitlab from the same repo, which I’d expect ICI to fail with the same/similar error in this ticket as ssh key is now unavailable, but the job still went on and passed.

Источник

🔥 Как настроить Gitlab-CI для автоматического развертывания (CD) вашего приложения через SSH

Тестовая схема:

• Gitlab Runner с запущенным и запущенным Docker исполнителем (может быть локально)
• Cервер для развертывания (тоже может быть локально, он должен быть доступен для раннера).
• У вас есть сервер Gitlab, и вы уже создали репозиторий своего проекта с файлом .gitlab-ci.yml.

Необходимые шаги

Подключитесь по ssh к раннеру:

ssh-keygen -t rsa -N ‘’ -f

Получите закрытый ключ раннера:

Добавьте этот закрытый ключ в качестве переменной в свой проект на Gitlab:

Перейдите: Settings > CI/CD > Variables

Решение ошибки Error loading key “/dev/fd/63”: invalid format

Если при выполнении CI/CD возникает ошибка вида:

/.ssh/id_rsa | base64 -w0

Спасибо за гайд, мне помогло!

Но мне пришлось изменить image, вместо “ubuntu-cd:0.0.2 ” я оставил значение “ubuntu-cd:0.0.2 “

Ошибка в прошлом комментарии :
* я оставил значение “ubuntu“

Спасибо за гайд, мне помогло!
Но мне пришлось изменить image, вместо “ubuntu-cd:0.0.2 ” я оставил значение “ubuntu “

Ну образа меняются, это нормально! Рад, что помогло!

Для выполнения команд по SSH мне помогла только такая конфигурация:

“SSH DEPLOY”:
stage: deploy
image: tetraweb/php
before_script:
– ‘which ssh-agent || ( apt-get update -y && apt-get install openssh-client -y )’
– mkdir -p

/.ssh
– eval $(ssh-agent -s)
– ssh-add Ответить

• Аудит ИБ (49)
• Вакансии (12)
• Закрытие уязвимостей (105)
• Книги (27)
• Мануал (2 234)
• Медиа (66)
• Мероприятия (39)
• Мошенники (23)
• Обзоры (800)
• Обход запретов (34)
• Опросы (3)
• Скрипты (109)
• Статьи (336)
• Философия (99)
• Юмор (18)

Anything in here will be replaced on browsers that support the canvas element

Источник

gitlab-ci SSH-ключ недопустимый формат

Я хотел бы запустить сценарий развертывания с помощью gitlab-ci, но шаг ssh-add $SSH_PRIVATE_KEY вернет ошибку:

Вы можете увидеть мои .gitlab-ci.yml :

В настройках моего проекта я добавил переменную SSH_PRIVATE_KEY с id_rsa с моего производственного сервера cat

Кто-нибудь может мне помочь?

/ .ssh / id_rsa.pub, в то время как закрытый ключ содержится в

В моем случае это произошло потому, что я сделал свою переменную SSH_PRIVATE_KEY защищенной . Когда я отключил защищенное состояние, он работал без ошибок.

В моем случае мне пришлось поставить новую строку в конце SSH_PRIVATE_KEY переменной

Я сделал глупую ошибку и добавил ключ без ——BEGIN RSA PRIVATE KEY—— и ——END RSA PRIVATE KEY—— положения.

Подводя итог, следует добавить:

Также убедитесь, что новая строка после закрытия присутствует.

Он работает с расширением переменных (фигурные скобки в двойных кавычках):

Сохраняя SSH_PRIVATE_KEY переменную защищенной!

Этот подход — просто менее неоднозначный метод вывода переменных; в этом случае он предотвращает обрезку последнего разрыва строки.

По умолчанию это открытый ключ SSH в

Закрытый ключ находится в

Вы должны скопировать все содержимое файла (id_rsa), включая последнюю пустую строку. Я так решаю проблему.

Убедитесь, что символ новой строки после конца переменной файла присутствует. В противном случае появилась бы следующая ошибка:

В ID_RSA этом примере это была моя файловая переменная.

В моем случае это произошло потому, что я сделал свою переменную SSH_PRIVATE_KEY доступной в определенной среде. Я изменил его на тот, который использовал (или вы можете изменить его на Все, в зависимости от ваших настроек).

Если вы экспортируете ключ из PuTTYgen , для получения содержимого ключа используйте его команду Conversations — Export OpenSSH key (принудительно использовать новый формат файла)

И обрезайте последние пробелы и добавьте новую строку.

У меня была эта проблема с gitlab и bitbucket, оба были решены добавлением n к концу ключевого файла.

У меня он работает с защищенной переменной.

Если переменная — это файл, echo больше работать не будет:

Иначе; если переменная НЕ является файлом, используйте следующее:

Источник

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 Ошибка загрузки ключа «/ 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 в переменные вашего проекта.

Источник

Перейти к содержанию

ssh root@runner-ip

ssh root@server-ip

"SSH DEPLOY":
  stage: deploy
  image: ubuntu-cd:0.0.2 
  before_script:
    - 'which ssh-agent || ( apt-get update -y && apt-get install openssh-client -y )'
    - mkdir -p ~/.ssh
    - eval $(ssh-agent -s)
    - '[[ -f /.dockerenv ]] && echo -e "Host *ntStrictHostKeyChecking nonn" > ~/.ssh/config'
    - chmod 700 ~/.ssh
  artifacts:
    when: always
    paths:
      - ./src/file.txt
    expire_in: 1 day
  script:
    - pwd
    - ls -a
    - ssh-add <(echo "$SSH_PRIVATE_KEY" | base64 --decode)
    - scp ./src/file.txt root@172.2.16.50:/tmp/