Не логинюсь по ssh к серверу по адресу скрытого сервиса

Сконфигурировал скрытый сервис следующим образом:
HiddenServiceDir path/to/dir HiddenServicePort 22 127.0.0.1:22

Пытаюсь залогиниться:
ssh user@somedomain.onion
somedomain.oninon's password:

– ввожу пароль, упорно отвергает три раза и выдает: Permission denied (publickey,password).
Как будто как пароль неправильный. По ip логинюсь влет.
В чем может быть причина?

Комментарии

—	unknown (02/10/2011 15:23) профиль/связь <#> комментариев: 9796 документов: 488 редакций: 5664

Раз коннект есть, то причина скорее всего в настройках самого ssh. Нужно смотреть в первую очередь именно его логи, подстраивать конфиги. Может кто-то ответит конкретнее...

—	SATtva (02/10/2011 15:27) профиль/связь <#> комментариев: 11558 документов: 1036 редакций: 4118

Попробуйте для начала ssh -v user@somedomain.onion.

—	*Гость* (02/10/2011 18:58) <#>

ssh -v somedomain.onion -l user
OpenSSH_5.5p1 Debian-6, OpenSSL 0.9.8o 01 Jun 2010
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to somedomain.onion [127.192.0.1] port 22.
debug1: Connection established.
debug1: identity file /home/localuser/.ssh/id_rsa type -1
debug1: identity file /home/localuser/.ssh/id_rsa-cert type -1
debug1: identity file /home/localuser/.ssh/id_dsa type -1
debug1: identity file /home/localuser/.ssh/id_dsa-cert type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.5p1 Debian-6
debug1: match: OpenSSH_5.5p1 Debian-6 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.5p1 Debian-6
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5 none
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host 'somedomain.onion' is known and matches the RSA host key.
debug1: Found key in /home/localuser/.ssh/known_hosts:8
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Trying private key: /home/localuser/.ssh/id_rsa
debug1: Trying private key: /home/localuser/.ssh/id_dsa
debug1: Next authentication method: password
user@somedomain.onion's password: 
debug1: Authentications that can continue: publickey,password
Permission denied, please try again.
user@somedomain.onion's password: 
debug1: Authentications that can continue: publickey,password
Permission denied, please try again.
user@somedomain.onion's password: 
debug1: Authentications that can continue: publickey,password
debug1: No more authentication methods to try.
Permission denied (publickey,password).

Не пойму, в чем дело.
На удаленном сервере логи изучал, там ни в логах тора, ни в auth.log вообще нет ничего по поводу коннекта.

—	*Гость* (02/10/2011 20:29) <#>

Прозрачная торификация плюс 127/8 как локалхост в правилах иптаблесов? Возможно клиент подключается к локальному серверу, а не удаленному?

—	*Гость* (02/10/2011 20:37) <#>

В вашей конфигурации прочие публично скрытые сервисы доступны?

VirtualAddrNetwork Address/bits::

When Tor needs to assign a virtual (unused) address because of a MAPADDRESS
command from the controller or the AutomapHostsOnResolve feature, Tor
picks an unassigned address from this range. (Default:

192.0.0/10)

When providing proxy server service to a network of computers using a tool
like dns-proxy-tor, change this address to "10.192.0.0/10" or
"172.16.0.0/12". The default VirtualAddrNetwork address range on a
properly configured machine will route to the loopback interface. For
local use, no change to the default VirtualAddrNetwork setting is needed.

—	*Гость* (02/10/2011 21:14) <#>

Прозрачная торификация плюс 127/8 как локалхост в правилах иптаблесов? Возможно клиент подключается к локальному серверу, а не удаленному?

Ага, посмотрел в auth.log на локальной машине, там действительно локальный ssh-сервер отверг подключение из-за неправильного пароля.
Кстати, msmtp тоже не хочет коннектиться к скрытым сервисам тора из консоли/терминала под прозрачно торифицированным юзером (к обычным серверам – с публичными dns – коннектиться).
А как сделать, чтобы работало?!

—	*Гость* (02/10/2011 21:16) <#>

— Гость (02/10/2011 20:37),

Да, VirtualAddrNetwork у меня в torrc не прописано. А как его правильно прописать?

—	*Гость* (02/10/2011 21:26) <#>

Тьфу, что после дня краснглазия перетупил, надо прописать как во втором абзаце Вашей цитаты из доков.
Все теперь работает, и ssh, и msmtp, только почему-то очень медленно, медленне, чем через Tor к ip.

—	SATtva (02/10/2011 21:57) профиль/связь <#> комментариев: 11558 документов: 1036 редакций: 4118

О скорости Вы судите по одному тесту или по серии? Просто медленная цепочка могла попасться.

—	*Гость* (02/10/2011 22:43) <#>

SATtva, очень долго соединялось, работает достаточно быстро, не хуже, чем если через Tor к ip.
Как я понимаю, если на сервере, например, запустить хотя бы промежуточную ноду Tor и коннектиться к нему через скрытый сервис, пакеты идущие по ssh к срытому сервису маскируются в составе пакетов, идущих через ноду?
Как я вижу по netstat, там не видно никаких специальных внешних соединений по ssh, есть только внутренние с localhost:произв. порт на localhost:ssh-порт.
Интересно, серьезный противник, контролирующий сеть где сервер, и, возможно, "нагнувший" провайдера сервера, может выделить пакеты, идущие в рамках такого коннекта, из общей массы, или нет? Например, для проведения последующей атаки пересечения?
Так то, когда коннектишься через Tor к ip, там сразу "невооруженным" видно соединение по ssh, идущее с того или иного Tor-exit'а.

—	unknown (02/10/2011 23:43, исправлен 02/10/2011 23:48) профиль/связь <#> комментариев: 9796 документов: 488 редакций: 5664

А соединения со скрытыми сервисами вообще происходят часто очень медленно. Там и протокол получения дескриптора и нахождения точки встречи замедляют дело и цепочка узлов длиннее.

Как я понимаю, если на сервере, например, запустить хотя бы промежуточную ноду Tor и коннектиться к нему через скрытый сервис, пакеты идущие по ssh к срытому сервису маскируются в составе пакетов, идущих через ноду?

С одной стороны как бы да и не очень хорошо оснащённому противнику (именно уровня ISP — наблюдающему все входящие и исходящие соединения ноды и имеющему возможность подсчитывать сколько вошло, сколько вышло трафика по различным параметрам) ничего не видно. Но этот трафик нельзя считать полноценно покрывающим, так как выделение проходящих цепочек Tor-ноды от собственно создаваемых ею, реализуется для ISP самыми простыми видами статистического анализа.

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

—	*Гость* (03/10/2011 10:46) <#>

unknown, кстати, не плохо было бы внести в FAQ про то, что некоторые консольные программы (ssh, msmtp) не работают корректно со скрытыми сервисами Tor, если не прописатьVirtualAddrNetwork в torrc.

—	unknown (03/10/2011 15:45) профиль/связь <#> комментариев: 9796 документов: 488 редакций: 5664

Добавить можно. Раз уж там объясняются такие экзотические случаи как прозрачная торификация. А здесь ещё и прозрачная торификация, да чтоб работало со скрытыми сервисами на не самых стандартных программах (не странички там смотреть, что и так работает).

Вот только перенаправляя трафик с помощью VirtualAddrNetwork на группы неиспользуемых адресов вместо локалхоста и не используя этот перехват упоминаемым там dns-proxy-tor у пользователя ничего лишнего не уйдёт в сеть? Или может нужно ещё и файрволл под эти адреса как-то специфично подправить?

Ваша оценка документа [показать результаты]