Como configuro o SSH para não precisar digitar uma senha e sem usar uma chave pública?

Como configuro o SSH para não precisar digitar uma senha e sem usar uma chave pública?

Eu sei que há dezenas de perguntas aqui sobrecomo se conectar a um servidor SSH sem digitar sua senha todas as vezes, e a resposta é sempre "usar uma chave pública". Bem, encontro-me numa rara circunstância em que isso realmente não é uma opção. Por alguma razão inexplicável, o daemon OpenSSH no servidor ao qual estou tentando me conectar está configurado com

RSAAuthentication no
PubkeyAuthentication no

em /etc/ssh/sshd_config. Não tenho nenhum acesso administrativo no servidor, portanto não posso alterar essas ou quaisquer outras opções de configuração do servidor. (É claro que tenho controle total sobre a configuração do cliente: OpenSSH 5.8 no Linux.)

Quais são minhas opções e, em particular, qual é a opção mais segura, para evitar ter que digitar minha senha toda vez que quiser fazer SSH neste servidor? Eu mantenho meus próprios computadores razoavelmente bem protegidos, então vamos supor que os riscos de segurança de armazenar a senha em um arquivo no cliente sejam aceitavelmente baixos, se isso for realmente necessário.

Os outros métodos de autenticação que o servidor pode aceitar são evidentemente API GSS (sobre a qual não sei nada), teclado interativo (sobre a qual também não sei nada) e senha. Aqui estão algumas opções de configuração relevantes:

#ChallengeResponseAuthentication yes

#KerberosAuthentication no

GSSAPIAuthentication yes
GSSAPICleanupCredentials yes

#UsePAM no

e aqui está um -vvrastreamento de depuração ():

debug1: Authentications that can continue: gssapi-with-mic,password,keyboard-interactive
debug1: Next authentication method: gssapi-with-mic
debug1: Unspecified GSS failure.  Minor code may provide more information
Credentials cache file '/tmp/krb5cc_1000' not found
debug1: Unspecified GSS failure.  Minor code may provide more information
Credentials cache file '/tmp/krb5cc_1000' not found
debug1: Unspecified GSS failure.  Minor code may provide more information

debug1: Unspecified GSS failure.  Minor code may provide more information

debug2: we did not send a packet, disable method
debug1: Next authentication method: keyboard-interactive
debug2: userauth_kbdint
debug2: we sent a keyboard-interactive packet, wait for reply
debug1: Authentications that can continue: gssapi-with-mic,password,keyboard-interactive
debug2: we did not send a packet, disable method
debug1: Next authentication method: password

Responder1

Nesse caso, escrever (ou melhor, gravar) um roteiro esperado seria uma de suas opções.

Cada sistema é diferente então não haverá script, mas com o autoexpect é muito fácil gravar um script para esse fim.

Responder2

Pelas informações coletadas até agora, o servidor sftp.pass.psu.eduoferece suporte à autenticação Kerberos 5 (GSSAPI) e está no dce.psu.edudomínio.

Cérbero émuitocomum em redes com muitos servidores e estações de trabalho; muitas grandes instituições educacionais o criaram. Uma das vantagens sobre a autenticação de chave pública é que uma única kinitfornece credenciais automaticamente para todas as máquinas no domínio Kerberos, sem a necessidade de copiar as chaves públicas para cada uma. Outra é o suporte a protocolos – as mesmas credenciais Kerberos podem ser usadas com mais de 30 protocolos (correio, sistemas de arquivos, bancos de dados...), não apenas SSH.

(Em relação aos "administradores sem noção apenas do Windows": o dce.psu.edudomínio, na verdade, parece ser baseado no Active Directory e hospedado por servidores Windows.)

Tente seguir estas etapas:

  1. Faça login no Kerberos. (As ferramentas kinite klistpodem estar no pacote "krb5-user" ou similar, se ainda não estiverem incluídas no sistema.)

    Kinitseu nome de usuário@dce.psu.edu
    

    Se nenhum erro for exibido, o login foi bem-sucedido. klistdeve mostrar um krbtgt/dce.psu.edu@...item " ".

  2. Agora conecte-se ao servidor SSH, com as -vvopções; se a autenticação for bem-sucedida, ótimo.

    Caso contrário, talvez seja necessário editar seu /etc/krb5.confarquivo. Na [domain_realm]seção, adicione o seguinte:

    [domain_realm]
        .psu.edu = dce.psu.edu
    
  3. Com as configurações padrão do Krb5, o bilhete obtido no item 1 deve ser válido por 10 horas e renovável por até uma semana. Não tenho como verificar as configurações, no entanto.

    Se você quiser manter a senha em um arquivo, um simples kinit your_principal < password.txtdeve funcionar, embora não seja totalmente confiável.

    Com ktutilele é possível fazer um"tecla aba"para uso em vez da senha.

    $ktutil
    ktutil: addent -password -pseu_principal-k 1 -e aes256-cts-hmac-sha1-96
    Senha paraseu_principal:*********
    ktutil: wktkeytab_file
    ktutil:  CtrlD
    

    e faça login usando:

    $kinit-ktkeytab_file seu_principal
    

Responder3

Eu consideraria uma solução mista, onde você digita a senha apenas uma vez e o computador mantém um soquete para o servidor SSH remoto. Você pode seguirestas etapaspara configurar exatamente ControlMasterpor esse motivo.

informação relacionada