Qualquer maneira inteligente de colocar uma senha em uma chave SSH?

Question

Meu host usa senhas em vez de id_rsa's para SSH. Mas, em vez de digitar a senha toda vez, existe uma maneira de colocar a senha no meu .ssh / config?

Por exemplo:

Host gravy_access
Hostname 127.0.0.1
User my_name_is_gravy
Password gravy_password

Para que, quando eu ssh gravy_access , permitir acesso instantaneamente.

    

Answer 1

Não, não acho que você possa fazer isso. Mas por que não criar uma chave? Crie uma chave com ssh-keygen (sem senha) e copie a parte pública para o seu host remoto e adicione-a a ~ / .ssh / authorized_keys.

Lembre-se de que qualquer pessoa que receba sua chave privada poderá acessar qualquer host no qual tenha adicionado a chave pública a ~ / .ssh / authorized_keys.

Por isso, mantenha sempre a sua chave privada privada .

Como Iain comentou abaixo, mais seguro seria criar a chave com uma senha, mas armazená-la em cache usando o ssh-agent. Digite

ssh-add your_key_file

e você será perguntado por sua senha. Ele será então armazenado em cache e, desde que você não efetue logout, ele permanecerá lá para ser usado pelo ssh para logins ou execução remota de comandos ou pelo scp.

    

Answer 2

Veja um artigo relevante sobre usando o SSH entre hosts sem o uso de senhas .

    

Answer 3

Existem 6 maneiras principais de acessar um servidor usando ssh que fornecem algum nível de segurança:

1. usando uma combinação de usuário / senha (teclado interativo)
2. usando uma identidade ssh (protegida com uma frase secreta ou não)
3. usando a autenticação baseada em host
4. usando certificados ssh
5. Kerberos
6. PAM

O seguinte pode ser de interesse:

Arquivos de identidade

Para gerar um par de arquivos de identificação ssh, use o programa ssh-key-gen para gerar um par de chaves privada (geralmente ~/.ssh/id_rsa ) e pública (geralmente ~/.ssh/id_rsa.pub ). Coloque a chave pública em um arquivo de modo 0600 chamado ~ / .ssh / authorized_keys na casa do usuário de login. Se você não usou uma frase secreta para sua chave privada, você deve conseguir fazer o login sem usar uma senha. No entanto, é mais sensato proteger sua chave privada com uma frase secreta. Pode-se evitar ter que redigitar esta frase em cada conexão, executando um processo ssh-agent e carregando a chave e a senha necessária para isso. Muitas pessoas geram um processo ssh-agent ao iniciar sua sessão X.

Você pode fazer algo nas seguintes linhas se precisar de um agente ssh:

   eval 'ssh-agent -s'
   ssh-add [optional ssh private file if not ~/.ssh/id_rsa]
   <enter passphrase>

O arquivo authorized_keys pode conter muitas chaves diferentes. Eles também podem receber controles especiais de acesso através do uso de frases de controle no início da linha de cada tecla no arquivo. Por exemplo, from="192.168.1.* no início do registro de uma chave limitará a chave para uso pelos hosts que se conectam a partir dos endereços 192.168.1.x.

Autenticação baseada em host

Autenticado com base em host permite acesso usando o nome do host remoto e o nome de usuário associados a ele. Isso usa a chave ssh do host do cliente para permitir acesso, junto com a verificação do host do cliente que acessa o host remoto. Esta é uma forma fraca de segurança e provavelmente não deve ser usada, ou se estiver em uso, deve ser usada apenas em uma LAN.

Certificados

Os certificados oferecem muitas opções interessantes que, embora sejam semelhantes à organização das chaves de identidade e authorized_keys, inverte a organização para que os controles que normalmente estão no arquivo authorized_keys estejam incorporados no certificado. Deseja dar a alguém a chance de executar date em seu servidor pelos próximos dois dias apenas como usuário bob da rede x? Os certificados parecem ser uma ótima maneira de fazer isso.

De man ssh-keygen :

ssh-keygen supports signing of keys to produce certificates that may be used for user or host authentication. Certificates consist of a public key, some identity information, zero or more principal (user or host) names and an optional set of constraints that are signed by a Certification Authority (CA) key. Clients or servers may then trust only the CA key and verify its signature on a certificate rather than trusting many user/host keys. Note that OpenSSH certificates are a different, and much simpler, format to the X.509 certificates used in ssl(8).

    

Answer 4

A autenticação sem senha é um caso de uso principal para a autenticação de chave pública (por exemplo, id_rsa). Seria uma prática de segurança incorreta colocar sua senha em um arquivo de configuração de texto simples (como .ssh/config ). Em vez disso, você deve gerar uma chave privada e pública como @rems menciona aqui e @joe menciona aqui . Certifique-se de fornecer uma frase secreta vazia para a chave privada ao criá-la com ssh-keygen.

    

Answer 5

Como outros já disseram, crie um par de chaves e implemente a chave pública no host remoto. No entanto, não seja tentado a criar chaves sem uma frase secreta. Use um agente ssh para manter as chaves privadas seguras para você. Se você estiver usando o PuTTY no Windows, então você pode usar o Concurso caso contrário, há < href="http://linux.die.net/man/1/ssh-agent"> ssh-agent .

O uso de um agente ainda exige que você insira uma senha para desbloquear a chave, mas você pode configurar por quanto tempo a chave ficará retida antes de exigir o desbloqueio novamente. Isso é muito mais seguro do que uma chave sem uma frase secreta.

    

Answer 6

Se você não tem outra escolha (porque você não tem acesso à configuração do servidor e porque a autenticação de chaves é proibida por alguma regra tola em sua organização), você pode usar sshpass , uma pequena ferramenta que faz digitação de senha interativa.