ssh ProxyJump com Kerberos

0

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 não funcionar.

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 uma incapacidade de "contatar qualquer KDC para domínio 'domain2.com' (e eu não tenho uma senha em domain2.com, portanto 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 cross-realm esteja configurada corretamente, pois o comando one funciona.

Como uma nota lateral, tudo dentro de domain1.com, eu posso fazer sem problema:     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?

KevinO
fonte

Respostas:

0

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 é nesse outro reino.

A autenticação entre domínios funciona assim:

  1. Os contatos do cliente @ FOO, kdc.foo.com, usam a senha para obter o krbtgt / FOO @ FOO (o TGT inicial).
  2. Os contatos do cliente @ FOO, kdc.foo.com, usam 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 devo ser capaz de alcançar os KDCs tanto para seu próprio domínio quanto para o domínio do servidor.

(Idealmente, para evitar manual krb5.conf configuração, 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.

grawity
fonte
Eu aprecio sua resposta. Peço desculpas se a menção do reino cruzado estar adequadamente configurado prejudicou a questão central. Como o cliente não pode ver o KDC para domain2 (bar.org), a implicação é que ProxyJump não pode ser utilizado, a única abordagem são os comandos ssh encadeados. Isso está correto?
KevinO
Sim. Conforme descrito no post, se você não conseguir acessar o KDC2, não poderá obter tickets para servidores em realm2. (Observe que geralmente é seguro fornecer acesso público ao KDC - tanto diretamente quanto por meio de um proxy reverso HTTPS.)
grawity
Você também pode configurar um túnel SSH para o KDC2 (porta 88 TCP) e alcançá-lo dessa forma ...
grawity