Как имитировать поведение SSH и создать действительный билет Kerberos на целевом хосте

Question

У нас есть приложение, которое в настоящее время передает билет Kerberos от hostA к hostB. Билет передается как есть и записывается в кэш учетных данных. Проблема заключается в том, что дополнительные билеты службы не могут быть созданы на hostB. Мы выяснили, что это связано с адресом билета.

Это билет, который существует на hostA:

hostA> /usr/lib/mit/bin/klist -f -a
Ticket cache: FILE:/tmp/krb5cc_12345
Default principal: [e-mail]

Valid starting     Expires            Service principal
09/09/17 15:31:45  09/10/17 01:31:45  krbtgt/[e-mail]
        renew until 10/09/17 14:24:09, Flags: FRIA
        Addresses: hostA.company.com

Если мы запускаем ssh для hostB, то на hostB создается новый тикет с правильным адресом (hostB.company.com):

hostA> ssh hostB /usr/lib/mit/bin/klist -f -a
Ticket cache: FILE:/tmp/krb5cc_12345
Default principal: [e-mail]

Valid starting     Expires            Service principal
09/09/17 15:39:46  09/10/17 01:39:46  krbtgt/[e-mail]
        renew until 10/09/17 14:24:09, Flags: FfRA
        Addresses: hostB.company.com

мы проверили, что ssh создал вышеуказанный тикет на hostB и что его раньше не было.

Очевидно, что когда мы передаем билет как есть, мы получаем hostA.company.com в качестве адреса, и мы не можем создать дополнительные билеты службы. например

hostB> /usr/lib/mit/bin/kvno HTTP/myservice.company.com
HTTP/[e-mail]: KDC reply did not match expectations while getting credentials

Это работает, однако, при получении билета с "kinit -A" - мы получаем "(none)" в качестве адреса, и это работает как на hostA, так и на hostB. Тем не менее - мы не используем этот метод, так как у пользователей нет такого типа адреса по умолчанию, и он потребует явного kinit.

Вопрос в том, как ssh пересылает билет и создает действительный билет TGT на хосте B? Как мы можем сделать то же самое в нашем приложении, без использования SSH?