Configurando uma caixa de salto ssh-only

Question

Estou administrando um cluster da AWS e planejo executar o acesso ssh exclusivamente por meio de uma única caixa de salto, em vez de lidar com chaves públicas ou autenticação LDAP para listas de acesso em constante mudança. Em vez disso, a chave pública da caixa de salto seria autorizada em todas as outras instâncias e gerencia quais usuários podem acessar quais outras instâncias. No entanto, não quero expor a chave privada a usuários normais.

Minha solução inicial era escrever um shell simples no bash que executasse ssh [myserver] e fizesse com que os usuários executassem ssh username@aws-jumpbox [myserver] para se conectar a myserver ou alternativamente para ter uma sessão interativa que aceitasse apenas ssh como um comando. No entanto, lembrei-me tardiamente que você não pode gerar uma sessão interativa a partir de um script de shell.

Existe uma maneira simples de alcançar o que estou procurando? Estou indo pelo caminho errado completamente?

    

Answer 1

However, I remembered belatedly that you can't spawn an interactive session from within a shell script.

Sim, você pode, mas tem que passar -t para o comando ssh (aquele que estabelece a conexão para o host de salto, não o de o salto jost). O motivo é que, se você especificar um comando ao executar ssh , por padrão, ele não alocará um tty, que é necessário para uma sessão interativa. -t corrige isso.

Algumas alternativas possíveis:

1. Faça com que o script em seu host de salto permita que seus usuários selecionem um nome de host de forma interativa, possivelmente usando algo como dialog . Desvantagem desse método: você dificulta a execução de uma sessão não-interativa.
2. Crie um usuário no host de salto por máquina de destino, nomeado após a máquina de destino. Desvantagem deste método: você precisa manter as chaves ssh dos seus usuários em muitos arquivos. Pode ser melhor usar algum sistema de gerenciamento de configuração para isso; por exemplo, o fantoche tem suporte para lidar com authorized_keys arquivos e chaves ssh diretamente. A vantagem é que você pode definir com mais facilidade qual usuário recebe acesso a qual host.

Observe que, se você não quiser que seus usuários consigam a chave privada ssh, certifique-se de que eles também não possam usar scp ou sftp em seu host de salto. Isso pode dificultar o trabalho deles.

No geral, pessoalmente, não tenho certeza se o que você está tentando fazer é uma boa ideia. Seu host de salto não resolve o problema de 'muitas chaves ssh', ele apenas o move e apresenta vários problemas (sem scp / sftp; você adiciona um host que é um grande alvo para um invasor tentando obtenha acesso a todos os hosts em sua rede e, portanto, um SPOF, em termos de segurança; o problema com sessões interativas e comandos especificados).

Em vez disso, sugiro o seguinte:

• Use um sistema de gerenciamento de configuração nos hosts da AWS e verifique se ele é executado na inicialização antes de sshd ter sido iniciado. Esta é uma boa ideia, por várias razões. Conheço fantoches melhor que as alternativas, mas há outras opções.

• se estiver usando puppet, crie um arquivo com as chaves ssh dos seus usuários, assim:

  $user_wouter_sshkey = 'ssh public key data'
  $user_john_sshkey = 'ssh public key data'
  

  Etc.

• Para cada grupo de usuários que você deseja conceder acesso a um recurso, crie um tipo definido:

  define dbassh ($username = $title) {
      ssh_authorized_key {"wouter_dba_$username":
          key => $user_wouter_sshkey,
          type => 'ssh-rsa',
          user => $username,
      }
      ssh_authorized_key {"john_dba_$username":
          key => $user_john_sshkey,
          type => 'ssh-rsa',
          user => $username,
      }
  }
  

  Etc.

• agora, em outro lugar na sua configuração de marionetes, você pode fazer coisas como:

  user {"postgres":
      ensure => present,
      purge_ssh_keys => true,
  }
  dbassh {"postgres":}
  

Answer 2

O que você descreve é um ponto único de falha e frágil. Pessoalmente, eu escolheria uma abordagem diferente: duas (ou mais) máquinas OpenBSD na frente de seu cluster, agindo como roteadores, firewalls e balanceadores de carga. Sincronize os estados do firewall com CARP e use authpf para controlar quem pode acessar o quê. Dessa forma, você pode distribuir as chaves de todos os lugares e ainda gerenciar o acesso em um único lugar. Ele separa a autenticação da autorização e elimina o ponto único de falha.

    

Answer 3

1) Estabeleça a segurança do SSH no host de salto. Permitir apenas o endereço IP público da sua empresa ou o bloco de endereços IP que o seu ISP fornece se você não tiver IPs estáticos. Em seguida, você pode forçar os usuários que podem até mesmo trabalhar de casa para a VPN em sua rede interna primeiro.

https://www.freebsd.org/cgi/man.cgi?query=sshd_config&sektion=5

2) Bloqueie logins SSH para os outros servidores para vir somente daquele servidor host de salto.

https://www.freebsd.org/cgi/man.cgi?query=sshd_config&sektion=5

3) Crie uma conta funcional nos servidores e pressione a chave SSH dessa conta funcional / admin. Bloqueie usando uma série de recursos de segurança como sudoers. MyCorporation .... mycorpsql, mycorpweb, mycorpdev, mycorpsys.

Você também pode usar efetivamente um grupo de segurança local para bloquear o su.

link

Você pode remover usuários do grupo e desativar a conta deles. Você pode criar um script no diretório raiz para isso.

Para excluir / finalizar usuários

#!/bin/bash 
#   title   : deladminusers.sh
#   syntax  : deladminusers.sh username
gpasswd -d $1 youradmingrouphere
userdel $1

Para desativar usuários

#!/bin/bash 
#   title   : disableadminusers.sh
#   syntax  : disableadminusers.sh username
gpasswd -d $1 youradmingrouphere
#makes password incomprehensible
sed -i "s/$1:/$1:!/g" /etc/shadow

Para ativar usuários

#!/bin/bash 
#   title   : enableadminusers.sh
#   syntax  : enableadminusers.sh username
gpasswd --add $1 youradmingrouphere
#makes password comprehensible again.
sed -i "s/$1:!/$1:/g" /etc/shadow

4) Pressione as teclas SSH para todos os servidores do host de salto. Em seguida, bloqueie os arquivos ssh nos perfis de contas funcionais para que eles sejam somente de leitura / execução.

fiduser@jumphost ~: ssh-keygen -t rsa
fiduser@jumphost ~: for SERVER in 'cat ~/serverlist'
do
    ssh-copy-id -i .ssh/rsa_id.pub fiduser@$SERVER
done

5) Bloqueie os usuários com permissão para o SU para os IDs funcionais e certifique-se de que o host de salto esteja travado. Desabilite o acesso binário normal no jumphost. Permitir SU e SSH para TODOS OS USUÁRIOS - Até mesmo as contas funcionais nesse host de salto, exceto para raiz. Reduzir para os requisitos mínimos para SSH sem senha, uma vez que eles estão conectados.

Não estou familiarizado com a versão do SO que você tem para um host de salto. Você terá que investigar porque é difícil explicar os comandos básicos do usuário adicionando usuários a um grupo em diferentes distribuições.

Use algumas contramedidas de força bruta. fail2ban talvez?

Certifique-se de que esteja configurado para não proibir o intervalo de IP da sua empresa. Além disso, não se esqueça de bloquear seu host interno do Jump-office.