
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'