É realmente seguro conectar-se a um servidor por SSH de hotéis durante uma viagem?

Question

É realmente seguro conectar-se a um servidor usando o SSH de hotéis durante uma viagem?

Servidor :
 - CentOS 7
 - Autorização somente pela chave RSA - a senha auth é negada
 - Porta não padrão

Estação de trabalho :
 - Ubuntu 14
 - senha do usuário
 - senha para usar a chave RSA (método padrão)

Talvez seja uma boa idéia manter metade da chave RSA privada em um pendrive, e automaticamente (por script) adicionar essa metade a ~ / .ssh / private_key antes de conectar-se?

A Internet será via WIFI em hotéis ou cabo em um apartamento alugado.

UPD
Desculpe por não ser claro no começo. Quero dizer segurança em dois aspectos aqui:

1. Segurança apenas da conexão SSH por meio de uma rede não confiável.
2. Segurança de um computador com a chave necessária para a conexão SSH - se for roubada, como proteger o servidor ...

Answer 1

Então, sobre fazer uma conexão ssh através de uma conexão explicitamente não confiável.

Supondo que você já tenha uma entrada ~ / .ssh / known_hosts de uma conexão anterior, sim, você deve poder se conectar sem se preocupar com o que a rede é segura ou não. O mesmo acontece se você tiver algum outro meio de verificar a chave do host ssh.

Se você nunca se conectou ao servidor antes, nem tendo outra maneira de verificar a chave do host ssh, convém ter mais cuidado com relação à rede que você usa para se conectar.

    

Answer 2

Na segunda parte da sua pergunta, você parece estar preocupado com o roubo do seu notebook e, com ele, com as chaves privadas do seu login SSH sem senha para seus servidores.

Por favor, note que isso pode ser facilmente resolvido (o problema das chaves privadas), armazenando chaves privadas "criptografadas" com uma "senha": elas podem ser criptografadas inicialmente, enquanto gera com o ssh-keygen , fornecendo uma senha no final do processo de geração ou, se você já os tiver descriptografado, usando o ssh-keygen utilitário com a opção -p . Uma vez que a chave é criptografada, a cada login você é solicitado a digitar a frase-senha relacionada e, se estiver correto, tudo continuará normalmente.

Além disso, se você não quiser digitar a senha todas as vezes que iniciar o cliente ssh, poderá usar o ssh -agent : pode acompanhar, na memória, chaves privadas não criptografadas. Você pode simplesmente executar ssh-add apontando para o arquivo que contém a chave criptografada e, depois de pedir a senha , a chave é adicionada ao conjunto gerenciado pelo ssh-agent. Posteriormente, toda vez que o cliente SSH exigir uma chave protegida por senha, o agente ssh fornecerá, de forma transparente, a chave privada não criptografada relacionada ao cliente ssh. Então, para você, não é necessário inseri-lo de forma interativa.

Observe que o ssh-agent pode gerenciar muitas teclas e, obviamente, você pode "ajustar" seu notebook / desktop para iniciar o utilitário ssh-add (para preencher o conjunto de chaves ssh-agent) no momento do login / inicialização.

Além disso, se alguém roubar seu laptop, suas chaves privadas provavelmente não são o único conteúdo "sensível" que você vai distribuir: observe que com as distribuições atuais de desktop Linux é MUITO fácil para configurar um notebook usando o sistema de arquivos "criptografados" (o /home como inicial, mas todo o / se necessário). Então, por favor, considere isso também.

Todas as opções acima, obviamente, NÃO aplicam se você NÃO confia no SEU PRÓPRIO notebook.

PS: quanto à sua possibilidade de armazenar as duas metades da chave privada não criptografada em diferentes mídias: Eu strongmente aconselho que você não faça isso, pois manter as duas partes de conteúdo confidencial em uma forma não criptografada é muito, muito pior, do que manter duas cópias completas de todo o conteúdo, criptografadas!

    

Answer 3

A primeira parte da sua pergunta já foi respondida por uma resposta anterior. De acordo com sua segunda parte, recomendo adicionar um segundo fator ao seu login do ssh usando o pam_google_authenticator. É bastante fácil configurar e configurar em qualquer distro. No caso em que a chave privada que você está carregando é roubada, eles não podem acessar seu servidor com a senha única do TOTP do google-authenticator.

link