Configurar SSH-Jumphost | Proxyjump con freeIPA y Kerberos-Tickets

Configurar SSH-Jumphost | Proxyjump con freeIPA y Kerberos-Tickets

Quiero configurar un bastión (ssh jumphost) para acceder a la red detrás de un firewall. Ambos servidores están en un dominio IPA gratuito. El cliente es una máquina de usuario y no forma parte del dominio IPA.

Internet/cliente —> SSH-Jumphost —> nodo de inicio de sesión

Mi plan es iniciar sesión en ssh-jumphost mediante credenciales para obtener un TGT válido y luego acceder por ssh al servidor de inicio de sesión mediante el ticket de Kerberos obtenido.

Por lo tanto, cambié las configuraciones ssh y sshd para las que se permite reenviar las credenciales GSSAPI.

# IPA-related configuration changes to sshd_config

PubkeyAuthentication yes
KerberosAuthentication no
GSSAPIAuthentication yes
UsePAM yes
ChallengeResponseAuthentication yes
AuthorizedKeysCommand /usr/bin/sss_ssh_authorizedkeys
AuthorizedKeysCommandUser nobody

# added
PasswordAuthentication no

Y la configuración ssh:

# IPA-related configuration changes to ssh_config
#
PubkeyAuthentication yes
GlobalKnownHostsFile /var/lib/sss/pubconf/known_hosts
#VerifyHostKeyDNS yes

# assumes that if a user does not have shell (/sbin/nologin),
# this will return nonzero exit code and proxy command will be ignored
Match exec true
        ProxyCommand /usr/bin/sss_ssh_knownhostsproxy -p %p %h


#added 
GSSAPIAuthentication yes
GSSAPITrustDns yes
GSSAPIKeyExchange yes
GSSAPIRenewalForcesRekey yes
Host login
    GSSAPIDelegateCredentials yes

Si uso ssh para iniciar sesión en jumphost, recibo un ticket Kerberos válido. Después de eso, puedo iniciar sesión mediante ssh sin ingresar las credenciales.

 $(j@client) ssh jumphost
(USER@jumphost) password:
$(@jumphost) klist
Credential-Cache: KCM:1791600003:19884
Standard-Principal: user@REALM

Valid starting       Expires              Service principal
22.11.2022 17:45:38  23.11.2022 17:35:51  krbtgt/REALM@REALM
$(@jumphost) ssh login

$(@login) klist
Credential-Cache: KCM:1791600003:66779
Standard-Principal: user@REALM

Valid starting       Expires              Service principal
22.11.2022 17:47:51  23.11.2022 17:35:51  krbtgt/REALM@REALM

Pero si intento hacer esto en un solo paso, necesito ingresar mis credenciales para cada servidor:

$(@client) ssh -J jumphost login
(user@jumphost) Password: 
(user@login) Password: 

Luego inicié sesión y tengo un TGT válido, pero no sé por qué necesito ingresar mi contraseña dos veces.

Sólo quiero que me obliguen a ingresar mi contraseña una vez.

También probé esto con diferentes configuraciones ssh en el cliente.

Host login
  User USER
  #GSSAPIAuthentication yes
  #GSSAPIDelegateCredentials yes
  HostName login
  ProxyJump USER@jumphost

Con y sin las opciones GSSAPI.

Host jumphost
  User USER
  HostName jumphost

Host login
  User USER
  #GSSAPIAuthentication yes
  #GSSAPIDelegateCredentials yes
  HostName login
  ProxyJump jumphost

Con y sin las opciones GSSAPI.

Todas las versiones conducen al caso de que necesito proporcionar mi contraseña dos veces.

¿Qué me estoy perdiendo?

Editar: Añadido krb5.conf

#File modified by ipa-client-install

includedir /etc/krb5.conf.d/
includedir /var/lib/sss/pubconf/krb5.include.d/

[libdefaults]
  default_realm = RELAM
  dns_lookup_realm = true
  rdns = false
  dns_canonicalize_hostname = false
  dns_lookup_kdc = true
  ticket_lifetime = 24h
  forwardable = true
  udp_preference_limit = 0
  default_ccache_name = KEYRING:persistent:%{uid}


[realms]
  REALM = {
    pkinit_anchors = FILE:/var/lib/ipa-client/pki/kdc-ca-bundle.pem
    pkinit_pool = FILE:/var/lib/ipa-client/pki/ca-bundle.pem

  }

[domain_realm]
  .realm.com = REALM
  realm.com = REALM
  jumphost.realm.com = REALM

Hay los siguientes archivos en /etc/krb5.conf.d

crypto-policies  freeipa  kcm_default_ccache  sssd_enable_idp

Respuesta1

editarSupongo que me equivoqué :-)

La configuración de SSH me parece bien. Supongo que el billete emitido no se puede reenviar.

Citandoman 5 krb5.conf:

Sección Libdefaults

[...]
reenviables
Si se establece esta bandera, los tickets iniciales por defecto serán reenviables. El valor predeterminado para esta bandera es falso.

Respuesta2

Creo que no estás entendiendo bien lo que hace la opción -J de ssh. Utiliza el host de salto para crear una conexión de socket con el destino final para realizar la conexión, pero sigue siendo el host original el que está negociando claves y autenticación con el destino final. Quizás tengas más suerte con algo como:

ssh -t jumphost 'ssh -t login'

información relacionada