Проблема tortoisegit: git не вышел корректно (код выхода 128)

Настройка двухфакторной аутентификации

Это, конечно, излишне, но если вы параноидально относитесь к тому, что кто-то захватывает ваши личные ключи SSH, вы можете настроить свой SSH-сервер на использование 2FA.

Самый простой способ сделать это — использовать Google Authenticator с устройством Android или iOS, хотя SSH поддерживает много двухфакторных методов. С помощью Google Authenticator вам будет предоставлен QR-код, который вы можете отсканировать в мобильном приложении Google Authenticator, чтобы связать свой телефон с сервером, а также вам будет предоставлено несколько резервных кодов для восстановления в случае потери телефона. , Не храните эти коды на своей основной машине, иначе это не совсем два фактора.

Просмотры:
90

Шаг 4: Защита демона sshd

После установки сервера SSH, первым делом исправить файл sshd_config. В нем запретить удалённый доступ пользователя root и разрешить доступ только для доверенных пользователей. Настраиваем от непривилегированного пользователя, используя sudo.

Первое действие перед правкой любого файла — это бекап этого файла, делаем:

remuserbak@vps:~$ sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.orig
 password for remuserbak:

Посмотреть текущее настройки демона ssh

sudo sshd -T

Отключение SSH-логин для пользователя root, используя параметр PermitRootLogin no.

remuserbak@vps:~$ sudo nano etcsshsshd_config
 
# Authentication:
PermitRootLogin no # запретить удалённый доступ для root
AllowUsers user1 user2 # список пользователей, которым разрешён доступ по SSH

После внесения изменений в sshd_config — перегружаем демона SSH.

$ sudo systemctl restart ssh.service
или
$ sudo service sshd restart

При таком способе перезагрузки демона SSH текущее соединение не прерывается.
Теперь при попытке залогинеться с пользователем root, в логах вы увидите запись:

User root from 222.187.238.57 not allowed because not listed in AllowUsers

Всё, у вас демон SSH минимально защищен!

Дополнительные параметры sshd_config, которые можно менять, под ваши задачи и условия, но не делайте это без нужды и предварительно изучите руководство man 5 sshd_config

LoginGraceTime 120: Сервер отключается по истечении этого времени, если пользователю не удалась регистрация в системе. Если стоит значение 0, то время ожидания не ограничено. Значение по умолчанию — 120 секунд.

StrictModes yes: Проверять наборы прав доступа и принадлежность конфигурационных файлов и домашнего каталога пользователя перед разрешением регистрации в системе. Это рекомендуется выполнять потому, что новички иногда оставляют свои каталоги или файлы доступными для записи всем. Значение по умолчанию — yes.

AddressFamily inet: Семейство адресов которое должна использовать служба sshd, допустимые значения: any, inet (только IPv4) и inet6 (только IPv6). Значение по умолчанию — any.

Port 22: Порт, на котором следует ожидать запросы на ssh соединение. Значение по умолчанию — 22, рекомендуется ставить значение нового порта выше 1024 так как значение ниже уже зарезервированы (например 2007)

Внимание! При подключение к нестандартному порту используйте ключ -p для задания порта.

PubkeyAuthentication yes — включение авторизации по ssh-ключам.

PermitEmptyPasswords no — запрет использования пустых паролей.

PasswordAuthentication no — запрет авторизации по паролю в принципе. (не меняйте, пока не убедитесь, что авторизация по SSH-ключам работает)

ListenAddress XXX.XXX.XXX.XXX — указываем конкретный IP, на котором будет располагаться служба

По умолчанию на всех.

Редактирование ~ / .ssh / config

Если у вас нет существующего ключа, который вы бы хотели использовать, вам нужно будет сгенерировать новый файл ключа для своей учетной записи. Если вы это сделаете, вам нужно будет переместить или переименовать нужный файл в ~ / .ssh, чтобы он не конфликтовал с вашим id_rsa по умолчанию. В этом случае мы создадим новый ключ с именем «github»:

ssh-keygen -t rsa -f ~ / .ssh / github

