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.
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
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:
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@...
".
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
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
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.