Uma abordagem consistente e segura para contas sem senha com SSH

Question

Devo admitir que gosto de servidores sem senhas em alguns casos. Um servidor típico é vulnerável a qualquer pessoa que tenha acesso físico a ele. Então, em alguns casos, é prático bloqueá-lo fisicamente e, desde então, confiar em qualquer <\> acesso físico

.

Conceitos básicos

Em teoria, quando eu chegar fisicamente a um tal servidor, eu deveria ser capaz de executar tarefas de administração sem senha simplesmente digitando root como o login e eu não deveria ter uma senha. O mesmo pode se aplicar a contas de usuários, mas não seria realmente acessado fisicamente. Portanto, nenhuma senha do sistema é necessária para o acesso local (ocasional).

Ao acessar o servidor remotamente, seja para administração ou para conta de usuário, espero sempre usar uma chave privada SSH. É muito fácil configurar uma chave SSH para uma conta recém-criada e, portanto, nenhuma senha do sistema é necessária para o acesso remoto (regular).

# user=...
# 
# useradd -m "$user"
# sudo -i -u "$user"

$ keyurl=...
$
$ mkdir -p .ssh
$ curl -o .ssh/authorized_keys "$keyurl"

A conclusão é que, em teoria, não teríamos qualquer senhas de sistema para casos de uso como esse. Então, a questão é: como configuramos o sistema e as contas de usuário para que isso aconteça de maneira consistente e segura.

Detalhes do acesso local

Como podemos garantir que a conta root pode ser acessada localmente sem uma senha? Eu não acho que nós podemos usar passwd -d , pois isso tornaria o acesso root muito permissivo e um usuário não-privilegiado poderia mudar para fazer o root de graça, o que é errado. Não podemos usar passwd -l , pois isso nos impede de fazer login.

Observe que o acesso local é exclusivamente sobre o acesso usando o teclado local. Portanto, uma solução válida não deve permitir que qualquer usuário alterne (usando su ou sudo ).

Detalhes do acesso remoto

Até recentemente, a solução acima funcionaria, mas agora o SSH começou a verificar as contas de usuário bloqueadas. Provavelmente não podemos usar passwd -d pelos mesmos motivos. Não podemos usar passwd -u , pois apenas reclama que isso levaria ao que passwd -d faz.

Existe uma solução alternativa com a senha fictícia para esta parte.

user=...

echo -ne "$user:'pwgen 16'\n" | chpasswd

Também pode ser possível desativar totalmente a verificação de conta bloqueada no SSH, mas seria melhor manter o suporte de contas bloqueadas e apenas poder desbloqueá-las.

Notas finais

O que me interessa é uma solução que permita que você faça login na conta raiz localmente e em todas as contas, incluindo a raiz remotamente, sem nenhuma senha. Por outro lado, uma solução não deve impactar a segurança, exceto em formas explicitamente descritas, especialmente não permitindo que usuários remotos acessem a conta raiz ou a conta de outros usuários. A solução deve ser suficientemente robusta para que não cause problemas de segurança indiretamente.

Uma resposta aceita e premiada pode ou não descrever a configuração detalhada de ferramentas individuais, mas deve conter os pontos-chave para alcançar as metas estabelecidas. Observe que isso provavelmente não pode ser resolvido por meio do uso convencional de ferramentas como passwd , ssh , su , sudo e similares.

Estou pronto para melhorar a estrutura da pergunta se isso ajudar.

Mais ideias depois de ler as primeiras respostas

Apenas uma ideia - o acesso à raiz local poderia ser alcançado iniciando-se shells de raiz em vez de processos de login. Mas ainda há a necessidade de bloquear somente a autenticação de senha, não a autenticação de chave pública.

    

Answer 1

Requisitos para os quais irei oferecer soluções, como marcadores:

1. Login do console raiz sem senha
2. Login remoto de raiz sem senha de usuários pré-autorizados
3. Login remoto sem senha para contas especificadas de usuários pré-autorizados
4. Login remoto sem senha para qualquer conta de usuários pré-autorizados

Os exemplos a seguir são baseados no Debian, já que é o que eu tenho aqui para testar. No entanto, não vejo razão para que os princípios não possam ser aplicados a qualquer distribuição (ou mesmo a qualquer derivado * ix baseado em PAM).

Login do console raiz sem senha

Acho que a maneira como eu abordaria isso seria aproveitar o PAM e o arquivo de configuração /etc/securetty .

