Manual
do
Maker
.
com
Existem diversas formas de se fazer conexão remota ao Raspberry, mas vamos iniciar o assunto com as razões pelas quais pode ser útil ou necessário, e depois veremos em que situação cada uma se adequa mais.
Nem sempre queremos ter um teclado e mouse conectado ao Raspberry. Por exemplo, tenho um servidor DNS em casa que utilizo para agilizar a resolução de nomes e também para resolver nomes em minha rede local. Nele também configuro um broker MQTT para testes em minha rede IoT e eventualmente preciso configurar alguma coisa, um tópico novo no broker ou coisa do tipo. Bem, preguiça é meu forte; levantar da cadeira, conectar teclado, mouse e monitor não são tarefas que me despertam interesse.
Podemos ter um servidor de mídia, um storage, uma rede neural ou um PBX instalados em um Raspberry. Ou outra coisa, mas ter acesso remoto a partir de um PC ou notebook é uma maneira de agilizar e facilitar o acesso. Em alguns casos a interface gráfica é necessária, em outros não, por isso vamos ver aqui diversas maneiras de como fazer conexão remota ao Raspberry, começando pela nativa.
Em meados dos anos 90, Telnet ainda era uma conexão utilizada para manutenção remota. O Telnet dava acesso ao terminal do sistema operacional, mas tinha um ponto fraco, que era a ausência de criptografia no canal de dados. Já para sistemas *NIX, uma opção criada em uma universidade da Finlândia trouxe o SSH (Secure Shell), adotado até os dias de hoje. Mas ele não é apenas uma comunicação com canal de dados criptografado. Utilizando SCP, podemos fazer transferência de arquivos. Podemos simplesmente enviar um comando remoto sem estabelecer uma conexão persistente, ou podemos também abrir um programa gráfico instalado remotamente em nosso computador local! Sem dúvidas, o SSH é a conexão remota ao Raspberry mais leve que temos como opção.
Para Windows podemos utilizar o subsistema Linux, ou usar um programa como o Putty, para fazer a conexão.
Uma segunda opção é o Bitvise SSH Client, disponível nesse outro endereço. Adicionalmente ele oferece transferência gráfica de arquivos, túnel ao desktop, auto-reconexão e outras coisas mais.
O legal do Bitvise é que ele tem a versão servidor, para que seja possível a conexão ao seu computador também.
Ambas as opções anteriores são bastante populares e utilizadas, mas particularmente não hesito em sugerir o MobaXterm.
A preferência se dá pelo fato de que com o MobaXterm podemos abrir um programa remoto localmente através do túnel SSH, da mesma forma que fazemos de Linux para Linux. Esse recurso é importante para quem tem aplicativo gráfico remoto e precisa acessá-lo.
O SCP (Secure Copy) é como transferimos arquivos de um lado a outro utilizando o túnel SSH. Todos os programas anteriores dão alguma interface para fazê-lo com SCP, SFTP (Secure FTP) ou ambos os nomes.
Se estiver em uma rede local, basta fazer a conexão utilizando usuário e IP. Supondo que o Raspberry esteja utilizando o IP de uma rede local 172.16.0.2:
ssh pi@172.16.0.2
#ou
ssh -l pi 172.16.0.2
Daí basta entrar com a senha quando solicitado. A senha usa o estilo shadow, onde digitamo-la porém nada aparece; nem asterisco; mas no Windows é tudo pela janela.
O ponto fraco dessa solução acaba sendo que para um acesso de fora da rede se faz necessária a configuração de port-forwarding no roteador de entrada (o roteador que está diretamente conectado à Internet). Port forwarding é um recurso que redireciona uma conexão. Por exemplo, tendo um IP público 200.192.43.128, configuramos no roteador para redirecionar conexões à porta 22 para o host 172.16.0.2 na porta 22. Adicionalmente podemos configurar um serviço como no DNS para acessar através de um nome e assim não precisarmos saber qual o IP público de uma rede externa.
No Linux já temos nativamente o client SSH e em alguns casos, o servidor também, bastando habilitá-lo para iniciar durante o boot do sistema. Se não estiver instalado, basta fazê-lo através do gerenciador de pacotes do sistema:
sudo su
apt-get update
apt-get install openssh-server
Se já estiver instalado e não estiver em execução, basta habilitar o serviço:
sudo update-rc.d ssh enable
E para simplesmente iniciá-lo para uma seção:
sudo service ssh start
Para iniciar uma conexão remota, utiliza-se os comandos descritos anteriormente.
ssh pi@172.16.0.2
#ou
ssh -l pi 172.16.0.2
E para fazer cópia de arquivos entre os hosts, usamos o comando scp:
scp pi@172.16.0.2:/home/pi/arquivo.jpg .
O programa tem outras sintaxes e flags, mas isso é o básico para uma transferência de arquivos por um túnel criptografado.
Essa é sem dúvidas a parte mais legal do processo, principalmente no Linux. Não precisamos ter o programa instalado localmente e também não precisamos ter um servidor gráfico com desktop rodando remotamente para abrir um programa. Simplesmente fazemos uma conexão desse modo:
ssh pi@172.16.0.2 -X
E depois executamos o programa. Por exemplo:
Esse programa está instalado em meu DNS (cujo nome é "aluminio"). Repare no terminal a conexão e depois a chamada ao programa. Agora, mais um detalhe; o Raspberry é ARM, portanto os binários dele são ELF LSB EABI (Embed Application Binary Interface), enquanto em um notebook tradicional temos a arquitetura IBM x86, na qual os binários gerados são ELF 32/64 LSB. Ou seja, estamos executando um programa que jamais poderia ser executado nativamente pela diferença de arquiteturas.
O xcalc é um programa básico e está contido em ambas as plataformas, por isso tirei um shot dessas diferenças binárias para exemplificar:
Legal ou não?
Além desses recursos, ainda podemos fazer a conexão sem senha usando troca de chaves, túnel reverso e outros recursos que com um pouco de tempo pode gerar um bocado de diversão.
Em ambas as plataformas podemos também acessar um sistema remoto com rdesktop. No Linux podemos usar o programa rdesktop-vrdp com a sintaxe:
rdesktop-vrdp -u usuario -p senha ip:porta
Se não quiser passar a senha no shell para não ficar registrado no .bash_history, use o parâmetro "-p -" para que a senha seja solicitada a posteriori. Essa conexão dará acesso a uma seção gráfica remota, como se fosse um desktop em um sistema virtualizado.
Essa imagem é um "Ctrl+Chups" do Google Images, mostrando uma conexão ao Windows a partir de um Mac. No Raspberry podemos instalar algum VNCServer para fazer a conexão, como o freerdp2-shadow-x11, tigervnc-standalone-server, tightvnc-server ou outro pacote qualquer que ofereça o protocolo.
O VNC é outro velho conhecido em ambas as plataformas. Já foi um bocado pesada e ainda hoje não considero a melhor opção em nenhum aspecto, mas tem seu mérito. Para esse exemplo instalei o tigervnc-standalone-server e o client tigervnc-viewer:
Depois para testar, para iniciar a conexão remota ao Raspberry basta seguir a orientação da inicialização do serviço, descrita no primeiro terminal.
xtigervncviewer -SecurityTypes VncAuth -passwd /home/djames/.vnc/passwd :2
Essa é outra imagem usando a técnica do "Ctrl+Chups":
Mas todas as opções anteriores tem um lado negativo. Precisamos saber o IP público remoto e ter um port forwarding configurado para fazer a conexão remota ao Raspberry. Por essa razão apresento agora as estrelas desse artigo.
Esse é um velho conhecido da maioria. O Teamviewer dá acesso ao desktop nativo, de forma que é possível prestar suporte remoto com ou sem acompanhamento do usuário. Isso também é importante para o caso de aplicativos de auto-inicialização no desktop durante o boot, pois em uma seção isolada não disponibilizaria o acesso a essa aplicação e aí as coisas complicariam um bocado.
O Teamviewer é multiplataforma porém não é opensource. Para baixá-lo, acesse o site do aplicativo. Mas o Teamviewer tem um lado bastante negativo; ele é incompatível entre versões e acaba causando um bocado de aborrecimento se tivermos diversos sistemas rodando com instalações do Teamviewer em diferentes épocas.
A vantagem é que o Teamviewer utiliza um endereço público como broker, redirecionando a seção para o dispositivo dentro de uma rede sem a necessidade de uma configuração especial no roteador.
Essa é a janela padrão. Para acessar um host, deve-se entrar com o número de seção gerado (o ID à esquerda da janela) e então digitar a senha. Se a intenção é fornecer o acesso remoto, passa-se as configurações da esquerda.
Tem também a opção de acesso desacompanhado, para não depender de um usuário na outra ponta para liberar a conexão. Isso é importante para o caso de gerenciamento remoto.
Esse é meu preferido. Além de ser leve localmente instalado, a interface de conexão com o broker é direto na nuvem, portanto não dependemos de um client para a conexão, que pode ser feita a partir de qualquer dispositivo. Já escrevi um artigo dedicado a esse recurso, "DWS Remote Control para Raspberry". Um recurso extra é um status sobre o sistema, coisa que os demais não oferecem.
Gostei bastante também e é exatamente no estilo do Teamviewer, mas não é meu preferido por duas razões; ter que instalar o client e o server ocupou recursos significativos do sistema. Não acho que seja a opção ideal para conexão remota ao Raspberry, portanto, reafirmo minha preferência ao DWS. De qualquer modo, é uma opção a considerar.
Gravei um vídeo sobre o Anydesk e assim que editá-lo, disponibilizarei no canal DobitaobyteBrasil no Youtube.
Esses são programas para acesso remoto e interação com o sistema operacional. Em outro artigo pretendo mostrar sistemas de arquivos em rede, espero lembrar de escrever a respeito. Até a próxima!
Revisão: Ricardo Amaral de Andrade
Inscreva-se no nosso canal Manual do Maker no YouTube.
Também estamos no Instagram.
Autor do blog "Do bit Ao Byte / Manual do Maker".
Viciado em embarcados desde 2006.
LinuxUser 158.760, desde 1997.