Efeito das entradas em / etc / securetty

Question

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 de adicionar e remover cada tipo de entrada?

Meu entendimento é que eles afetam como e quando você pode fazer o login, mas existem outros efeitos? E quando você e quando você não pode entrar dependendo de quais entradas existem?

EDIT 1 O que eu sei é que tty 1-6 corresponde a se você pode fazer login a partir dos 6 primeiros consoles que você acessa usando CTRL-ALT-F1 através de CTRL-ALT-F6. Eu sempre achei que eram consoles virtuais, então estou um pouco confuso. E o que console também corresponde? Obrigado.

EDIT 2 Qual é o efeito se algum no modo de usuário único?

    

Answer 1

/etc/securetty é consultado pelo módulo pam_securetty para decidir de qual raiz de terminais virtuais (ttyS) é permitido efetuar o login. No passado, /etc/securetty era consultado por programas como login diretamente, mas agora o PAM lida com isso. Portanto, alterações em /etc/securetty afetarão qualquer coisa usando o PAM com um arquivo de configuração que usa o pam_securetty.so. Portanto, somente o programa de login é afetado por padrão. /etc/pam.d/login é usado para logins locais e /etc/pam.d/remote é usado para logins remotos (como o telnet).

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

• Se /etc/securetty não existir, a raiz poderá efetuar login a partir de qualquer tty
• Se /etc/securetty existir e estiver vazio, o acesso root será restrito ao modo de usuário único ou a programas não restritos por pam_securetty (por exemplo, su, sudo, ssh, scp, sftp)
• se você estiver usando o devfs (um sistema de arquivos obsoleto para manipular / dev), incluir entradas no formato vc / [0-9] * permitirá o login root a partir do número do console virtual fornecido
• se você estiver usando o udev (para gerenciamento dinâmico de dispositivos e substituição de devfs), adicionar entradas do formulário tty [0-9] * permitirá o login raiz a partir do número do console virtual fornecido
• listar console em segurança, normalmente não tem efeito, pois / dev / console aponta para o console atual e normalmente é usado apenas como tty filename no modo de usuário único, que não é afetado por /etc/securetty
• adicionar entradas como pts / [0-9] * permitirá que programas que usam pseudo-terminais (pty) e pam_securetty façam login na raiz, assumindo que a categoria alocada seja uma das listadas; normalmente é uma boa ideia não incluir essas entradas porque é um risco de segurança; permitiria, por exemplo, que alguém fizesse login root via telenet, que envia senhas em texto simples (note que pts / [0-9] * é o formato para o udev que é usado no RHEL 5.5; será diferente se usar o devfs ou alguma outra forma de gerenciamento de dispositivos)

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

Note que para você não deve usar /etc/securetty para controlar logins root via ssh. Para isso, altere o valor de PermitRootLogin em /etc/ssh/sshd_config . Por padrão, /etc/pam.d/sshd não está configurado para consultar pam_securetty (e, portanto, /etc/securetty ). Você pode adicionar uma linha para fazer isso, mas o ssh não configura o tty real até algum tempo depois do estágio auth, então não funciona como esperado. Durante os estágios auth e account - pelo menos para o openssh - o tty (PAM_TTY) é codificado para "ssh".

A resposta acima é baseada no RHEL 5.5. Muito do que diz respeito às distribuições atuais de outros sistemas * nix, mas existem diferenças, algumas das quais eu observei, mas não todas.

Respondi a mim mesmo porque as outras respostas estavam incompletas e / ou imprecisas. Muitos outros fóruns, blogs, etc on-line têm informações imprecisas e incompletas neste tópico também, então eu fiz uma extensa pesquisa e testes para tentar obter os detalhes corretos. Se alguma coisa que eu disse estiver errada, por favor me avise.

Fontes:

• link
• link
• link
• link
• link
• link
• link
• link
• link
• link
• link

Answer 2

vc/X e ttyX são sinônimos: caminhos diferentes para os mesmos dispositivos. O objetivo da redundância é capturar vários casos para não bloqueá-lo.

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

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