После переустановки системы с сохранением данных пользователя стали творится странные вещи.

Вот одна из них:

Доступ к гиту через port 22 + private key - "ssh://user@mydomain.com/pathtorepo.git"

Для теста запускаю еще Wireshark.

На других компах все без проблем работает и Wireshark показывает соединения через порт 22

На рабочем абсолютная глухота, только когда через Putty или еще что то подобное когда пытаюсь залогинится через порт 22, работает и показывает соединения на порт 22

Firewall отключить запрещено "Fcr your security, some settings are managed by your system administrator.", разрешил пользование портом 22 также.

На сервере тоже проверял - не приходит ничего.

Попробую еще виртуалку поставить, старые все слетели.

Что еще может избирательно блокировать соединение? Какие еще проверки можно сделать?

------

Локальный файрволл... билли с некоторых пор его пихает и включает когда ему надо...

Локальный файрволл..

Вполне возможно, только есть две проблемы:

1. Официально его можно отключить только через домейн админом. Сервис удалось остановить, но никак не повлияло.

2. Дофига "дохлых" прог. Запускаются, могут работать, но чего то не пашет, так как регистрация/ключи сбросились.

Есть подозрение что какая то часть фаерволла работает в "дурном" режиме.

Что видимо с кзшем сайта

Когда вызываю из gitbash

ssh user@mydomain.com

говорит что сайт неизвестный и предлагает занести в кэш.

Wireshark обнаруживает активность на 22 порту при следующем вызове этой же команды.

Бум искать дальше

Локальный файрволл..

Точно не он

Попробовал сейчас "гиткракен" - работает, но он не бесплатный. Что то с "режимом Putty" случилось.

2. Дофига "дохлых" прог. Запускаются, могут работать, но чего то не пашет, так как регистрация/ключи сбросились.

Напоминает ситуацию когда систему переустановили, а все проги которые были проинсталированныев старой системе скопировали просто по верху.

Напоминает ситуацию

В принципе после переустановки где то так было. На компе два диска С и Д. На С система, на Д устанавливались все проги.

Переустановка затронула только диск С. Все проги на диске Д переусатновились заново в те же каталоги.

Но вот

http://www.dependencywalker.com/

установки не имеет, а когда меняются настройки отказывается их писать в регистри, так как нет прав на запись. Больше никто не жалуется.

Ассембли нельзя было подписать, в какой то каталог у юсера не была прав записи

Если вручную даю команды putty/plink, то реакция есть. Как только из какой то проги, но никакой реакции на порт 22

Еще вот надо найти описание чисто ручной работы с гит через SSH и Putty

Блин, перерыл дофига ссылок нигде не нахожу полного описания.

Вот одна из них

https://serverfault.com/questions/194567/how-do-i-tell-git...

Есть совет выполнить следующую команду для проверки в GitBash

$ ssh someuser@someserver.com ls

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

Теперь нужно обнову взять. Раньше работало следующее

$ git fetch --progress "origin"

Теперь нет даже начала соединения, только "ошибка"

fatal: protocol error: bad line length character: someuser@

Как же это теперь объединить? Как раз вопрос к любителям командных строк...

Похоже самый нижний уровень протокола нашел и он работает:

$ ssh someuser@someserver.com git-receive-pack /path-to-repo.git

008fd4db7a934d842eb1fbb2f468f2bd2b3fe52772f3 refs/heads/developreport-status delete-refs side-band-64k quiet atomic ofs-delta agent=git/2.7.4

004dbbf3063881abadcf2944b9a1af9256b7ef9e9e7b refs/heads/feature/Version_2706

003fb10603657a18fd4559cceb5985cdc789c2291207 refs/heads/master

0000

По идее, это все должен вызывать и получать гит, а он отчего этого не хочет делать.

Похоже и команду нашел, но... ничего не происходит

$ git clone ssh://someuser@someserver.com/path-to-repo.git

Похоже нашел, слов матных не хватает.

Помогла эта команда с загруженными в pagent ключами. Если все правильно, то должна открыться сессия. Если что неправильно то хоть видно что.

plink.exe -v -agent gituser@servername.com

Оказалось что Putty должен иметь (или может вообще не иметь) сессию с именем сервера с портом для доступа по гит. А у меня там было порт для доступа по админке.

А тут нечего объединять. У вас что-то с сервером, он неправильно отвечает. Первые мм... 2 или 4 байта ответа должны быть длиной ответа.

получается у вас путти видел что кто-то хочет начать сессию с определенным хостом и пользователем и вместо 22 порта с чем-то другим соединялся?

У вас что-то с сервером, он неправильно отвечает

Что бы он что то ответил он должен вначале что то получить.

получается у вас путти видел что кто-то хочет начать сессию с определенным хостом

была сохраненная сессия путти с именем сервера на порт, допустим 1111 и подлая путти нагло брала части этой сессии и пыталась соединится через порт 1111. Может было бы и хорошо для нестандартного порта. Но такое поведение нигде в описаниях не попадалось.

А я этого нигде не видел соединения и на клиенте и на сервере проверял доступ только на порт 22. А там всё пусто.

До переустановки было все тоже самое, только имя сессии включало еще дополнительные буквы

Странная штука ни тебе версии ни что к чему присоединяется а здесь сразу гид , нужно изменить всё на чистый стандарт по умолчанию и очистить все сохранённые настройки и даже VPN для Pytty , дальнейшем проверять блокировку не только портов но и программ которой вы желаитье создать соиденения. Даже если это невозможно по какой-то причине. Если проверить только частично и ошибка останется то можно искать всю оставшуюся жизнь пока не дойдёт.