Como pré-requisito, uma senha raiz "suficientemente segura" deve ser definida. Isso não é necessário para o login do console, mas existe para tornar as tentativas de cracking de força bruta irrealistas. A conta é outra conta root perfeitamente normal.

Em /etc/pam.d/login , tenho o seguinte conjunto de linhas padrão para autenticação (aquelas que começam com a palavra-chave auth ):

auth       optional   pam_faildelay.so  delay=3000000
auth [success=ok new_authtok_reqd=ok ignore=ignore user_unknown=bad default=die] pam_securetty.so
auth       requisite  pam_nologin.so

@include common-auth
auth       optional   pam_group.so

O arquivo common-auth include referenciado contém as seguintes linhas relevantes:

auth    [success=1 default=ignore]      pam_unix.so nullok_secure
auth    requisite                       pam_deny.so
auth    required                        pam_permit.so
auth    optional                        pam_cap.so

O arquivo common-auth instrui o PAM a ignorar uma regra (a negação) se um "login UNIX" for bem-sucedido. Normalmente, isso significa uma correspondência em /etc/shadow .

A linha auth ... pam_securetty.so está configurada para impedir logins de raiz, exceto nos dispositivos tty especificados em /etc/securetty . (Este arquivo já inclui todos os dispositivos de console.)

Ao modificar ligeiramente esta linha auth , é possível definir uma regra que permita um login root sem uma senha a partir de um dispositivo tty especificado em /etc/securetty . O parâmetro success=ok precisa ser alterado para que o ok seja substituído pelo número de auth linhas a serem ignoradas no caso de uma correspondência bem-sucedida. Na situação mostrada aqui, esse número é 3 , que salta para a linha auth ... pam_permit.so :

auth [success=3 new_authtok_reqd=ok ignore=ignore user_unknown=bad default=die] pam_securetty.so

Login remoto de raiz sem senha de usuários pré-autorizados

Esta é uma inclusão direta de chaves ssh para aqueles usuários autorizados que estão sendo adicionados ao arquivo root authorized_keys .

Login remoto sem senha para contas especificadas de usuários pré-autorizados

