Configurando o Prompt de Login com agetty

3

Isto é um pouco excêntrico, mas por favor, tenha paciência comigo. Eu estou em um sistema Raspbian headless, mas eu percebi que isso era mais uma questão geral de linux do que uma questão de distribuição específica.

Então estou brincando e tentando simplificar / endurecer meu prompt de login tty para exibir um mínimo de informações do sistema. Eu modifiquei meu /etc/issue e /etc/motd para estar vazio e toquei em ~/.hushlogin . Isso apagou quase tudo!

Eu fiquei com o seguinte como uma experiência de login:

hostname login: user
Password:
user@hostname:~$ 

Eu não gosto que mostre o nome do host no prompt de login, e eu persegui isso. Isso me levou a a página de manual para agetty , onde modifiquei os arquivos de serviço :

/lib/systemd/system/[email protected] e

/lib/systemd/system/[email protected] ,

adicionando a opção --nohostname à linha ExecStart da seguinte forma:

[Service]
ExecStart=-/sbin/agetty --nohostname --keep-baud 115200,38400,9600 %I $TERM

Isso funciona muito bem, exceto , quando o usuário digita uma senha errada. Em seguida, ele reverte para o prompt antigo e mostra o nome do host.

Login bem-sucedido:

login: user
Password:
user@hostname:~$

Login com falha:

login: user
Password:

Login incorrect
hostname login:

Ainda mais estranho, se eu deixar o console desacompanhado por ~ 60 segundos após o login incorreto, há uma meia-impressão da palavra login, ele faz uma pausa e, em seguida, mostra o prompt de login correto.

login: user
Password:

Login incorrect
hostname login:
Log
login:

Alguma ideia que explica este comportamento? Eu acho que estou no limite do meu conhecimento aqui. Eu olhei para a fonte por agetty e, em seguida, para shadow (login.c), e eu posso ver onde a re-exibição do prompt de login acontece depois de uma falha, mas é referenciando PAMs, e eu realmente não entendo essa parte do sistema linux.

Esta questão também foi reportada contra o CentOS em 2015

    
por Ben McMahon 27.01.2018 / 03:03

1 resposta

1

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

por 04.04.2018 / 10:00