Чтобы использовать несколько ключей SSH, вам нужно будет отредактировать ~ / .ssh / config и настроить новый блок Host для Github, который указывает на только что созданный ключевой файл. SSH будет использовать это, чтобы выбрать ключ SSH, который он будет использовать.

Главное имя хоста Имя хоста github.com IdentityFile ~ / .ssh / github IdentitiesOnly yes Хост старое имя хоста github.com IdentityFile ~ / .ssh / id_rsa IdentitiesOnly yes

Если у вас есть только один блок хоста для нового ключа, вам не нужно ничего делать, и вы сможете подключиться к Github прямо сейчас. Если у вас есть несколько блоков для разных ключей, вам нужно отредактировать удаленный репозиторий, чтобы github.com был заменен именем блока хоста в файле конфигурации SSH. Это позволит выбрать ключ вручную, а не полагаться на конфликтующий поиск.

git удаленное удаление источника git удаленное добавление источника git @ main: имя пользователя / репозиторий.git

Выбор ключей

Если Вы имеете один ключ для каждого типа, то вы можете использовать стандартные имена файлов и ssh-клиент самостоятельно найдет их и использует, но может так случиться, что Вы используете для аутентификации разные файлы:

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

Определить используемый ключ можно с помощью опции -i private_key_file:

mydesktop$ ssh -i ~/.ssh/special_ssh_key  ssh-server
Enter passphrase for key '/home/xahria/.ssh/special_ssh_key':

Следущая опция создаст в Вашем ~/.ssh/config указание на отображение еспользуемого ключа:

mydesktop$ cat ~/.ssh/config
 Host ssh-server
 IdentityFile ~/.ssh/special_ssh_key

mydesktop$ ssh ssh-server
Enter passphrase for key '/home/xahria/.ssh/special_ssh_key':

Обратите внимание, что переменная config всегда равна IdentityFile, независимо от того, используется Pubkey или Identity

Безопасность кодовой фразы

Ваши приватные ключи могут и должны шифроваться кодовой фразой, так как это оберегает Ваш ключ от компрометации. Даже если Вы установили соответствующие права доступа, но не защитили ключь кодовой фразой, без всяких проблем полюбоваться Вашим ключом сможет пользователь root. Так что не спускайте на тормозах это дело.

authorized_keys2

Старые версии OpenSSH использовали два различных публичных ключа для доступа к серверу — authorized_keys для Identities (SSHv1) и authorized_keys2 для Pubkeys (SSHv2). Позже было решено, что это глупо и теперь используется один файл для ключей всех типов, но при отсутствии подходящего ключа будет проверен и authorized_keys2. Более поздние версии OpenSSH могут вполне прекратить поддерживать authorized_keys2 вовсе.

Чтобы не думать об этом ограничении, создадим жесткую ссылку authorized_keys2 на файл authorized_keys.

ssh-server$ cd .ssh
ssh-server$ ls -l
-rw-------    1 xahria   hatchclan   883 Jan 21 11:52 authorized_keys

# make a hard link so they are the same file, just different
# file names.
ssh-server$ ln authorized_keys authorized_keys2

ssh-server$ ls -l
-rw-------    2 xahria   hatchclan   883 Jan 21 11:52 authorized_keys
-rw-------    2 xahria   hatchclan   883 Jan 21 11:52 authorized_keys2

Так мы удовлетворим потребности любой версии OpenSSH.

Как создать ключи SSH?

Сначала необходимо создать ключи ssh для аутентификации на локальном сервере. Для этого существует специальная утилита ssh-keygen, которая входит в набор утилит OpenSSH. По умолчанию она создает пару 2048 битных RSA ключей, которая подойдет не только для SSH, но и для большинства других ситуаций.

И так, генерация ключей ssh выполняется командой:

Утилита предложит вам выбрать расположение ключей. По умолчанию ключи располагаются в папке ~/.ssh/. Лучше ничего не менять, чтобы все работало по умолчанию и ключи автоматически подхватывались. Секретный ключ будет называться id_rsa, а публичный id_rsa.pub.

