ssh ProxyJump com Kerberos

Question

Existem dois excelentes hosts intermediários entre minha estação de trabalho e onde eu preciso terminar. Eu estava tentando usar a configuração ProxyJump para fazer essa conexão, mas parece que não funciona.

Topologia:

                      ssh                ssh                ssh
localhost.domain1.com --> h1.domain1.com --> h2.domain2.com --> dest.domain2.com

Quando tento usar este comando abaixo, recebo um erro

ssh -K -J h1.domain1.com,h2.domain2.com dest.domain2.com

Ele se conecta a h1.domain1.com, mas não consegue se conectar corretamente a h2.domain2.com com a incapacidade de "contatar qualquer KDC para domínio 'domain2.com' (e eu não tenho uma senha em domain2). com, por isso não é uma opção):

OpenSSH_7.4p1, OpenSSL 1.0.2k-fips  26 Jan 2017
debug1: Reading configuration data /home/USERNAME/.ssh/config
...
debug1: Setting implicit ProxyCommand from ProxyJump: ssh -J h1.domain1.com -v -W %h:%p h2.domain2.com
debug1: Executing proxy command: exec ssh -J h1.domain1.com -v -W dest.domain2.com:22 h2.domain2.com
...
debug1: Connecting to h1.domain1.com [132.175.108.33] port 22.
debug1: Connection established.
...
debug1: Authenticating to h1.domain1.com:22 as 'USERNAME'
...
debug1: Next authentication method: gssapi-with-mic
debug1: Authentication succeeded (gssapi-with-mic).
Authenticated to h1.domain1.com ([###.###.##.##]:22).
debug1: channel_connect_stdio_fwd h2.domain2.com:22
debug1: channel 0: new [stdio-forward]
debug1: getpeername failed: Bad file descriptor
debug1: Requesting [email protected]
debug1: Entering interactive session.
debug1: pledge: network
...
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.3
debug1: match: OpenSSH_5.3 pat OpenSSH_5* compat 0x0c000000
debug1: Authenticating to h2.domain2.com:22 as 'USERNAME'
...
debug1: Next authentication method: gssapi-with-mic
debug1: getpeername failed: Socket operation on non-socket
debug1: Unspecified GSS failure.  Minor code may provide more information
Cannot contact any KDC for realm 'domain2.com'

debug1: Authentications that can continue: gssapi-keyex,gssapi-with-mic,password,hostbased
debug1: Next authentication method: password

O seguinte comando funciona, mas este site sugere que pode não ser seguro :

ssh -K -tt h1.domain1.com ssh -K -tt h2.domain2.com ssh -K -tt dest.domain2.com

Acredito que toda a autenticação entre domínios está configurada corretamente, já que o comando funciona.

Como nota de rodapé, tudo dentro do domínio1.com, posso fazer sem problemas:     ssh -K -J a.domain1.com, b.domain1.com c.domain.com

Existe alguma maneira de obter o ProxyJump mais curto e mais seguro para trabalhar com o Kerberos nessa configuração?

    

Answer 1

Autenticação cross-realm não tem nada a ver com você ter uma senha para o outro domínio. Seu cliente deve entrar em contato com o KDC do domínio2 para obter um ticket para um servidor que esteja nesse outro domínio.

Autenticação cross-realm funciona assim:

1. Os contatos do cliente @ FOO, kdc.foo.com, usam a senha para obter o krbtgt / FOO @ FOO (o TGT inicial).
2. O cliente @ FOO contata kdc.foo.com, usa krbtgt / FOO @ FOO para obter krbtgt / BAR @ FOO.
3. O cliente @ FOO contata kdc.bar.org, usa krbtgt / BAR @ FOO para obter host/host1.bar.org@BAR.

Portanto, o cliente deve ser capaz de acessar os KDCs tanto para o seu próprio domínio quanto para o domínio do servidor.

(Idealmente, para evitar a configuração manual krb5.conf , cada região deve ter apenas registros SRV para _kerberos._udp e _kerberos._tcp apontando para o KDC correto.)

O ProxyJump não afeta isso de nenhuma maneira. Ele estabelece um túnel para que toda a lógica do cliente ainda seja executada no seu computador. Portanto, o Kerberos funciona exatamente como se você estivesse ssh ao servidor final diretamente.