Quais são as implicações do SSH sem senha

Question

Se os usuários do UNIX acessarem servidores via SSH, e quisermos permitir apenas logins pubkey, há outros itens que precisem ser adicionados a essa lista, com os quais eu deveria me preocupar?

1. Permitir pubkey login no arquivo sshd_config no servidor.
2. Considerações sobre uma senha padrão, como "!" ou "*"

Answer 1

Teria sido bom saber qual servidor SSH você solicitou e quais sistemas (conjuntos de) Unix.

! e * não são senhas quando você as vê em /etc/passwd ou /etc/shadow (use getent para ler essas entradas).

São marcadores que indicam se a conta tem uma senha ou não e se está bloqueada ou não.

Esta é uma distinção importante, dependendo da configuração e versão do PAM e da distribuição, se você estiver no Linux . Se bloqueado, é menos provável que você tenha permissão para efetuar login, mas, por outro lado, é possível que ele funcione imediatamente em sistemas mais antigos (pelo menos, essa é a minha experiência).

Você pode usar (como superusuário) passwd -l <name> para bloquear uma conta ( ! ) ou passwd -d <name> para excluir a senha dela ( * ) e também pode combinar ambas, o que simplesmente garantiria que qualquer a senha existente é removida: passwd -dl <name> .

Você não diz, mas assumindo o OpenSSH as diretivas relevantes em /etc/ssh/sshd_config (o caminho pode variar) são:

HostKey ...

O servidor precisa ter uma chave de host ou RSA2 ou DSA (e a implementação mais moderna inclui também duas implementações de curva elíptica). O RSA1 foi abandonado por todas as implementações comuns de servidores SSH.

Então:

RSAAuthentication yes
PubkeyAuthentication yes
PasswordAuthentication no

Eu também recomendaria sempre configurar /etc/sudoers e completamente não permitir root login via SSH ( PermitRootLogin no ). No entanto, pode haver uma pequena desvantagem nessa configuração mais segura, quando o disco estiver cheio e seu sudo membro não privilegiado não conseguir gravar no disco, mas root (devido ao espaço reservado). Então YMMV.

Mais dois conselhos

Atribuir um grupo para limitar o acesso SSH

Crie um grupo ssh-users (ou qualquer nome que você queira) e defina a respectiva diretiva em sshd_config . Certifique-se de que root seja ou não membro desse grupo de acordo com a política escolhida com base nas informações acima.

AllowGroups ssh-users

Designe um grupo para limitar os usuários a somente acesso via SFTP

Em sshd_config , o seguinte garantirá que os usuários não possam escapar de /home e que certas funcionalidades estejam desativadas para eles.

Match group sftponly
    ChrootDirectory /home
    X11Forwarding no
    AllowTcpForwarding no
    ForceCommand internal-sftp
    PasswordAuthentication no

Conclusão

Então, sim, o PAM teria que ser adicionado como consideração no Linux.

Além disso, para permitir o encaminhamento de agentes ou deixar isso para seus usuários.

E por último, mas não menos importante, permitir que eles encaminhem portas ou conexões X11. Especialmente as portas podem ser indesejáveis, pois permitem que um usuário use seu servidor como proxy.

A diretiva Match permite que você limite usuários em relação ao local de conexão (um firewall também pode fazer isso ou os wrappers TCP).

Você deseja que seus usuários tenham permissão para gerenciar as chaves ou deseja abstrair isso e tornar o acesso direto a authorized_keys indisponível para eles?

Há certamente mais aspectos, mas eles são principalmente em um nível de detalhe mais refinado e, como tal, variações dos pontos acima mencionados.

    

Answer 2

Qualquer que seja o usuário, considere políticas de complexidade de senhas. Se o único acesso for via SSH e PasswordAuthentication for no em sshd_config , então não importa o que a senha é. Observe também que as entradas em shadow são senhas criptografadas, portanto, os valores de ! e * não são < em> senhas - mas sequências que não são valores criptografados válidos, evitando assim o login baseado em senha.

    

Answer 3

Sim, é possível, mas há uma oportunidade de alterar a senha executando um novo arquivo de senha em /etc/passwd . Eu espero que isso ajude. Se não, tente a opção provavelmente mais eficaz por menos estável de mexer com sshd_config , mas eu não recomendaria a menos que você agora o que você está fazendo.

    

Answer 4

Supondo que você esteja executando algo semelhante ao RHEL / CentOS com OpenSSH, essas são as coisas que geralmente faço quando não faço senhas:

• Configure o sshd_config para aceitar apenas a autenticação pubkey ( PubkeyAuthentication yes, PasswordAuthentication no, ChallengeResponseAuthentication no, UsePAM no )
• Definir todos os usuários existentes para ter uma senha inválida ( chpasswd -e 'pubkey!!' <username> )
• Remover a expiração da senha de todos os usuários existentes ( chage -M -1 <username> )
• Se estiver usando o sudo, verifique se todas as especificações do usuário estão marcadas como NOPASSWD (por exemplo, %wheel ALL=(ALL) NOPASSWD: ALL )
• Verifique se o processo de criação do usuário manterá esses requisitos (por exemplo, useradd -p 'pubkey!!' -K MAX_PASS_DAYS=-1 <username> )

Antes de bloquear o acesso por senha, verifique se você consegue autenticar com sucesso via pubkey. Certifique-se de que sua partição / home não esteja em uma montagem de rede (ou qualquer outra coisa que nem sempre esteja disponível). Há poucas coisas piores do que perder o acesso ao seu servidor porque ele não pode chegar ao seu pubkey. Se o sistema estiver sem cabeça, certifique-se de que você tenha acesso direto ao console em caso de emergência (KVM, console virtual, crashcart, etc).

Dito tudo, eu consideraria colocar uma senha na conta de qualquer pessoa com acesso completo ao sudo e configurar sudoers para exigir uma senha deles. Se tudo o mais estiver configurado como acima, eles ainda não conseguirão entrar no servidor com essa senha, mas isso lhe dará um pouco de proteção extra contra alguém sentado em seu prompt de comando e fazendo "coisas ruins (tm)" .

    

Answer 5

Outra consideração importante é a expiração da senha. Só porque o SSH está configurado para impor a autenticação sem senha não significa que o processo de login irá ignorar as senhas se solicitado a verificar a expiração.

Isso é extremamente importante porque não há como o SSH entrar em um servidor com uma conta de usuário que tenha uma senha expirada (por experiência própria).

A expiração da senha pode ser definida ou definida em vários locais, incluindo o arquivo passwd, o arquivo login.defs, o arquivo de autorização pam relevante, bem como outros locais (por exemplo, banco de dados). É importante verificar qual é a política de senha no seu sistema e na sua organização.

Algumas maneiras de contornar isso podem ser: 1) permitir senhas para determinados usuários no sshd_config e / ou 2) tentar que certos usuários que não tenham suas senhas expirem. Esta segunda opção provavelmente não é possível em ambientes onde as senhas são configuradas para expirar de uma configuração global, como login.defs e arquivos de autenticação pam.

    

Answer 6

Se esta é uma máquina UNIX (HP UX) e não Linux, então você precisará adicionar rcommand ao seu pam.conf sob a conta sshd.

sshd     account sufficient /usr/lib/security/libpam_ldap.1 rcommand

Caso contrário, você receberá uma solicitação de senha que não será executada ao tentar ssh na máquina.