Затем утилита предложит ввести пароль для дополнительного шифрования ключа на диске. Его можно не указывать, если не хотите. Использование дополнительного шифрования имеет только один минус — необходимость вводить пароль, и несколько преимуществ:

Пароль никогда не попадет в сеть, он используется только на локальной машине для расшифровки ключа. Это значит что перебор по паролю больше невозможен.
Секретный ключ хранится в закрытом каталоге и у клиента ssh нет к нему доступа пока вы не введете пароль;
Если злоумышленник хочет взломать аутентификацию по ключу SSH, ему понадобится доступ к вашей системе. И даже тогда ключевая фраза может стать серьезной помехой на его пути.

Но все же, это необязательное дополнение и если не хотите, то вы можете просто нажать Enter. Тогда доступ по ключу ssh будет выполняться автоматически и вам не нужно будет что-либо вводить.

Теперь у вас есть открытый и закрытый ключи SSH и вы можете использовать их для проверки подлинности. Дальше нам осталось разместить открытый ключ на удаленном сервере.

Настройка rkhunter (основанная на заведомо исправный значениях)

Получив некоторое представление о том, как rkhunter просматривает систему, можно указать файлы и приложения, которые нужно игнорировать или обрабатывать иначе во избежание ложных срабатываний.

Откройте конфигурационный файл rkhunter с привилегиями root:

Настройка уведомлений

Если почтовый сервер установлен локально, можно получать почту, войдя в систему как root:

Имейте в виду, почтовые программы настраиваются сразу при установке, потому их инсталляции нужно уделять особое внимание. Данная строка определяет программу и параметры отправки почты:

Данная строка определяет программу и параметры отправки почты:

Белый список известных файлов

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

Приведенные ниже четыре файла были выведены в результате проверки rkhunter; их нужно внести в белый список с помощью параметра SCRIPTWHITELIST, чтобы rkhunter знал, что эти файлы безвредны:

Это позволит предотвратить ложные срабатывания при всех последующих проверках

Обратите внимание: эти белые списки необходимы только для определенных тестов; потому нужно отметить, что эти файлы не должны быть двоичными. Другие же изменения могут вызвать предупреждения (что является правильной работой программы)

Определенные файлы каталога /dev вызывают предупреждения rkhunter. Эти файлы содержат детали реализации, которые фактически не указывают на какие-либо нарушения. Они необходимы и поддерживаются дистрибутивом.

Итак, существует три предупреждения, которые нужно устранить. Первое предупреждение связано с обнаружением “подозрительного файла” в каталоге. Разместите в конфигурациях следующую строку, чтобы снять подозрения с данного файла:

Следующее предупреждение связано с тем, что в каталоге /dev обнаружен скрытый каталог. В этом каталоге находится предыдущий файл.

Последнее предупреждение вызвано скрытыми файлами. Это основные конфигурационные файлы, которые хранятся в этом каталоге, чтобы программы могли получать к ним доступ независимо от схемы разбиения и состояния монтирования.

Добавьте эти строки, чтобы внести эти файлы в белый список

Разрешение Root SSH-подключения

Следующий шаг – просто проверка утверждения. При запуске rkhunter проверяет этот параметр в конфигурационном файле и сравнивает его со значением в файле конфигурации SSHD.

Данная опция указывает, может ли root-пользователь устанавливать SSH-подключение. Многие методы обеспечения безопасности рекомендуют отключить root-логин. Если root-логин отключен, нужно установить значение “no”.

При необходимости подключаться по SSH нужно изменить значение на “yes”, чтобы rkhunter подтверждал такое соединение:

Сохраните изменения и закройте файл.

Пример использование ssh-keygen для беспарольной аутентификации

Вместо использования паролей, с помощью ssh-keygen можно создать ключи DSA или RSA, которыми пользователи могут аутентифицироваться. Ключи RSA являются наиболее широко используемыми и создаются по умолчанию. Но я для примера использую ключу для создания DSA, если запустить ssh-keygen будет создан RSA.

Немножко терминов:

