☰

Configurar SSH-Jumphost | Proxyjump com freeIPA e Kerberos-Tickets

tag-icon • tag-icon ssh kerberos login freeipa gssapi
Configurar SSH-Jumphost | Proxyjump com freeIPA e Kerberos-Tickets

Quero configurar um bastião (ssh jumphost) para acessar a rede atrás de um firewall. Ambos os servidores estão em um domínio freeIPA. O cliente é uma máquina do usuário e não faz parte do domínio IPA.

Internet/cliente —> SSH-Jumphost —> nó de login

Meu plano é fazer login no ssh-jumphost por meio de credenciais para obter um TGT válido e, em seguida, fazer ssh no servidor de login por meio do ticket Kerberos obtido.

Portanto, alterei as configurações ssh e sshd que as credenciais GSSAPI podem ser encaminhadas.

# 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

E a configuração do 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

Se eu usar o ssh para fazer login no jumphost, recebo um ticket Kerberos válido. Depois disso, posso fazer o ssh para o login sem inserir credenciais

 $(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

Mas se eu tentar fazer isso em uma única etapa, precisarei inserir minhas credenciais para cada servidor:

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

Depois estou logado e tenho um TGT válido, mas não sei por que preciso digitar minha senha duas vezes.

Só quero ser forçado a digitar minha senha uma vez.

Eu tentei isso com diferentes configurações de ssh no cliente também.

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

Com e sem as opções GSSAPI.

Host jumphost
  User USER
  HostName jumphost

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

Com e sem as opções GSSAPI.

Todas as versões levam ao caso de que preciso fornecer minha senha duas vezes.

o que estou perdendo?

Editar: Adicionado 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

Existem os seguintes arquivos em /etc/krb5.conf.d

crypto-policies  freeipa  kcm_default_ccache  sssd_enable_idp

Responder1

editarAcho que estava errado :-)

As configurações de SSH parecem boas para mim. Suponho que o bilhete emitido não possa ser encaminhado.

Citandoman 5 krb5.conf:

Seção Libdefaults

[...]
encaminhável
Se este sinalizador estiver definido, os tickets iniciais por padrão serão encaminháveis. O valor padrão para este sinalizador é falso.

Responder2

Acho que você está entendendo mal o que a opção -J do ssh faz. Ele usa o host de salto para criar uma conexão de soquete com o destino final para fazer proxy da conexão, mas ainda é o host original que está negociando chaves e autenticação com o destino final. Você pode ter mais sorte com algo como:

ssh -t jumphost 'ssh -t login'

informação relacionada