Pular para o conteúdo principal

Conforme mais e mais pessoas começam a usar o SSH no lugar do Telnet, vejo cada vez mais confusão sobre a forma como o daemon SSH trata o aviso de senha, expiração e tempos de graça. Parte da confusão é causada pela expectativa incorreta de que o SSH irá duplicar o comportamento do Telnet e do comando de login. Este blog é uma tentativa de explicar como ele funciona.

Primeiro, lembre-se que o SSH vem do mundo do Unix/Linux e que o mundo não tem o aviso de pré-validade de 7 dias com a opção de mudar a senha que o comando de login do VOS fornece. O lançamento original do daemon do SSH também não forneceu este aviso/opção.

A partir da versão 2.0.0e (correção de erros ssl-205 e ssl-268) este comportamento foi alterado para que o daemon SSH pedisse uma nova senha 7 dias antes da senha ser definida para expirar, assim como o comando de login. No entanto, as conexões que estabeleciam um túnel ficavam penduradas na solicitação de mudança de senha porque a solicitação nunca era exibida para o usuário. O problema era que a configuração do túnel normalmente não alocava um pseudo-terminal, de modo que não havia lugar para exibir a solicitação.

Assim, a partir do lançamento 2.0.0k (ssl-295), o daemon SSH foi alterado de volta ao seu comportamento original. Uma variável externa foi adicionada ao código para permitir que os sites ativassem o prompt de mudança de senha pré-validade, se assim o desejarem. Isto é feito configurando a variável sshd$pw_change_method para 1.

Observe que o comportamento do daemon SSH ao solicitar uma nova senha durante o período de advertência de 7 dias é diferente do comportamento do login ao se conectar com a Telnet. Telnet/login permite que você apenas pressione a tecla return para pular a etapa de mudança de senha. O daemon SSH exige que você mude a senha. O comportamento é diferente devido à forma como o daemon SSH está mudando a senha. Se você adicionar o argumento change_password ao comando login, você também não poderá pular a etapa de mudança de senha. Isto é basicamente o que o daemon do SSH está fazendo. O bug ssl-279 descreve esta diferença de comportamento, mas não foi considerado um bug pela Engenharia. Uma outra coisa que você pode notar se logar com o Telent/login e o SSH é que o Telnet/login informará que sua senha expirará em N dias enquanto o daemon SSH pode informar que sua senha expirará em N+1 dias. O comportamento depende da hora do dia da última mudança de senha. Isto foi reportado como bug ssl-368.

A discussão acima trata do tempo durante o período de advertência de 7 dias. E durante o período de carência (definido pelo valor de tempo_senha_grace_time do comando login_admin)? Durante o período de carência, o daemon SSH permite o login usando a senha antiga e exige que você insira uma nova senha, assim como o Telnet/login. Entretanto, a mensagem que o daemon SSH exibe é um pouco enganosa. Ela afirma que sua senha está expirando em breve. A sugestão ssl-366 foi inserida para solicitar que a mensagem seja alterada para indicar que sua senha expirou. Entretanto, independentemente da mensagem, o resultado final é o mesmo - você deve digitar uma nova senha.

O período de tempo final a considerar é após o período de carência. Durante este tempo, o daemon SSH aparece para permitir o login usando a senha antiga e solicita uma nova senha, mas depois de inserir a nova senha, ela termina a conexão. O comando Telnet/login encerrará a conexão depois que você digitar a senha antiga. Isto está documentado como sugestão ssl-367, o daemon SSH não deve solicitar uma nova senha.

Há outra diferença entre os comportamentos Telnet/login e daemon SSH quando se muda uma senha. Após alterar a senha, o daemon SSH desconectará a sessão, exigindo que você reconecte e faça o login com a nova senha.

Finalmente, mais um bug que precisa ser discutido. Se o parâmetro req_change_first_login como exibido pelo comando set_login_security for definido como "sim", então o daemon SSH tratará todas as senhas como não expiraram, independentemente de seu estado real. Este bug, ssl-361, é corrigido na versão 2.0.0u e é recomendado que qualquer módulo com o parâmetro req_change_first_login definido para sim atualize para pelo menos esta versão imediatamente.

Uma vez que o processo sshd forca um novo processo para cada conexão, é possível instalar a nova versão do arquivo sshd.pm sem forçar todos os usuários conectados SSH a sair do sistema. Para fazer isso, você precisa

  1. Alterar diretórios para >system>openssl>sbin
  2. Renomear o arquivo sshd.pm em execução para original_sshd.pm
  3. Mover uma cópia do novo sshd.pm para o diretório atual
  4. Execute the command “kill (contents <etc>sshd.pid)” to stop the parent sshd process
  5. Mude para o usuário root com o comando switch_to_root. Você precisará saber a senha do usuário root.
  6. Comece o novo processo sshd. Se você não tiver certeza de como iniciar o sshd, verifique seu módulo_start_up.cm

O procedimento para apenas alterar o valor da variável sshd$pw_change_method é quase o mesmo. Os passos 1, 2, 4, 5, e 6 são os mesmos, mas o passo 3 muda para

3. Cópia original_sshd.pm para sshd.pm

e uma nova etapa 3a é adicionada para realmente definir a variável

3a. Executar o comando

"set_external_variable sshd$pw_change_method -in sshd.pm -type integer -to 1"

© 2024 Stratus Technologies.