RSA (Rivest-Shamir-Adleman) является одним из первых криптосистемы с открытым ключом и широко используется для безопасной передачи данных. Безопасность основана на целочисленной факторизации, поэтому безопасный RNG никогда не нужен. По сравнению с DSA RSA быстрее проверяет подпись, но медленнее для генерации.
DSA (Digital Signature Algorithm — алгоритм цифровой подписи) является федеральным стандартом обработки информации для цифровых подписей. Безопасность зависит от дискретной логарифмической проблемы. По сравнению с RSA DSA быстрее генерирует подпись, но медленнее для проверки.

Введите нижеприведённую команду и сгенерируйте ключ, на все вопросы просто жмите Enter. Если при генерации ключей был использован пароль (вы что-то написали на вопрос Enter passphrase (empty for no passphrase)), каждый раз для при использовании приватного ключа он будет запрашиваться у пользователя.

% ssh-keygen -t dsa
Generating publicprivate dsa key pair.
Enter file in which to save the key (homeuser.sshid_dsa):
Created directory '/home/user/.ssh'.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in homeuser.sshid_dsa.
Your public key has been saved in homeuser.sshid_dsa.pub.
The key fingerprint is:
bb:48:db:f2:93:57:80:b6:aa:bc:f5:d5:ba:8f:79:17 [email protected]

ssh-keygen создаст пару публичного и приватного ключей, используемых для аутентификации. Приватный ключ сохраняется в ~/.ssh/id_dsa или ~/.ssh/id_rsa, а публичный в ~/.ssh/id_dsa.pub или ~/.ssh/id_rsa.pub (для ключей DSA и RSA соответственно).

Для включения аутентификации по ключам, публичный ключ должен быть помещен в файл ~/.ssh/authorized_keys на удаленном компьютере, например так:

cat ~.sshid_rsa.pub | ssh root@ip-адрес-сервера 'cat >> ~/.ssh/authorized_keys'

Это позволяет соединяться с удаленным компьютером с помощью SSH-ключей вместо паролей.

Создаст ключи с паролем fgdfgytyityirioyroryoyuouiy:

$ ssh-keygen -N fgdfgytyityirioyroryoyuouiy -t rsa -C test4@test4 -f test4 -q

Создаст ключи без пароля (пароль пустой):

$ ssh-keygen -t rsa -N "" -C test4@test4 -f test4 -q

Как управлять токенами без Exodus?

Допустим, вы поспешили и вывели Ethereum раньше, чем позаботились о токенах на балансе старого кошелька Exodus. Как теперь ими управлять?

Во время импорта приватных ключей, новый Exodus вам выдаст ошибку: не достаточный баланс для перевода. Не волнуйтесь, ваши токены не пропали.

Откройте файл, который получили после экспорта приватных ключей. В нём будет адрес кошелька в сети Ethereum, баланс токена и private key.

Обратите внимание: адрес и приватный ключ – общие для всех ERC20 токенов. Это значит, что их можно контролировать через кошелек MyEtherWallet

А просматривать баланс через Etherscan.

Проверьте!

Если всё в порядке, можно переходить к дальнейшим шагам. Если нет – сразу же напишите в службу поддержки Exodus.

Появится кнопка Unlock, нажимаем.

Внутри кошелька MEW выберите Load Token Balance – должны загрузиться все монеты, которые были изначально у вас в Exodus. Если какой-то монеты нет, попробуйте добавить её через кнопку Add Custom Token (подробная инструкция).

Дальше стоит пополнить кошелек на нужное количество Ethereum (как рассчитать, сколько нужно Gas для перевода токенов – читайте здесь) и перевести токены на свой базовый Ethereum кошелек (MEW, MetaMask или в новый Exodus).

Почему не стоит оставлять токены на этом кошельке?

Он скомпрометирован: когда вы указали seed фразу для получения бесплатных монет, появилась возможность подсмотреть ваши приватные ключи. Поэтому ваш старый кошелек Exodus (Electrum и любой другой, кроме аппаратных), теперь может быть уязвимым.

Чтобы защитить криптовалюты на кошельке, следует создать новую seed фразу, она зашифрует новые приватные ключи, так что уязвимость будет снята.

Если у вас небольшой баланс на данном приватном ключе, то можно ничего не делать.
Но если вы храните крупные суммы или это беспокойство мешает вам жить – проще перевести все активы на новый кошелек.

