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

8

Eu sei que há dúzias de perguntas aqui sobre como conectar-se a um servidor SSH sem digitar sua senha toda vez , e a resposta é sempre" usar uma chave pública ". Bem, eu me vejo nas raras circunstâncias em que isso não é uma opção. Por alguma razão inexplicável, o daemon do OpenSSH no servidor ao qual estou tentando se conectar está configurado com

RSAAuthentication no
PubkeyAuthentication no

em /etc/ssh/sshd_config . Eu não tenho nenhum acesso administrativo no servidor, portanto não posso alterar essas ou quaisquer outras opções de configuração do servidor. (Eu, claro, 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 eu quiser SSH neste servidor? Eu mantenho meus próprios computadores razoavelmente seguros, então vamos supor que os riscos de segurança de armazenar a senha em um arquivo no cliente sejam aceitáveis baixos, 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 rastreio de depuração ( -vv ):

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
    
por David Z 08.05.2012 / 21:26

3 respostas

3

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

Cada sistema é diferente, por isso não haverá um script, mas com a autoexpectação é muito fácil gravar um script para essa finalidade.

    
por 08.05.2012 / 21:33
7

A partir das informações coletadas até o momento, o servidor sftp.pass.psu.edu suporta a autenticação Kerberos 5 (GSSAPI) e está no dce.psu.edu realm.

O Kerberos é muito comum em redes com muitos servidores e estações de trabalho; muitas instituições educacionais de grande porte a montaram. Uma das vantagens da autenticação de chave pública é que um único kinit fornece automaticamente credenciais para todas as máquinas na região do Kerberos, sem ter que copiar as chaves públicas para cada uma delas. Outro é o suporte ao protocolo - as mesmas credenciais do Kerberos podem ser usadas com mais de 30 protocolos (correio, sistemas de arquivos, bancos de dados ...), não apenas SSH.

(Com relação a "administradores sem conhecimento do Windows": o dce.psu.edu realm parece ser baseado no Active Directory e hospedado por servidores Windows.)

Tente seguir estas etapas:

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

    kinit your_username@dce.psu.edu
    

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

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

    Se isso não acontecer, talvez seja necessário editar o arquivo /etc/krb5.conf . Na seção [domain_realm] , adicione o seguinte:

    [domain_realm]
        .psu.edu = dce.psu.edu
    
  3. Com as configurações padrão do Krb5, o ticket obtido em # 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.txt deve funcionar, embora não seja totalmente confiável.

    Com ktutil , é possível fazer uma "keytab" para uso em vez da senha.

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

    e faça o login usando:

    $ kinit -kt keytab_file your_principal
    
por 08.05.2012 / 22:02
2

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 seguir estas etapas para configurar o ControlMaster apenas por esse motivo.

    
por 08.05.2012 / 21:36

Tags