Existe alguma coisa que pode ser feita através de um login no console, mas não através de um login SSH?

Question

Provavelmente uma pergunta idiota, mas quero ter certeza disso. Em uma conexão SSH, você pode fazer tudo o que você pode fazer em uma conexão de console?

Em outras palavras, depois de lançar um sistema e instalar e configurar um servidor SSH nele, você pode fazer toda a sua interação com este sistema via SSH, e não usar o console (exceto nos casos em que o servidor SSH não está disponível) por algum motivo)?

    

Answer 1

Sim.

Aqui estão algumas coisas.

logon de superusuário

Em sistemas como FreeBSD e OpenBSD, o programa init permite somente o login como usuário # 0, no modo de usuário único, em terminais marcados como secure no arquivo /etc/ttys . E o programa login (diretamente no OpenBSD, através de um módulo PAM no FreeBSD) aplica o sinalizador secure no modo multiusuário.

O Debian e o Ubuntu também possuem o mecanismo /etc/securetty . Em todos eles, o console e os terminais virtuais do kernel (que não são necessariamente o console, note), o padrão é permitir o logon do superusuário.

No OpenBSD, o padrão fora do padrão para SSH não é permitir logon como superusuário ao usar senha ou autenticação interativa com teclado (mas permitir isso ao usar autenticação de chave pública). O padrão fora do padrão para SSH no FreeBSD é não permitir o logon como superusuário.

evento de saída framebuffer / programas de entrada USB

Pode-se tunelar o X através de uma conexão SSH, e pode-se interagir com programas que empregam um dispositivo terminal. Mas os programas que esperam executar E / S através do sistema de dispositivos "evento" do Linux, através de dispositivos USB HID, e através de um dispositivo framebuffer, não são operáveis via SSH.

leitura adicional

• Como usar / dev / fb0 como um console do userspace, ou envie um texto para ele

som

Geralmente, não há som sintonizado no SSH. Pode-se direcionar manualmente programas que fazem sons para um servidor PulseAudio pela LAN, ou encapsulam manualmente a partir dos clientes de som remoto para um servidor PulseAudio local. Mas nem todo som é o PulseAudio, para iniciantes.

leitura adicional

• link

Braille

Programas como BRLTTY requerem acesso direto à matriz de célula character + attribute de um dispositivo terminal virtual. Onde um servidor tem o BRLTTY configurado, ele não pode acessar as sessões de login do SSH e exibi-las em Braille, enquanto ele pode exibir as sessões de login do terminal virtual do kernel.

leitura adicional

• Jonathan de Boyne Pollard (2014). Combinando os terminais virtuais de espaço de usuário nosh com BRLTTY . Softwares.
• acessibilidade . Wiki do Debian.

modo de emergência e trabalho no modo de recuperação

O bootstrapping no modo de emergência ou modo de recuperação não inicia um servidor SSH. Nenhum dos dois modos inicia toda a excitação que sustenta a rede, muito menos os serviços de rede, como um servidor SSH.

Material imprevisível do PolicyKit

O PolicyKit tem a noção de sessões de login ativas e inativas . Isso tenta resumir o que no sistema /etc/ttys é um conjunto de vários atributos ( on , secure , network , dialup ) em uma única alternância true / false entre "ativo" e "inativo" . Isso não se encaixa perfeitamente no mundo onde o SSH e sua laia existem.

Pode-se apenas ter uma sessão de login "ativa" quando se efetua o logon no console ou em um terminal virtual do kernel. O logon via SSH é sempre considerado como uma sessão de login "inativa". Surpreendentes diferenças comportamentais podem resultar, porque os autores de software e o administrador do sistema podem conceder permissões diferentes para fazer coisas em sessões de login ativas versus inativas.

leitura adicional

• Habilitando privilégios de gerenciamento do sistema para usuários não locais - como funciona o 'polkit'?
• link
• Jeff Lane (2014-03-28). plainbox-secure-policy não funciona em ssh . Bug # 1299201. Plataforma de lançamento. Ubuntu.

Answer 2

Não , contanto que você não desative a conexão de rede (ou, se fizer isso, restabelece-a automaticamente o suficiente, o que é complicado). Os comandos não se importam intrinsecamente com a interface que eles emitem.

No entanto, é possível que uma sessão SSH tenha menos privilégios do que uma sessão de console. Neste caso, pode haver coisas que são possíveis fazer através de uma sessão SSH em princípio, mas não são autorizadas para uma sessão SSH específica, ou mesmo para todo o SSH sessões que podem ser abertas em uma configuração específica.

Efetuar login no console obviamente fornece alguns privilégios relacionados à interação do console. Tradicionalmente, isso significa ter o direito de interagir com o dispositivo terminal (teclado e display). Sistemas modernos frequentemente associam outros privilégios a um login de console, como o privilégio de montar dispositivos removíveis, acessar outros periféricos como dispositivos de áudio, iniciar uma suspensão ou reinicialização, etc. Sistemas Linux modernos usam polkit para isto, com ConsoleKit ou logind do systemd para rastrear qual usuário tem uma sessão de console ativa.

Tradicionalmente, o superusuário (root) tem todos os privilégios. Todos os privilégios significam tudo, e não importa se o root está logado através do SSH ou em um console. É comum desabilitar logins diretos via SSH, mas isso depende da configuração do sistema. A maioria dos sistemas Unix em sua configuração padrão permite que a conta root seja alcançada por meio de su ou sudo de uma sessão SSH, mas é possível desabilitar isso, por exemplo, através pam_securetty .

Os modernos sistemas Unix podem restringir a conta root, por exemplo, com o SELinux . Um sistema reforçado pode permitir sessões raiz sobre SSH, mas restringi-las de formas que não se aplicam aos logins do console. Mais uma vez, isto seria uma questão de configuração, e. a política do SELinux.