В конце концов, заведите себе Ledger Nano S для хранения крупных сумм.

PuTTY

PuTTY, который предпочтительнее в Windows, требует, чтобы открытый / закрытый ключи создавались с помощью PuTTYGen (который поставляется с TortoiseGit). необходимо выбрать в качестве клиента ssh в настройках TortoiseGit -> Сеть — это должно быть по умолчанию. Однако по умолчанию для открытых / закрытых ключей нет места, и, следовательно, эти должны быть настроены. Есть (как минимум два способа сделать это):

Настройте свой ключ как ключ по умолчанию в приложениях на основе PuTTY. Для этого откройте PuTTY (который не входит в комплект TortoiseGit и должен быть загружен отдельно). Затем перейдите на страницу конфигурации Connection-> SSH -> Auth и выберите свой .ppk файл как «Закрытый ключ для аутентификации», вернитесь на страницу конфигурации «Session», выберите «Default Settings» и нажмите «Сохранить». -> Отныне PuTTY и PLink будут использовать этот ключ для аутентификации.
Чтобы TortoiseGit загрузил закрытый ключ для использования с PuTTY, его нужно настроить.
- Для существующего репозитория: Выберите репозиторий, откройте настройки TortoiseGit -> Удаленный и выберите там конфигурацию удаленного репозитория (обычно «origin»). Затем выберите свой закрытый ключ .ppk и нажмите «Добавить / Сохранить».
- Для нового репозитория ключ можно выбрать при клонировании. При толкании / вытягивании убедитесь, что установлен флажок «Autoload putty key».

Дополнительные советы / рекомендации по использованию PuTTY.

Если это не поможет

Прежде всего, нам нужно убедиться, что правильный вызывается — обычно так и должно быть, поскольку TortoiseGit изо всех сил пытается найти правильный в системе при первом запуске. Это легко сделать, перейдя в настройки TortoiseGit -> Общие. Здесь следует проверить, » Путь »указывает на правую папку« Git для Windows »(он должен указывать на папку bin установки Git для Windows, а не на папку cmd — но это должно происходить автоматически) — если msysgit (разрабатываемая версия« Git для Windows «), необходимо, чтобы находится на пути (т.е. введен в текстовое поле Extern DLL Path) для выполнения (в противном случае требуемые .dll-файлы) не могут быть найдены. (См. Документацию TortoiseGit)

Теперь нажмите «Проверить сейчас» и убедитесь, что рядом с кнопкой отображается правильный номер версии (а не сообщение об ошибке). Если это работает, должен быть правильно настроен и работать с https.

У меня была такая же проблема, и я решил ее следующим образом …

У меня установлен NVIDIA «Tegra Android Development Pack», и, похоже, с ним также есть версия mysysgit.exe. TortoiseGit автоматически нашел это место установки (вместо стандартной установки git) и автоматически заполнил его в меню настроек.

Чтобы исправить это, перейдите в: «Настройки -> Общие» и там есть поле для пути к mysysgit.exe. Убедитесь, что это указывает на правильную установку.

Я думаю, что нашел лучшую альтернативу для Windows: http://www.syntevo.com/smartgithg/index.html

Пока работает. Но я по-прежнему предпочитаю TortoiseGit, если смогу заставить его работать.

Я также пробовал TortoiseGit в какой-то момент (особенно после многих лет использования Tortoise-SVN), но обнаружил, что это … низкое качество и несколько неинтуитивно. В настоящее время в Windows я использую и всем рекомендую пакет Git Extensions. Он поставляется с: клиентом Git, Cheetah и даже Git bash (с минимальными утилитами Linux, созданными для Win). Устанавливается чисто из коробки. Git-Cheetach подключается к проводнику так же, как TortoiseXXX, и адаптирован к командам Git. Конечно, это только мое предпочтение, поэтому я оставляю комментарий, а не отвечаю, поскольку вопросы остаются нерешенными.
1 Я только что опубликовал новый ответ, который должен прояснить различия между openssh и putty: stackoverflow.com/a/26100799/3906760

