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

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

Servidor :
- CentOS 7
- Autorização apenas por chave RSA - Autenticação de senha 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 ideia manter metade da chave RSA privada em um pendrive e adicionar automaticamente (por script) essa metade a ~ / .ssh / private_key antes de conectar?

A Internet será feita através de WIFI em hotéis ou por cabo em um apartamento alugado.

UPD
Desculpe por não estar claro a princípio. Quero dizer segurança em dois aspectos aqui:

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

security physical-security

— Sergey Serov
fonte

Qual metade da chave RSA? A parte pública da chave do host ssh? Metade da parte privada da sua chave ssh do usuário?

— 27415 andol

metade da minha chave RSA privada, é claro :) e automaticamente por script para adicionar essa metade ao ~ / .ssh / private_key antes de conectar ao servidor.

— Sergey Serov

Você já é mais seguro que a maioria das pessoas porque está executando o Linux. Como você está executando versões recentes, você deve ter novas versões do OpenSSH que suportem criptografia mais forte. Depois de seguir tecmint.com/5-best-practices-to-secure-and-protect-ssh-server, você pode se limitar a criptografia mais forte, como stribika.github.io/2015/01/04/secure-secure- shell.html

— chicks

@chicks "mais seguro que a maioria das pessoas porque você está executando o Linux" é uma coisa boba de se dizer. SSH é SSH, independentemente de estar em execução no Linux, Unix (o Mac) ou Windows. E podemos apontar muitas falhas de segurança extremamente sérias no Linux na história recente (Heartbleed, alguém?). Apenas dizendo, vamos deixar as tolas guerras de chama do sistema operacional à margem de onde elas pertencem, porque isso distrai as questões e questões reais. Obrigado! ;-)

— Craig

@chicks Acho que é isso que eu estava tentando transmitir. Muitos problemas de segurança em todos os sistemas operacionais e a Microsoft fez grandes progressos desde o início de sua iniciativa "computação confiável * há vários anos. Eu acho que a coisa" você é mais seguro porque o Linux "desvia a conversa do problema atual em questão ( respeitosamente) ;-).

— Craig

Respostas:

Portanto, sobre como fazer uma conexão ssh por 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ê poderá se conectar sem se preocupar com o que a rede é segura ou não. O mesmo acontece se você tiver outros meios de verificar a chave do host ssh.

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

— andol
fonte

Obrigado!! Portanto, é seguro conectar-se ao servidor por SSH, mesmo através de qualquer wi-fi público?

— Sergey Serov

Na verdade, esta resposta se aplica a qualquer situação em que você deseja ssh para um servidor remoto e qualquer parte do caminho não esteja sob seu controle total (portanto, praticamente qualquer coisa além de ssh para um host local instalado recentemente ou através de um cabo de ligação cruzada )

— Hagen von Eitzen

Vale notar que, se o cliente não conhecer a chave do host, será possível um ataque MITM completo se a autenticação por senha for usada. Mas se a autenticação baseada em chave for usada, o invasor poderá apenas representar o servidor. O invasor também não poderá se autenticar no servidor real. É difícil para um invasor fornecer uma representação convincente do servidor nesse caso; portanto, você pode perceber que algo está errado antes que seja tarde demais. Em resumo: a autenticação de chave pública é muito mais segura que a autenticação de senha .

— kasperd

@kasperd: Bem, se o cliente de conexão tiver o encaminhamento de agente ativado, até a autenticação de chave pública poderá fornecer a experiência completa do MITM. Mas sim, a autenticação de chave pública é definitivamente preferível a senhas regulares, a qualquer dia.

— Andol

@kasperd: Bem, eu posso facilmente imaginar alguém descobrindo o encaminhamento de agentes, mas não entendendo completamente, colocando algo como "Host * \ n \ tForwardAgent yes" em sua ~ / .ssh / config. As pessoas fazem todo tipo de coisa louca :-)

— andol

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

Observe que isso pode ser facilmente resolvido (o problema das chaves privadas) armazenando chaves privadas "criptografadas" com uma "frase secreta": elas podem ser criptografadas inicialmente, enquanto geradas com o utilitário ssh-keygen , fornecendo uma frase secreta no final de o processo de geração ou, se você já os tiver sem script, usando o utilitário ssh-keygen com a -popção Depois que a chave é criptografada, a cada login, você é solicitado a inserir a senha relacionada e .... se estiver correto, tudo continuará normalmente.

Além disso, se você não quiser inserir a senha sempre que iniciar o cliente ssh, poderá usar o ssh-agent : ele pode rastrear, na memória, chaves privadas não criptografadas. Você pode simplesmente executar o ssh-add apontando para o arquivo que contém a chave criptografada e, após solicitar a senha, a chave é adicionada ao conjunto gerenciado pelo ssh-agent. Depois, sempre 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. Portanto, para você, não é necessário inseri-lo interativamente.

Observe que o ssh-agent pode gerenciar muitas chaves e, obviamente, você pode "ajustar" seu notebook / desktop para iniciar o ssh-addutilitário (para preencher o conjunto de chaves do 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ê distribuirá: observe que, com as distribuições atuais de desktops Linux, é MUITO fácil configurar um notebook usando "criptografado" "sistema de arquivos (o /homeinicial, mas o todo, /se necessário). Então, por favor, considere isso também.

Todas as opções acima, obviamente, NÃO se aplicam se você não confiar 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 fortemente recomendo não para fazer isso, como manter os dois pedaços de conteúdo sensível de uma forma não criptografada é muito, muito pior, do que manter dois cópias completas de todo o conteúdo, criptografadas!

— Damiano Verzulli
fonte

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

https://www.howtoforge.com/tutorial/secure-ssh-with-google-authenticator-on-centos-7

— Arul Selvan
fonte