Efeito das entradas em / etc / securetty

Por padrão no RHEL 5.5, 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 existem outros efeitos? E quando você pode e quando não pode fazer login, dependendo de quais entradas existem?

EDIT 1 O que eu sei é que tty 1-6 corresponde a se você pode efetuar login nos 6 primeiros consoles que você alcança usando CTRL-ALT-F1 a CTRL-ALT-F6. Eu sempre pensei que esses eram consoles virtuais, então estou um pouco confuso. E o que o console corresponde também? Obrigado.

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

/etc/securettyé consultado pelo módulo pam_securetty para decidir a partir de qual raiz dos terminais virtuais (ttyS) é permitido fazer login. No passado, /etc/securettyera consultado por programas como o login diretamente, mas agora o PAM lida com isso. Portanto, as alterações em /etc/securettyafetarão qualquer coisa usando o PAM com um arquivo de configuração que use pam_securetty.so. Portanto, apenas 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 telnet).

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

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

Para o modo de usuário único, /etc/securettynão é consultado porque o sulogin é usado em vez do login. Veja a página de manual sulogin 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 logins raiz via ssh. Para fazer isso, altere o valor de PermitRootLogin em /etc/ssh/sshd_config. Por padrão, /etc/pam.d/sshdnão está configurado para consultar pam_securetty (e, portanto /etc/securetty). Você pode adicionar uma linha para fazer isso, mas o ssh não define o tty real até algum tempo após o estágio de autenticação, para que não funcione conforme o esperado. Durante os estágios de autenticação e conta - pelo menos no openssh - o tty (PAM_TTY) é codificado para "ssh".

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

Eu mesmo respondi isso 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 uma extensa pesquisa e teste para tentar obter os detalhes corretos. Se alguma coisa que eu disse estiver errada, informe-me.

Fontes:

• http://docs.redhat.com/docs/pt-BR/Red_Hat_Enterprise_Linux/5/html/Deployment_Guide/ch-sec-network.html#s1-wstation-privileges
• http://www.mathematik.uni-marburg.de/local-doc/centos5/pam-0.99.6.2/html/sag-pam_securetty.html
• http://linux.die.net/man/1/login
• http://www.tldp.org/HOWTO/html_single/Text-Terminal-HOWTO/
• http://www.kernel.org/doc/Documentation/devices.txt
• http://en.wikipedia.org/wiki/Virtual_console
• http://en.wikipedia.org/wiki/Linux_console
• http://www.kernel.org/doc/man-pages/online/pages/man4/console.4.html
• http://www.unix.com/security/8527-restricting-root-login.html
• http://www.redhat.com/mirrors/LDP/HOWTO/Serial-HOWTO-11.html#ss11.3
• http://www.mathematik.uni-marburg.de/local-doc/centos5/udev-095/udev_vs_devfs

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), verificava /etc/securettye negava rootlogins 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 abrange securettya funcionalidade e é recomendado pela página de securetty(5)manual) e também /etc/pam.d/loginonde você pode controlar o comportamento desse recurso.

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