В моем случае я сделал эту фиксацию (жертву «не удалось-не-завершил») из Git Bash. И попробовал следующую фиксацию от Tortoise, которая сработала!

4 ответа

Лучший ответ

Пока работает. Но я по-прежнему предпочитаю TortoiseGit, если смогу заставить его работать.

HP.
19 Фев 2013 в 08:48

В моем случае я совершил эту фиксацию (жертву «не удалось-не-завершил-чисто») из Git Bash. И попробовал следующий коммит от Tortoise, который сработал!

Sujit Y. Kulkarni
30 Июн 2018 в 11:14

У меня была такая же проблема, и я решил ее следующим образом …

roadrunner
5 Сен 2013 в 14:17

Общий ответ

Каждый раз, когда выполняется , он возвращает код выхода (см. Возвращает ли git определенные коды ошибок возврата?) .

В сообщении StackOverflow упоминается код выхода 128, который указывает на ошибку:

Следующий пост содержит конкретный ответ, связанный с случаем push, и в конце более общий ответ (если это не поможет раздел).

Использование TortoiseGit с SSH

Здесь нужно различать OpenSSH и PuTTY. ()

OpenSSH

Чтобы использовать OpenSSH, вы должны установить как «SSH-клиент» в настройках TortoiseGit -> Сеть. OpenSSH использует файлы для своих открытых / закрытых ключей по умолчанию, которые должны быть созданы OpenSSH , а не PuTTYGen (ключи PuTTY имеют другой формат, однако их также можно преобразовать с помощью PuTTYGen). Если не установлен, TortoiseGit установит его автоматически, если вы вручную установили , убедитесь, что он действителен (возможно, вам придется использовать косую черту вместо обратной косой черты).

Это рекомендуется для людей, у которых уже есть ключи OpenSSH.

PuTTY

PuTTY, который предпочтительнее в Windows, требует, чтобы открытые / закрытые ключи создавались с помощью PuTTYGen (который поставляется с TortoiseGit). необходимо выбрать в качестве клиента ssh в настройках TortoiseGit -> Сеть — это должно быть по умолчанию. Однако по умолчанию для открытых / закрытых ключей нет места, поэтому их необходимо настроить . Есть (как минимум два способа сделать это):

Настройте свой ключ как ключ по умолчанию в приложениях на основе PuTTY. Для этого откройте PuTTY (который не поставляется с TortoiseGit и должен быть скачал отдельно). Затем перейдите на страницу конфигурации Connection-> SSH -> Auth и выберите свой .ppk файл как «Закрытый ключ для аутентификации», вернитесь на страницу конфигурации «Session», выберите «Default Settings» и нажмите «Сохранить». -> Отныне PuTTY и PLink будут использовать этот ключ для аутентификации.
Чтобы заставить TortoiseGit загрузить закрытый ключ для использования с PuTTY, его нужно настроить.
- Для существующего репозитория: Выберите репозиторий, откройте настройки TortoiseGit -> Remote и выберите там конфигурацию вашего удаленного репозитория (обычно «origin»). Затем выберите свой закрытый ключ .ppk и нажмите «Добавить / Сохранить».
- Для нового репозитория ключ можно выбрать при клонировании. При нажатии / вытягивании убедитесь, что установлен флажок «Autoload putty key».

Если это не поможет

Прежде всего, нам нужно убедиться, что вызывается правильный — обычно так и должно быть, поскольку TortoiseGit изо всех сил пытается найти правильный в системе при первом запуске. Это легко сделать, перейдя в настройки TortoiseGit -> Общие. Здесь следует проверить, указывает ли « Путь» на правильную папку «Git для Windows» (он должен указывать на папку bin установки Git для Windows, а не на папку cmd — но это должно происходить автоматически) — если используется msysgit (разрабатываемая версия «Git для Windows»), необходимо, чтобы был на пути (т.е. был введен в текстовое поле Extern DLL Path) для выполнения (в противном случае требуемые .dll-файлы) не могут быть найдены. (См. документацию TortoiseGit)

CheTesta
19 Апр 2019 в 09:55