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

Eu sei que existem dezenas de perguntas aqui sobre como conectar-se a um servidor SSH sem digitar sua senha todas as vezes , e a resposta é sempre "use uma chave pública". Bem, eu me encontro na 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 conectar está configurado com

RSAAuthentication no
PubkeyAuthentication no

no /etc/ssh/sshd_config. Como não tenho acesso administrativo ao servidor, não posso alterar essas ou outras opções de configuração do servidor. (Obviamente, eu 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 a necessidade de digitar minha senha toda vez que quero fazer o SSH neste servidor? Eu mantenho meus próprios computadores razoavelmente bem protegidos, então vamos assumir que os riscos de segurança de armazenar a senha em um arquivo no cliente são aceitáveis, se isso for realmente necessário.

Os outros métodos de autenticação que o servidor pode aceitar são evidentemente a API GSS (sobre a qual não sei nada), o teclado interativo (sobre o qual também não sei nada) e a 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 -vvrastreio debug ( ):

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

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

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

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

O Kerberos é muito comum em redes com muitos servidores e estações de trabalho; muitas grandes instituições educacionais o criaram. Uma se suas vantagens sobre a autenticação de chave pública é que um único kinitfornece credenciais automaticamente a todas as máquinas no domínio Kerberos, sem a necessidade de copiar as chaves públicas para cada uma. Outro é o suporte ao protocolo - 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 a "administradores apenas sem noção do Windows": o dce.psu.edudomínio realmente parece ser baseado no Active Directory e hospedado por servidores Windows.)}

Tente seguir estas etapas:

1. Faça logon no Kerberos. (As ferramentas kinite klistpodem estar no "krb5-user" ou em um pacote semelhante, se ainda não estiver incluído no sistema.)

   kinit your_username @ dce.psu.edu
   

   Se nenhum erro for exibido, o logon 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, tudo bem.

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

   [domain_realm]
       .psu.edu = dce.psu.edu
   

3. Com as configurações padrão do Krb5, o ticket obtido no nº 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ê deseja manter a senha em um arquivo, um simples kinit your_principal < password.txtdeve funcionar, embora não seja totalmente confiável.

   Com ktutilisso é possível fazer um "keytab" para uso em vez da senha.

   $ ktutil
   ktutil: addent -password -p your_principal -k 1 -e aes256-cts-hmac-sha1-96
   Senha do seu_principal : *********
   ktutil: wkt keytab_file 
   ktutil:  CtrlD
   

   e faça login usando:

   $ kinit -kt keytab_file  seu_principal
   

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