☰

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

tag-icon • tag-icon ssh password
Quais são as implicações do SSH sem senha

Se os usuários UNIX acessarem os servidores via SSH e quisermos permitir apenas logins pubkey, há algum outro item que precise ser adicionado a esta lista com o qual eu deveria me preocupar?

  1. Permitir pubkey logina entrada do sshd_configarquivo no servidor.
  2. Considerações sobre uma senha padrão, como"!"ou"*"

Responder1

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

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

São marcadores que indicam se a conta possui 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 fazer login, mas, por outro lado, é possível que 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>excluir a senha dela ( *) e também pode combinar ambos, o que simplesmente garantiria que qualquer senha existente fosse removida: passwd -dl <name>.

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

HostKey ...

O servidor deve ter uma chave de host ou RSA2 ou DSA (e implementações mais modernas também adicionam duas implementações de curva elíptica). O RSA1 foi abandonado há muito tempo por todas as implementações comuns de servidores SSH.

Então:

RSAAuthentication yes
PubkeyAuthentication yes
PasswordAuthentication no

Eu também recomendaria sempre configurar /etc/sudoerse proibir completamente rooto login via SSH ( PermitRootLogin no). No entanto, pode haver uma pequena desvantagem nesta configuração mais segura, quando o disco está cheio e seu sudomembro sem privilégios não consegue gravar no disco, mas rooto faria (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 desejar) e defina a respectiva diretiva em sshd_config. Certifique-se de que rooté ou não membro desse grupo de acordo com a política que você escolheu com base nas informações acima.

AllowGroups ssh-users

Atribuir um grupo para limitar os usuáriosapenasAcesso SFTP

A sshd_configseguir, garantiremos que os usuários não possam escapar /homee que certas funcionalidades sejam 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 uma consideração se estivesse no Linux.

Além disso, permita o encaminhamento do agente ou deixe isso para vocês, usuários.

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

A Matchdiretiva também permite limitar os usuários em relação ao local onde eles estão se conectando (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 authorized_keysindisponível para eles?

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

Responder2

Seja o que for que o usuário queira, considerando quaisquer políticas de complexidade de senha. Se o único acesso for via SSH e PasswordAuthenticationestiver noemsshd_config, então não importa qual seja a senha. Observe também que as entradas emshadowsão senhas criptografadas, portanto os valores de !e *não sãosenhas- mas strings que não são valores criptografados válidos, evitando assim o login baseado em senha.

Responder3

Supondo que você esteja executando algo semelhante ao RHEL/CentOS com OpenSSH, estas são as coisas que normalmente faço quando não uso senha:

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

Antes de bloquear o acesso por senha, certifique-se duplamente de que você consegue autenticar com êxito via pubkey. Certifique-se de que sua partição /home não esteja montada em 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 consegue acessar o seu pubkey. Se o sistema estiver sem cabeça, certifique-se de ter alguma maneira de obter acesso direto ao console rapidamente em caso de emergência (KVM, console virtual, carrinho de travamento, etc.).

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

Responder4

Se esta for uma máquina UNIX (HP UX) e não Linux, você precisará adicionar rcommandao seu pam.conf na 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á necessária ao tentar fazer o ssh na máquina.

informação relacionada