Miranda NG русскоязычный форум > Общие разговоры о Miranda NG

Miranda GSSAPI не работает с Prosody 0.9

(1/2) > >>

Oneiron:
Настроили GSSAPI, сервер - Debian 9, на нем prosody 0.9.12, с настроенным GSSAPI. Pidgin поверх GSSAPI подключается нормально.
Запускаем Miranda NG 0.9.95 x32, чистую, единственная настройка - указание сервера и "Доменный логин". Вываливается с ошибкой "аутентификация не прошла".
Нетлог прилагаю.
На сервере в логе следующее:

Spoiler
--- Code: ---Aug 16 14:49:22 socket  debug   accepted incoming client connection from: 192.168.7.7 49525 to 5222
Aug 16 14:49:22 c2s56e47978     info    Client connected
Aug 16 14:49:22 c2s56e47978     debug   Client sent opening <stream:stream> to etpk.local
Aug 16 14:49:22 c2s56e47978     debug   Sent reply <stream:stream> to client
Aug 16 14:49:22 c2s56e47978     debug   Received[c2s_unauthed]: <starttls xmlns='urn:ietf:params:xml:ns:xmpp-tls'>
Aug 16 14:49:22 socket  debug   try to start ssl at client id: 56cc06b0
Aug 16 14:49:22 socket  debug   ssl session delayed until writebuffer is empty...
Aug 16 14:49:22 c2s56e47978     debug   TLS negotiation started for c2s_unauthed...
Aug 16 14:49:22 socket  debug   starting ssl handshake after writing
Aug 16 14:49:22 socket  debug   starting handshake...
Aug 16 14:49:22 socket  debug   ssl handshake of client with id:table: 0x56cc06b0, attempt:1
Aug 16 14:49:22 socket  debug   ssl handshake of client with id:table: 0x56cc06b0, attempt:2
Aug 16 14:49:22 socket  debug   ssl handshake of client with id:table: 0x56cc06b0, attempt:3
Aug 16 14:49:22 socket  debug   ssl handshake done
Aug 16 14:49:22 c2s56e47978     debug   Client sent opening <stream:stream> to etpk.local
Aug 16 14:49:22 c2s56e47978     debug   Sent reply <stream:stream> to client
Aug 16 14:49:22 c2s56e47978     debug   Received[c2s_unauthed]: <auth mechanism='GSS-SPNEGO' xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
Aug 16 14:49:22 etpk.local:saslauth       debug   sasl reply: <challenge xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>oYG1MIGyoAMKAQChCwYJKoZIgvcSAQICooGdBIGaY
IGXBgkqhkiG9xIBAgICAG+BhzCBhKADAgEFoQMCAQ+ieDB2oAMCARKibwRttFDq1Px+V3tQ/psGtl+h5RyTxfmLupJDroZeD7NxD1m9SK2pdlilEH22ME1L+3xb2HjDwLRmPhSGZ+lcFUXShAKt2QL1b9
g3ZcZnEdtZ4dJM4XHMUnki6TB07yYEDxkYFdfGuEk0kqE22h00dA==</challenge>
Aug 16 14:49:22 c2s56e47978     debug   Received[c2s_unauthed]: <response xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
Aug 16 14:49:22 etpk.local:saslauth       debug   sasl reply: <challenge xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>BQQF/wAMAAAAAAAAAjKJaAEAAACzTjBB47RIgkhEf
ig=</challenge>
Aug 16 14:49:22 c2s56e47978     debug   Received[c2s_unauthed]: <response xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
Aug 16 14:49:22 sasl_cyrus      debug   Got SASL error condition -1: generic failure
Aug 16 14:49:22 etpk.local:saslauth       debug   sasl reply: <failure xmlns='urn:ietf:params:xml:ns:xmpp-sasl'><undefined-condition/><text>generic failure
</text></failure>
Aug 16 14:49:22 c2s56e47978     debug   Received[c2s_unauthed]: <auth mechanism='GSSAPI' xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
Aug 16 14:49:22 sasl_cyrus      debug   Got SASL error condition -1: generic failure
Aug 16 14:49:22 etpk.local:saslauth       debug   sasl reply: <failure xmlns='urn:ietf:params:xml:ns:xmpp-sasl'><undefined-condition/><text>generic failure
</text></failure>
Aug 16 14:49:24 c2s56e47978     debug   Received </stream:stream>
Aug 16 14:49:24 c2s56e47978     info    c2s stream for <192.168.7.7> closed: session closed
--- End code ---
[close]
Без SSL картина примерно та же самая. Сбой идет при проверке SASL. В чем может быть дело?

ghazan:
добавил логов, в следующем ночнике будет.
надо будет повторить попытку

в том смысле, что надо перейти на ночник (0.9.96)

Oneiron:
Перешел на ночник. Лог приложен :)

ghazan:

--- Quote from: Oneiron on 22 08 2017, 14:03:49 ---Перешел на ночник. Лог приложен :)

--- End quote ---
Печаль. Винда почему-то отвергает механизм GSS-SPNEGO на твоей машине.
Вопрос: если, к примеру, вообще вырубить его в капсах сервера и оставить только GSSAPI, оно будет работать или нет?
Сервер в данном случае конкретно неправ, что отвергает полностью попытку клиента сменить механизм на лету

Oneiron:
Так и подумал, что это как-то связано, поскольку Pidgin использует только GSSAPI.
На сервере особой возможности указать конкретные механизмы нет. Конфиг хоста выглядит так:
SpoilerVirtualHost "sn.local"
   enabled = true
   ssl = {
      key = "/etc/prosody/certs/sn.key";
      certificate = "/etc/prosody/certs/sn.crt";
      }
   authentication = "cyrus"
   cyrus_application_name = "xmpp"
   cyrus_server_fqdn = "apache.sn.local"
   cyrus_service_realm = "SN.LOCAL"
   c2s_require_encryption = true
[close]
А все колдунство с выбором конкретного механизма совершается уже внутри сервера.

Navigation

[0] Message Index

[#] Next page