É possível configurar o .ssh / config para se conectar a um host com uma senha?

Question

Eu tenho meu ~/.ssh/config cheio de entradas como esta:

host foo
   hostname 1.2.3.4
   user bar
   identityfile ~/.ssh/private.pem

que me permite fazer isso:

ssh foo

para fazer login. O SSH então verifica se tenho permissão para acessar foo usando minha chave em ~/.ssh/private.pem e me permite entrar com facilidade.

No entanto, em alguns sistemas eu tenho autenticação de dois fatores, ou seja, uma senha também. Posso especificar uma senha no meu arquivo config ? É realmente possível ou você não pode fazer isso?

Muito obrigado:).

    

Answer 1

Minha resposta curta: não que eu tenha sido capaz de determinar w / OpenSSH.

Minha longa resposta:

Essa é uma ótima pergunta e raramente é considerada, na minha opinião, para não mencionar um assunto difícil e às vezes delicado. Ambas as respostas até agora são boas. Certamente você pode "codificar" sua senha em um script Expect. Além disso, a resposta sobre o desbloqueio da sua chave privada também é válida. Nikolaidis chega mais perto na minha opinião, na medida em que responde à pergunta.

O ponto principal é que não há nenhum método para especificar ou enviar na linha de comando sua senha de maneira não interativa durante a autenticação ssh usando um mecanismo interno (que eu encontrei).

Isso pode ser uma coisa da RFC ou pode ser uma coisa de implementação - não tenho certeza. Meu palpite é uma restrição à implementação, pois duvido que qualquer RFC especifique "como" uma senha deve ser tratada no processo - mas, ei, eu posso estar errado. Uma chave privada é, em algum nível, apenas uma senha muito longa e muitas vezes armazenada sem criptografia e não há restrições de implementação relativas a isso.

Mas cuidado.

Agora percebo que há mais na criptografia assimétrica (chaves pública / privada) do que apenas fazer login em um sistema remoto e que há mais no que significa se autenticar do que essa discussão. O que estou me referindo é a diferença na percepção e uso do usuário entre os dois métodos de autenticação de si mesmo (mais da resposta de Daffy).

Então, aqui está o acordo (minha opinião):

Se você está realizando autenticação de 2 fatores, geralmente há uma razão por trás disso: alguém realmente quer ter certeza de que A : um ser humano está realizando a autenticação e B : que o ser humano é realmente o ser humano que ele diz ser. Há provavelmente uma boa razão para isso .

Isso pode ser devido à conformidade devido à lei existente (Sarbanes-Oxley). Nesse caso, se alguém determinar que você está ignorando a autenticação de uma maneira que crie exposição indevida ou contra a política da empresa - como durante uma auditoria - você pode se encontrar em uma situação delicada e / ou com um deslizamento rosa.

Meu ponto é ter certeza de que você entende o que está fazendo e documentar o que está fazendo, bem como documentar a aprovação apropriada de seus superiores. Mas nesse ponto, por que ignorar as coisas e, em vez disso, apenas descobrir se é a autoridade apropriada para a situação.

Há muitos casos em que se entende e se espera que um sistema remoto precise falar com outro sistema remoto em nome de um "usuário" - como transferir arquivos, monitorar sistemas, executar backups, etc. Nessas situações, é bom configuração de autenticação de 1 fator usando chaves pública / privada e, da mesma forma, alguns desses mecanismos de autenticação não interativos tocam arquivos confidenciais (backups).

A chave (sem trocadilhos) é garantir que o mecanismo de autenticação correto esteja em vigor para a situação correta. As pessoas precisam trabalhar e isso precisa ser balanceado com segurança robusta. É por isso que existem mecanismos de autenticação sendo inventados / inventados desde os dias das senhas - Kerberos, Smart Cards, scanners oculares, what-have-you. Existem upsides para cada um, bem como desvantagens. Nenhum é perfeito (perfeito ser um conceito subjetivo).

Espero que ajude.

    

Answer 2

hhhm, não tenho certeza sobre configuração, mas você sempre pode usar um wrapper usando o expect. Algo como expect -c 'spawn ssh [email protected] ; expect password ; send "passphrase\n" ; interact'

Dessa forma, você autentica tanto pelo certificado quanto pela senha!

    

Answer 3

Você não pode adicioná-lo ao arquivo de configuração (também é uma má ideia inserir senhas em texto claro, mesmo que você possa). como sugerido, você poderia usar 'esperar', mas não tenho certeza se você tem o problema que você acha que tem. O último indivíduo que encontrei tentando resolver esse problema não percebeu como essa autenticação funcionava.

Você pode estar 100% correto (Chave Privada + Senha para o servidor), mas pode estar colocando a senha simplesmente para desbloquear sua chave privada em sua máquina local. Quando você gera a chave, solicita uma senha. a maioria das pessoas acha que isso é autenticar para o servidor remoto, não é. Ele está pedindo uma senha que você escolhe para bloquear a chave que você está prestes a criar. Tente recriar a chave deixando a senha em branco. Isso deve eliminar a senha que você está solicitando.

Thomas