Terminal remoto discado
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" para acessar um sistema. Muitos equipamentos de rede possuem uma porta serial de console, para o caso de nenhum outro método de acesso funcionar.
O texto original deste artigo era um tutorial sobre como permitir acesso TTY via modem, e estabelecer um link de Internet se necessário usando esse canal. Em apenas 20 anos, o conteúdo ficou completamente obsoleto, porque linhas discadas e modems analógicos desapareceram da face da Terra. Quando se precisa alta disponibilidade, ou uma porta dos fundos, simplesmente utiliza-se um canal secundário de Internet.
Então, o conteúdo principal foi reduzido para cobrir apenas portas seriais locais, sem modem, em que um console TTY ainda poderia ter alguma utilidade. O texto também foi atualizado para o Linux moderno, que trocou o SysVInit pelo systemd.
Historicamente, o login num console TTY Unix começa por um processo chamado "getty". A função dele é ficar ouvindo um dispositivo TTY até que alguém tente fazer login. Assim que se digita o nome de um usuário, o "getty" passa o controle para outro programa, tipicamente o "login".
Hoje em dia, esse processo de login foi absorvido pelo systemd. Eu preferia o sistema antigo, porém é fato que ficou bem mais fácil ativar o login numa porta serial.
Vamos usar como exemplo a porta /dev/ttyUSB0, que pode ser qualquer dispositivo USB-serial. No meu caso, é um conversor USB-serial TTL FTDI 232, muito popular entre Arduinistas. Usei um par deles para estabelecer um link serial.
Para habilitar login via essa porta serial, execute os seguintes comandos:
sudo systemctl enable serial-getty@ttyUSB0.service sudo systemctl start serial-getty@ttyUSB0.service
E está pronto! Na outra ponta, que seria o cliente de terminal, se for um Linux ou MacOS, use o comando
screen /dev/ttyUSB0 115200
Se quiser customizar algum aspecto do login serial, execute o comando
sudo systemctl edit serial-getty@ttyUSB0.service
A customização mais comum seria limitar o canal a uma velocidade específica. Para fazer isso, inclua as duas linhas a seguir na seção apropriada do arquivo que o comando anterior abriu para você editar:
ExecStart= ExecStart=-/sbin/agetty --keep-baud 9600 %I $TERM
Leia os comentários inclusos no arquivo aberto, porque se inserir as linhas no local errado, elas serão simplesmente descartadas. A seguir, faça valer a mudança com
sudo systemctl daemon-reload sudo systemctl restart serial-getty@ttyUSB0.service
No tempo da onça, era possível configurar as questões de segurança do login serial num arquivo chamado /etc/securetty. Hoje em dia, a configuração é via PAM. Os exemplos abundam na Internet, aqui está um.
Antes do systemd, a configuração era espalhada por diversos arquivos. O exemplo é baseado no serviço mgetty, muito utilizado no seu tempo pois também tinha a capacidade de receber fax.
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 poderia 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/ttyUSB0 -s 115200 -n 4 -m '"" ATH0S0=0 OK'
No exemplo acima, 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 ATH0S0=0 costumava ser suficiente para qualquer modem.
O "respawn" dizia ao init (antecessor do systemd) 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.
Para reler o inittab e fazer valer as configurações, rodávamos o comando init q.
O canal estabelecido via login serial pode ser usado para estabelecer um enlace de Internet. Era mais ou menos assim que funcionava a Internet discada: o discador estabelecia a conexão via modem, fazia login num terminal remoto, e então disparava um serviço PPP em ambas as pontas.
Há 25 anos atrás, era assim que eu conseguia entrar na Internet a partir da praia. Não havia nem os provedores de Internet discada tipo IG. Muito menos celular GPRS/EDGE.
É claro, isso é totalmente obsoleto, há quase duas décadas. Os provedores discados já se foram, o telefone fixo POTS está praticamente extinto no Brasil. No MacOS, nem existe mais a opção de configurar uma conexão PPP sobre canal serial.
Vou manter a "receita de bolo" aqui para o caso de alguém querer configurar o PPP sobre canal serial por qualquer outro motivo.
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.