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

ssh unix

— David Z
fonte

O servidor possui um /etc/krb5.keytab? O GSSAPI (Kerberos) pode ser simples de configurar do lado do cliente; Eu teria que pedir o nome do host do servidor, no entanto. (Também: keyboard-interactiveé muito semelhante a password, exceto não limitado a um prompt "Senha:".)

— user1686

@rawrawity Não /etc/krb5.keytab, mas tem /etc/krb5/krb5.keytab. Eu não tenho acesso ao conteúdo. O nome do servidor é sftp.pass.psu.edu(acho que não há nenhum mal em dar esse nome) se ele ajudar a explicar o procedimento.

— David Z

Aah, o antigo disco de PSU. Memórias tão agradáveis. Fiquei muito feliz com a autenticação de senha. Por que você não perguntou ao pessoal de computação do campus (era CAC quando eu fui lá) em vez de procurar a rede? Quero dizer, vamos lá, eles têm um espelho do Debian. Nem todos são administradores sem noção do Windows.

— Broam

@Broam Não consigo imaginar que eu seria o primeiro a perguntar, então, presumivelmente, eles têm algum motivo para mantê-lo assim ... Suponho que não faria mal tentar, no entanto.

— David Z

Respostas:

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.

— johnshen64
fonte

Altamente inseguro, mas com um voto positivo por ser a resposta mais simples e direta.

— Zac B

bom ponto. é melhor que tudo isso seja feito atrás de um firewall e em uma rede privada.

— 9605 John Mayer

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:

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 " ".
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
```
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
```

— user1686
fonte

Parece que ele deve estar bem próximo do ideal para mim, mas não parece funcionar - eu consegui entrar com o Kerberos com êxito (sem mensagens de erro), mas ainda recebo uma senha. As mensagens de erro de ssh -vvsão semelhantes ao rastreamento que eu publiquei, exceto que recebo, em debug1: Unspecified GSS failure. Minor code may provide more information\n Server not found in Kerberos databasevez da coisa sobre o arquivo de cache de credenciais não ser encontrado.

— David Z

Ah, parece que os "administradores sem noção do Windows" configuraram o keytab para host/sftp.pass.psu.edu, mas seu nome real deveria ter sido host/lutz.cac.psu.edu. Você pode contornar isso adicionando " 128.118.2.85 sftp.pass.psu.edu" a seus / etc / hosts, mas é tipo de feio - seria muito melhor se os administradores fixa o servidor ...

— user1686

Sim, seria ... Eu vou perguntar a eles sobre isso, mas por enquanto espero que sua solução deva resolver as coisas. Eu vou tentar amanhã.

— David Z

@DavidZaslavsky: Pode ser útil mencionar a eles que o MIT Krb5 v1.10 oferece suporte a vários principais de host (ou seja, ambos host/lutz.cac.psu.edu e host/sftp.pass.psu.edu) em uma única tecla. (As versões anteriores usavam apenas a primeira.) #

— User1686 8/12/12

Desculpe, esqueci de voltar e fornecer feedback sobre isso. Depois de modificar /etc/hostscomo sugerido eu recebo debug1: Unspecified GSS failure. Minor code may provide more information Generic error (see e-text). Nada mais na saída é relevante para o erro.

— David Z

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.

— roguesys
fonte

A conexão principal seria redefinida quando eu desligasse o cliente. Portanto, essa não é uma solução ideal, mas seria uma ligeira melhora em relação à minha situação atual.

— David Z

Use screenpara proteger as conchas de terminarem na interrupção ou interrupção da conexão.

— LawrenceC