O comportamento é simples de explicar e remonta décadas às primeiras versões do Unix. getty
imprime o primeiro prompt de login, mas se a autenticação falhar, o segundo e os prompts subseqüentes serão impressos pelo programa login
, com o qual getty
já se sobrepôs.
O programa login
tem um limite no número de tentativas de login antes de simplesmente sair e permite que o serviço de login seja reaberto pelo processo # 1. Em um sistema com terminais reais que são remotos, isso teria fechado o dispositivo de terminal, fazendo com que ele definisse DTR para zero, fazendo com que um modem conectado deixasse cair a conexão. A ideia era dificultar a adivinhação de senhas e contas por força bruta em uma conexão remota. (Ele se baseava em várias chamadas telefônicas, mesmo a tarifas locais, sendo caro para um invasor.) Há também um temporizador de inatividade que causa a mesma coisa. (A idéia disso é um pouco diferente; impedir que circuitos telefônicos sejam alocados indefinidamente por um terminal remoto que ainda não tenha uma sessão de login.)
Em um terminal virtual, ou em um terminal real que seja local , não há modem, nenhuma linha telefônica e nenhuma portadora para desligar; e esses mecanismos que repetem o prompt de login e definem um watchdog são amplamente inúteis. login
poderia simplesmente esperar indefinidamente sem watchdog, e sair e reciclar de forma barata o serviço de login em todas as falhas de autenticação . Mas eles ainda existem e ainda são empregados mesmo assim.
Infelizmente para você, enquanto o programa agetty
do util-linux permite que você configure pelo menos essa parte do prompt, o programa login
da shadow não. Seu prompt de login é programado no código do programa.
Isso não é universal, observe. Por exemplo, em um sistema FreeBSD, o prompt emitido pelo programa login
é configurável pela configuração login_prompt
em /etc/login.conf
.
Leitura adicional
- " Autenticação ". %código%. Manual de Formatos de Arquivos do FreeBSD. 2011-07-08.
- link
- link
- link
- link