1

There are two fine intermediary hosts between my workstation and where I need to end-up. I was attempting to use the ProxyJump configuration to make this connection, but it does not appear to work.

Topology:

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

When I try using this command below, I receive an error

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

It connects to h1.domain1.com, but then fails to properly connect to h2.domain2.com with an inability to "contact any KDC for realm 'domain2.com' (and I do not have a password on domain2.com, so it is not an option):

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

The following command does work, but this site suggests it may not be secure:

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

I believe all of the cross-realm authentication is properly set, as the one command does work.

As a side note, all within domain1.com, I can do without issue: ssh -K -J a.domain1.com,b.domain1.com c.domain.com

Is there anyway to get the shorter and more secure ProxyJump to work with Kerberos in this configuration?

1 Answer 1

0

Cross-realm authentication has nothing to do with you having a password for the other realm. Your client must contact the KDC of domain2 to obtain a ticket for a server which is in that other realm.

Cross-realm authentication works like this:

  1. Client@FOO contacts kdc.foo.com, uses the password to obtain krbtgt/FOO@FOO (the initial TGT).
  2. Client@FOO contacts kdc.foo.com, uses krbtgt/FOO@FOO to obtain krbtgt/BAR@FOO.
  3. Client@FOO contacts kdc.bar.org, uses krbtgt/BAR@FOO to obtain host/host1.bar.org@BAR.

Therefore the client must be able to reach KDCs for both its own realm and the server's realm.

(Ideally, to avoid manual krb5.conf configuration, each realm should just have SRV records for _kerberos._udp and _kerberos._tcp pointing at the correct KDC.)

ProxyJump does not affect this in any way. It establishes a tunnel so that all client logic still runs on your computer. Therefore Kerberos works exactly the same as if you were ssh'ing to the final server directly.

3
  • I appreciate your reply. I apologize if the mention of the cross-realm being properly configured detracted from the central question. As the client cannot see the KDC for domain2 (bar.org), then the implication is that ProxyJump cannot be utilized, the only approach is the chained ssh commands. Is that correct?
    – KevinO
    Commented Oct 9, 2018 at 15:06
  • Yes. As described in the post, if you cannot reach KDC2, you cannot get tickets for servers in realm2. (Note that it is generally safe to provide public access to the KDC – both directly and through a HTTPS reverse proxy.) Commented Oct 9, 2018 at 16:24
  • You could also set up a SSH tunnel to KDC2 (port 88 TCP) and reach it that way... Commented Oct 9, 2018 at 16:27

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .