☰

Efeito das entradas em /etc/securetty

tag-icon • tag-icon security login pam
Efeito das entradas em /etc/securetty

Por padrão no RHEL 5.5 eu tenho

[deuberger@saleen trunk]$ sudo cat /etc/securetty 
console
vc/1
vc/2
vc/3
vc/4
vc/5
vc/6
vc/7
vc/8
vc/9
vc/10
vc/11
tty1
tty2
tty3
tty4
tty5
tty6
tty7
tty8
tty9
tty10
tty11

Qual é a diferença entre cada um dos tipos de entrada ( console, vc/*, e tty*)? Especificamente, qual é o resultado final da adição e remoção de cada tipo de entrada?

Meu entendimento é que eles afetam como e quando você pode fazer login, mas há algum outro efeito? E quando você pode e quando não pode fazer login, dependendo de quais entradas existem?

EDITAR 1

O que eu sei é que isso tty1-6corresponde a saber se você pode fazer login nos primeiros 6 consoles que você acessa usando Ctrl- Alt- F1até Ctrl- Alt- F6. Sempre pensei que fossem consoles virtuais, então estou um pouco confuso. E a que consolecorresponde?

Obrigado.

EDITAR 2

Qual é o efeito, se houver, no modo de usuário único?

Responder1

/etc/securettyé consultado por pam_securettymódulo para decidir de quais terminais virtuais ( tty*) rooté permitido fazer login.

No passado, /etc/securettyera consultado diretamente por programas login, mas agora o PAM cuida disso. Portanto, as alterações /etc/securettyafetarão qualquer coisa que use o PAM com um arquivo de configuração que use pam_securetty.so. Portanto, apenas o loginprograma é afetado por padrão.

/etc/pam.d/loginé usado para logins locais e /etc/pam.d/remotepara logins remotos (como telnet).

Os principais tipos de entrada e seus efeitos são os seguintes:

  • Se /etc/securettynão existir, rooté permitido fazer login de qualquertty
  • Se /etc/securettyexistir e estiver vazio, rooto acesso será restrito ao modo de usuário único ou programas que não são restritos por pam_securetty(ou seja su, sudo, , ssh, scp, sftp)
  • Se você estiver usando devfs(um sistema de arquivos obsoleto para manipulação /dev), adicionar entradas no formulário vc/[0-9]*permitirá o login root a partir do número do console virtual fornecido.
  • Se você estiver usando udev(para gerenciamento dinâmico de dispositivos e substituição de devfs), adicionar entradas do formulário tty[0-9]*permitirá o login root a partir do número do console virtual fornecido.
  • A listagem consolenormalmente /etc/securettynão tem efeito, pois /dev/consoleaponta para o console atual e normalmente é usado apenas como o ttynome do arquivo no modo de usuário único, que não é afetado por/etc/securetty
  • Adicionar entradas como pts/[0-9]*permitirá programas que usam pseudoterminais ( pty) e pam_securettyfazer login rootassumindo que o alocado ptyé um dos listados; normalmente é uma boa ideianãoincluir essas entradas porque é um risco à segurança; permitiria, por exemplo, que alguém fizesse login no root via telnet, que envia senhas em texto simples (observe que pts/[0-9]*é o formato udevusado no RHEL 5.5; será diferente se usar devfsou alguma outra forma de gerenciamento de dispositivos).

Para o modo de usuário único, /etc/securettynão é consultado porque suloginé usado em vez de login(veja a suloginpágina de manual para mais informações). Além disso, você pode alterar o programa de login usado /etc/inittabpara cada nível de execução.

Observe que você não deve usar /etc/securettypara controlar rootlogins via ssh. Para fazer isso altere o valor de PermitRootLoginin /etc/ssh/sshd_config. Por padrão /etc/pam.d/sshdnão está configurado para consultar pam_securetty(e portanto /etc/securetty). Você poderia adicionar uma linha para fazer isso, mas sshnão define o real ttyaté algum tempo após o authestágio, portanto não funciona conforme o esperado. Durante os estágios authe account- pelo menos para openssh- o tty( PAM_TTY) é codificado para ssh.

A resposta acima é baseada no RHEL 5.5. Muito disso pertencerá às distribuições atuais de outros sistemas *nix, mas há diferenças, algumas das quais observei, mas não todas.

Eu mesmo respondi porque as outras respostas estavam incompletas e/ou imprecisas. Muitos outros fóruns, blogs, etc. on-line também contêm informações imprecisas e incompletas neste tópico, por isso fiz extensas pesquisas e testes para tentar obter os detalhes corretos. Se alguma coisa que eu disse estiver errada, por favor me avise.

Fontes:

Responder2

vc/Xe ttyXsão sinônimos: caminhos diferentes para os mesmos dispositivos. O objetivo da redundância é capturar vários casos para não bloquear você.

Tradicionalmente login(e possivelmente getty, não me lembro com certeza) verificaria /etc/securettye negaria rootlogins em terminais não listados. Nos sistemas modernos, existem outras maneiras de fazer isso e também outras medidas de segurança. Confira o conteúdo de /etc/login.defs(que também aborda securettya funcionalidade do e é recomendado pela securetty(5)página de manual) e também de /etc/pam.d/login, onde você pode controlar o comportamento deste recurso.

Como securettysó é verificado por login, os meios de login que não são usados login​​(por exemplo, SSH com use_login=no, gerenciadores de exibição X, etc.) não são afetados.

informação relacionada