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 -vv
rastreamento 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.edu
oferece suporte à autenticação Kerberos 5 (GSSAPI) e está no dce.psu.edu
domí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 kinit
fornece 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.edu
domínio, na verdade, parece ser baseado no Active Directory e hospedado por servidores Windows.)
Tente seguir estas etapas:
Faça login no Kerberos. (As ferramentas
kinit
eklist
podem 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.
klist
deve mostrar umkrbtgt/dce.psu.edu@...
item " ".Agora conecte-se ao servidor SSH, com as
-vv
opções; se a autenticação for bem-sucedida, ótimo.Caso contrário, talvez seja necessário editar seu
/etc/krb5.conf
arquivo. Na[domain_realm]
seção, adicione o seguinte:[domain_realm] .psu.edu = dce.psu.edu
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.txt
deve funcionar, embora não seja totalmente confiável.Com
ktutil
ele é 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 ControlMaster
por esse motivo.