Essa também é uma inclusão simples de chaves ssh para usuários autorizados que estão sendo adicionados ao arquivo .ssh/authorized_keys do usuário correspondente e correspondente. (O cenário típico do usuário remoto chris deseja login sem senha para o usuário local chris .

Observe que as contas podem permanecer no estado bloqueado padrão após a criação (ou seja, com apenas ! no campo de senha para /etc/shadow ), mas permitem login baseado em chave SSH. Isso requer raiz para colocar a chave no arquivo .ssh/authorized_keys do novo usuário. O que é não tão óbvio é que essa abordagem só está disponível quando UsePAM Yes está definido em /etc/ssh/sshd_config . O PAM diferencia ! como "conta bloqueada para senha, mas outros métodos de acesso podem ser permitidos" e !... "conta bloqueada. Período." (Se UsePAM No for definido, o OpenSSH considerará qualquer presença de ! iniciando o campo de senha para representar uma conta bloqueada.)

Login remoto sem senha para qualquer conta de usuários pré-autorizados

Não estava totalmente claro para mim se você queria ou não essa facilidade. Ou seja, certos usuários autorizados poderão fazer o login ssh sem uma senha em qualquer conta local.

Eu não posso testar este cenário, mas acredito que isso pode ser alcançado com o OpenSSH 5.9 ou mais recente, que permite que vários arquivos authorized_keys sejam definidos em /etc/ssh/sshd_config . Edite o arquivo de configuração para incluir um segundo arquivo chamado /etc/ssh/authorized_keys . Adicione as chaves públicas de seus usuários autorizados selecionados a este arquivo, garantindo que as permissões sejam de tal propriedade que ele seja de root e tenha acesso de gravação apenas pelo usuário root (0644).

    

Answer 2

Parece que você quer contas de usuário reais (não-raiz) com chaves ssh e NOPASSWD completo via sudo (que está disponível por padrão na maioria das distribuições Linux nos dias de hoje e também é fácil de instalar manualmente). Você pode ter senhas em branco para cada conta de usuário (que não funcionará remotamente), então o usuário executa sudo -s ou o usuário ~/.bash_profile simplesmente contém esse comando.

Sudo

Adicione cada usuário ao grupo sudo UNIX (por exemplo, usermod -a -G sudo USERNAME , embora os sistemas mais antigos tenham formas menos intuitivas de fazer isso; no pior dos casos, edite /etc/groups diretamente).

Em /etc/sudoers ou /etc/sudoers.d/local , você quer uma linha como esta:

%sudo    ALL=(ALL:ALL) NOPASSWD: ALL

Se você quiser acesso root automático, adicione isso ao perfil do usuário. Para bash , isso seria ~/.bash_profile :

sudo -s

Isso permitirá que você veja quem está conectado (tente who ou last ) e deixará os registros em /var/log/auth.log .

Login sem senha

Em sistemas mais antigos, você poderia editar /etc/passwd (ou em sistemas um pouco antigos, /etc/shadow ) e remover o hash, por exemplo, bob:$1$salt$hash:12345:0:99999:7::: se torna apenas bob::12345:0:99999:7::: . Isso foi tudo que você precisava. Sistemas modernos não gostam disso. Provavelmente, existem outras maneiras de fazer isso, mas a maneira que acabei de verificar é a seguinte ^{_{(fonte: Coisas Aleatórias de Leo )}} :

Abra /etc/shadow e observe uma conta com informações reais. Isso incluirá três elementos delimitados por cifrões ( $ ). Eles representam o mecanismo de hashing, depois o salt e, em seguida, o hash. Observe o sal e execute isso:

openssl passwd -1 -salt SALT

(Isso usa o MD5 como o mecanismo de hashing. É uma senha em branco, portanto você não deve se importar.) Quando for solicitada uma senha, pressione enter. Salve essa string, incluindo os pontos à direita, e cole-a após os dois primeiros pontos da linha do usuário em /etc/shadow (isso deve substituir qualquer conteúdo pré-existente entre o primeiro e o segundo ponto). (Por favor, não use literalmente SALT como seu sal!)

SSH

Sua configuração do daemon ssh está em /etc/sshd_config ou /etc/ssh/sshd_config . Para uma segurança adequada, recomendo incluir estas linhas:

PermitRootLogin no
PermitEmptyPasswords no

Veja o artigo Secure Secure Shell para obter medidas adicionais de segurança que você pode adicionar à sua configuração do ssh para melhor endurecê-lo contra invasores sofisticados.

Agora seus usuários não podem efetuar login via ssh devido a terem senhas vazias (essa é uma medida de segurança necessária). Isso significa que eles só podem efetuar login com chaves ssh.

Cada usuário, para cada um de seus sistemas clientes, deve criar um par de chaves ssh, por exemplo

ssh-keygen -t rsa -b 4096 -f $HOME/.ssh/id_rsa -o -a 100 -C "Bob Roberts on his laptop"

Isso produz uma chave privada em $HOME/.ssh/id_rsa e uma chave pública em $HOME/.ssh/id_rsa.pub . Peça para esse usuário enviar a você as chaves públicas e anexá-las ao $HOME/.ssh/authorized_keys deste servidor (observe que cada usuário $HOME/.ssh deve estar no modo 700, por exemplo, mkdir -p ~user/.ssh && chmod 700 ~user/.ssh ).

Usuários que não querem chaves ssh podem ser encaminhados para o sistema físico. Lá, a senha em branco irá registrá-los, e nesse ponto eles poderão digitar passwd do shell e definir uma senha, permitindo acesso remoto.

(Eu realmente usei essa técnica para dar às pessoas acesso a uma coleção de sistemas quando eu gerenciei um departamento de TI. Isso forçou os usuários a usarem chaves ssh e eu não tive que fornecer senhas. Sua% inicial ~/.bash_profile duas linhas na parte inferior: passwd e, em seguida, mv ~/.bash_profile.real ~/.bash_profile , para que definam uma nova senha no primeiro login.

Riscos

Você está colocando confiança total em seus usuários. Não há nada que impeça que um usuário mexa no arquivo ~/.ssh/authorized_keys de outro usuário e, assim, altere sua capacidade de revogar e auditar o acesso, mas isso é inevitável se você conceder acesso root completo.

Conclusão

Cada usuário é agora um membro do grupo sudo e tem acesso completo sem senha a um shell de root. Esses usuários não têm senhas para suas contas e podem fazer login remotamente usando chaves ssh.

Se você perder um de seus funcionários, poderá remover a conta dele / dela. Se um dos laptops de seus funcionários for roubado, você poderá remover a chave ssh do laptop do arquivo authorized_keys do usuário. Se você tiver uma violação de segurança, você tem logs mostrando quem está logado.