Es gibt zwei gute Vermittler zwischen meiner Workstation und den Stellen, an denen ich enden muss. Ich habe versucht, die ProxyJump-Konfiguration zu verwenden, um diese Verbindung herzustellen, aber es scheint nicht zu funktionieren.
Es stellt eine Verbindung zu h1.domain1.com her, kann jedoch keine korrekte Verbindung zu h2.domain2.com herstellen, mit der Unfähigkeit, "ein beliebiges KDC für Realm" domain2.com "zu kontaktieren (und ich habe kein Kennwort auf domain2.com.) es ist keine 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 no-more-sessions@openssh.com 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
Ich glaube, dass die gesamte bereichsübergreifende Authentifizierung ordnungsgemäß festgelegt ist, da der Befehl "one" funktioniert.
Als Randbemerkung kann ich alle auf domain1.com ohne Probleme erledigen: ssh -K -J a.domain1.com, b.domain1.com c.domain.com
Gibt es trotzdem einen kürzeren und sichereren ProxyJump, um in dieser Konfiguration mit Kerberos zu arbeiten?
1 Antwort auf die Frage
0
grawity
Die bereichsübergreifende Authentifizierung hat nichts damit zu tun, dass Sie ein Kennwort für den anderen Bereich haben. Ihr Client muss sich an das KDC von Domäne2 wenden, um ein Ticket für einen Server zu erhalten, der sich in diesem anderen Bereich befindet.
Die Cross-Realm-Authentifizierung funktioniert folgendermaßen:
Client @ FOO kontaktiert kdc.foo.com, verwendet das Kennwort, um krbtgt / FOO @ FOO (das ursprüngliche TGT) zu erhalten.
Client @ FOO kontaktiert kdc.foo.com, verwendet krbtgt / FOO @ FOO, um krbtgt / BAR @ FOO zu erhalten.
Client @ FOO kontaktiert kdc.bar.org, verwendet krbtgt / BAR @ FOO, um host/host1.bar.org@BAR zu erhalten.
Daher muss der Client in der Lage sein, KDCs sowohl für seinen eigenen Bereich als auch für den Server zu erreichen.
(Um manuelle krb5.confKonfiguration zu vermeiden, sollte jeder Bereich nur SRV-Einträge für das richtige KDC haben _kerberos._udpund _kerberos._tcpauf das richtige KDC zeigen.)
ProxyJump beeinflusst dies in keiner Weise. Es baut einen Tunnel auf, damit die gesamte Client-Logik auf Ihrem Computer ausgeführt wird. Daher funktioniert Kerberos genau so, als würden Sie direkt an den endgültigen Server ssh'en.
Ich freue mich über Ihre Antwort. Ich entschuldige mich, wenn die Erwähnung der Cross-Realm-Konfiguration die zentrale Frage beeinträchtigt. Da der Client das KDC für domain2 (bar.org) nicht sehen kann, bedeutet dies, dass ProxyJump nicht verwendet werden kann. Der einzige Ansatz sind die verketteten ssh-Befehle. Ist das korrekt?
KevinO vor 5 Jahren
0
Ja. Wenn Sie KDC2 nicht erreichen können, erhalten Sie keine Tickets für Server in realm2. (Beachten Sie, dass es generell sicher ist, den öffentlichen Zugriff auf das KDC bereitzustellen - sowohl direkt als auch über einen HTTPS-Reverse-Proxy.)
grawity vor 5 Jahren
0
Sie können auch einen SSH-Tunnel für KDC2 (Port 88 TCP) einrichten und ihn so erreichen ...
grawity vor 5 Jahren
0