Terminal remoto discado

O modo texto do UNIX, seja no console ou via SSH remoto, é uma herança do tempo do terminal teletipo (TTY), a principal forma de "computação remota" até meados dos anos 80. O meio de comunicação entre o computador central e os TTY era um cabo serial, uma linha privada alugada, ou mesmo uma linha discada com modem.

O uso de TTYs via telefone tem pouca utilidade hoje em dia, mas ainda pode ser uma "porta dos fundos" interessante para acessar um sistema:

Funciona mesmo que a Internet esteja fora do ar ou desconfigurada;
Viabiliza administraçâo remota de máquinas desconectadas da Internet;
É mais seguro administrar a máquina via telefone que via Internet;
O link serial pode ser usado como base para comunicação TCP/IP, inclusive para a Internet (é assim que um provedor discado funciona, a diferença é que normalmente o computador que atende a ligação é um equipamento chamado RAS e não um PC normal).

No Linux, se você reparar nos processos, verá que há diversos "mingetty" rodando. A função dele é ficar ouvindo um dispositivo TTY (seja o console ou uma porta serial) até que alguém tente se logar. Assim que se digita o nome de um usuário, o "getty" passa o controle para outro programa, tipicamente o "login".

Se quisermos fazer login via linha discada, precisamos rodar um processo getty para a porta serial. Mas o "mingetty" é uma versão reduzida, que só funciona nos consoles do Linux, que não são dispositivos seriais normais. É preciso instalar o mgetty, uma versão mais completa que sabe lidar com portas seriais e modems.

O mgetty também permite usar o modem como secretária eletrônica e fax, mas não vamos explorar estas possibilidades neste artigo. Para o mgetty atender o telefone, você precisa ter um modem configurado e funcionando. Nos exemplos a seguir, o modem está em /dev/ttyS1 (porta serial COM2 do PC).

Segue as configurações necessárias para o mgetty atender o telefone.

Arquivo: /etc/mgetty+sendfax/login.config

Incluir a seguinte linha:

modem   -       -       /bin/login @

No caso, "modem" é o nome do usuário que será aceito pelo mgetty para login. Se você colocar um asterisco ao invés do nome, qualquer usuário cadastrado poderá entrar via linha discada.

Arquivo: /etc/mgetty+sendfax/mgetty.config

Preencher com:

port /dev/ttyS1
  speed 115200
  fax-id 47 433 3333

Este arquivo de configuração contém o fax-id porque foi copiado de uma instalação onde o modem também serve como fax.

Arquivo: /etc/inittab

Incluir:

S1:345:respawn:/sbin/mgetty /dev/ttyS1 -s 115200 -n 4 -m '"" ATH0S0=0 OK'

O parâmetro "-s 115200" configura a velocidade da porta serial (a velocidade do modem é determinada pela qualidade da conexão), o parâmetro "-n 4" faz o mgetty atender o telefone após 4 toques, e o "-m ..." é o comando usado para inicializar o modem. O comando acima deve ser suficiente para qualquer modem. O "respawn" diz ao init que este programa deve ser recarregado se morrer (e ele sempre morre no logout). O "345" diz que o mgetty deverá ser mantido vivo nos níveis de execução 3, 4, 5.

Rode o comando

init q

para que o inittab seja relido, e o mgetty carregado.

Feito isso, basta tentar discar para seu telefone com um programa de terminal (minicom no Linux, HyperTerminal ou similar no Windows). Uma vez bem-sucedido o login remoto, só falta um disco do Bee Gees e roupas de cafetão para entrar no clima dos anos 70.

Mesmo com o asterisco em login.config, você notará que o login de root não funciona. Para que login de root seja possível, inclua o dispositivo da porta serial (ttyS1 no exemplo) no arquivo /etc/securetty. Aconselhamos não fazer isto, é mais seguro obrigar-se a fazer login como usuário e usar o "su" depois.

Como foi dito, pode-se usar esta conexão como um enlace para TCP/IP. Você pode fazer do seu computador um "mini-provedor", que funciona de qualquer lugar do mundo e não depende de nenhum provedor comercial (lembrar que Internet grátis não funciona em muitas cidades pequenas, pois depende da central telefônica possuir RAS).

Segue a "receita de bolo" para fazer conexão TCP/IP com PPP, pressupondo que o usuário que pode fazer login é o "modem".

Arquivo: /home/modem/ppp (deve ser tornado executável com chmod 755)

#!/bin/sh

/usr/sbin/pppd call modem

Arquivo: /etc/ppp/peers/modem

noauth
nodefaultroute
mtu 1500
mru 1500
10.202.1.1:10.202.1.2
debug
ms-dns 10.0.1.1
unit 2

Significado dos parâmetros do arquivo "modem":

noauth	Não usa autenticação PAP, pois já autenticamos via login do terminal
nodefaultroute	Não torna esse link a rota padrâo, no lado servidor
mtu 1500	maior pacote transportado pelo link, na transmissão
mru 1500	Idem, para recepção
10.202.1.1:10.202.1.2	IP local (servidor) e remoto (cliente) que o link terá
debug	Mostra andamento da criação do link no /var/log/messages do servidor (útil para depurar quando a instalação é nova)
ms-dns 10.0.1.1	Servidor DNS informado ao cliente
unit 2	Interface de rede do lado servidor será ppp2 (se não estiver ocupada)

Depois de discar e ter a ligação atendida, o cliente deve digitar o nome (modem), a senha, e invocar o script /home/modem/ppp. Este script carrega o pppd, que é o programa que implementa o protocolo PPP no Linux. Feito isso, o cliente deve iniciar o PPP também. Normalmente, o lado cliente usa alguma ferramenta automática para isso, como o discador do Windows.

Ao invés de obrigar o cliente a invocar o script, poderíamos colocar /home/modem/ppp como "shell" da conta modem, o que faria o script ser invocado apenas digitando nome e senha. Mas preferi deixar separado para ter a chance de usar a conta também para administração remota, não apenas para Internet.

A razão do arquivo /etc/ppp/peers/modem existir é que um usuário normal (não root) que invoca o pppd, não pode passar parâmetros de configuração a ele. O usuário é obrigado a usar um "perfil" preexistente, criado pelo root. Além isso, como o pppd deste computador é o lado "servidor", somos obrigados a ter uma configuração imutável para ele.