É comum na rotina de sysadmin precisar executar algum comando nos servidores sob a sua tutela e em regras gerais estes servidores não estão exatamente na mesma sala em que o indivíduo costuma estar, por isso há muitos anos é possível acessar e executar comandos nestes servidores através dos chamados terminais remotos. Neste texto abordo o básico deste assunto e que será útil para que aspirantes ao cargo de sysadmin possam começar a se divertir feito gente grande.

Breve histórico

Existem algumas formas antigas de se trabalhar remotamente em servidores. Algumas já não são mais utilizadas por razões de segurança e outras se tornaram os xodós da TI e receberam atualizações e melhorias ao longo do tempo.

No primeiro grupo temos por exemplo o FTP e o Telnet, respectvamente para transferência de arquivos e linha de comandos interativa, que embora ainda hoje seja encontrado em switchs e roteadores o seu uso não é encorajadado, sendo muitas vezes estes recursos usados como ultima alternativa de acesso e ainda assim costuma estar por padrão desativado.

No segundo grupo temos o SSH com seu subsistema SFTP e que com o passar do tempo tem recebido atenção, atualizações e melhorias. A diferença básica entre aqueles dois do primeiro grupo e estes aqui reside no fato de que estes últimos transitam com as informações na rede de forma criptografada, evitando assim o ataque conhecido como Men-in-the-middle (Homem no meio) e o sniffing, o atacante poderia ler o conteúdo das informações que trafegam entre o servidor e a estação do administrador conseguindo assim obter não só os dados que estão sendo transferidos mas também o seu login e a senha aumentando ainda mais as possibilidades de danos.

As vantagens deste segundo grupo não se esgotam apenas ai. O SSH permite até mesmo que sessões gráficas remotas sejam inteiramente transferidas via rede, permite criar tuneis de forma que uma máquina na internet acesse uma rede local em outro ponto do planeta como se estivesse fisicamente nela entre outros recursos. Seria preciso muito mais do que este simples artigo para esgotar todas as possibilidades deste poderoso recurso.

Instalando um servidor SSH

A maioria das distribuições linux já possuem um pacote com o servidor OpenSSH précompilado e pronto para instalação então nda de ficar baixando código fonte. Tão somente procure qual é o pacote correpondente em sua distribuição e instale-o a partir do seu gerenciador de pacotes.

Nas distribuições Debian-like, como Ubuntu, Mint e o próprio Debian você deve instalar o pacote “openssh-server” que iniciará o serviço sshd em segundo plano e que ficará escutando na porta TCP/22, consumindo pouquíssimo recurso do sistema.

Executando comandos remotos

Uma vez instalado o servidor SSH já está pré-configurado e pronto para funcionar e receber conexões a partir da rede, o que deverá ser feito a partir de uma outra máquina onde haja um cliente SSH instalado, apontando-o para o endereço IP da máquina onde está o servidor com o seu devido login naquela máquina

Obs: Em geral o cliente SSH já está instalado por padrão, mas se precisar fazê-lo o pacote é algo como “openssh-client”.

A forma mais direta para executar comandos remotos via ssh é digitando a partir do seu desktop:

ssh seuusuário@seuservidor comando

Você verá uma mensagem pedindo a senha do “seuusuário” no “seuservidor” e se você a digitar corretamente então o “comando” será executado remotamente.

Suponhamos que eu precise verificar se a data do sistema (comando date) no meu servidor 192.168.5.3, onde eu tenho uma conta de login “welington”.

ssh welington@192.168.5.3 date

Após eu informar a senha do meu usuário o comando “date” seria executado naquela máquina e o resultado exibido na minha máquina. Ou seja, no terminal onde eu digitei este comando, eu veria algo como:

Sáb Nov 14 06:09:27 BRST 2011

Limites de acesso

Você pode executar qualquer comando que o seu usuário tenha privilégios para de execução naquele servidor remoto. Isso é importante lembrar, pois – com poucas exceções – será como se você estivesse fisicamente diante da máquina.

Desta maneira não adiantaria por exemplo eu tentar desligar ou reiniciar o servidor caso eu não tenha os devidos privilégios para executar o comando shutdown ou reboot naquela máquina. Geralmente, para executar estes comandos eu deveria ter permissão para acessar o sistema como usuário root, o que poderia ser feito através de um login como root, ou mesmo escalando o privilégio através de permissões concedidas via comandos “su” ou “sudo”. Assunto que será abordado oportunamente.

Mais do que um comando

No último exemplo nós apenas queriamos digitar um único comando (o comando date) então o informamos diretamente na sintaxe do comando SSH e pronto. Suponhamos que eu precise trabalhar por várias horas naquele mesmo servidor para resolver algum problema remotamente e para tal eu deverei digitar inúmeros comandos.

Neste caso não seria muito confortável digitar “ssh meulogin@servidor comando” para cada ls, mkdir mount etc que eu tenha necessidade. Nós podemos então abrir o interpretador de comandos padrão daquele servidor e então trabalhar normalmente como se estivesse diretamente no servidor.

Para tal basta que você omita o comando. Sendo assim, se eu digitar o comando abaixo, após confirmar a minha senha naquele servidor, estarei acessando o seu terminal onde poderei digitar todos os comandos que eu precisar.

ssh welington@192.168.5.3

Após informar a sua senha a forma mais direta de saber se você está no servidor correto é olhar o prompt de comandos. Veja o mesmo exemplo agora com a imagem de uma sessão SSH completa:

welrbraga@meudesktop:~$ ssh 192.168.5.3
welington@192.168.5.3's password: 
Linux servidorteste 2.6.26-2-amd64 #1 SMP Wed Sep 21 03:36:44 UTC 2011 x86_64

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
You have new mail.
Last login: Fri Nov 11 18:12:47 2011 from meudesktop
welington@servidorteste:~$

Perceba que antes de digitar o comando ssh, o prompt na minha máquina era:

welrbraga@meudesktop:~$

Após o login, ele mudou para:

welington@servidorteste:~$

Dependendo de qual seja a sua distribuição, ou como você tenha personalizado o prompt ele poderá se parecer um pouco diferente disso, mas o nome do servidor deverá aparecer, onde antes era o nome da sua máquina.

Uma breve palavra de advertência

Quando você tiver trabalhando com várias sessões SSH ao mesmo tempo tome extremo cuidado para não digitar o comando desejado no servidor errado. Eu, particularmente, costumo trabalhar com 2 a 10 sessões SSH abertas simultaneamente o que embora seja essencial para algumas atividades não posso negar que isso já me causou alguns transtornos, pois dentre as melhores situações eu já precisei reiniciar o servidor A, por exemplo, mas por descuido acabei digitando reboot e teclando ENTER no servidor B (digo dentre as melhores situações pois coisas piores do que um reboot também já aconteceram – e ninguém é imune a isso, infelizmente).

Inibindo o login como root

Não é seguro deixar aberto o acesso remoto aos servidores como usuário root (aliás alguns radicais afirmam que nem localmente isso deveria ser permitido, mas isso é papo para outro texto) então o ideal (ou próximo disso) é sempre bloquear o acesso ao SSH como root e caso precisemos executar um comando com privilégios altos, ou mesmo como outro usuário que não o nosso podemos “alterar temporariamente a nossa personalidade” através dos comandos “su” ou “sudo”.

Para impedir que alguém acesse o nosso servidor remoto com o usuário root, edite o arquivo /etc/ssh/sshd_config do seu servidor e altere a linha PermitRootLogin yes para PermitRootLogin no depois é só reiniciar o serviço ssh. Desta forma se alguém quiser acessar o seu servidor remotamente deverá ter um login especifico nele e se este comando precisar ser executado como root ele deverá ter privilégios concedidos por você através da configuração do sudo.

Acesso ao servidor SSH sem pedido de senha

Já comentei sobre este tema há algum tempo atrás, mas para simplificar bastaria você digitar o comando abaixo em sua máquina para que você tenha que digitar a senha pela última vez para acessar o o “seuservidor”:

ssh-copy-id seuusuário@seuservidor

Após digitar a sua senha, este comando vai transferir o certificado  rsa ou dsa da sua máquina para a máquina remota. O certificado é um arquivo com nome parecido com “id_rsa.pub” e que está no diretório oculto “.ssh” dentro do seu home e caso você não tenha este arquivo consulte o link que passei sobre este assunto para ler como criá-lo usando o comando ssh-keygen.

A partir de então todas as vezes que você tentar se conectar por ssh naquele servidor (com aquele dado usuário) não será mais necessário digitar a sua senha. Acredite, embora você não tenha mais que digitar a sua senha este procedimento é tão ou mais seguro do que digitar aquele conjunto estranho de letras números que você decorou, desde que apenas você use esta máquina de onde você transferiu o certificado.

Imagine a situação. Eu sou administrador do servidor 192.168.5.3 e sempre preciso executar comandos remotos nele a partir do meu desktop, mas digitar a senha a toda hora que eu preciso acessá-lo é um tédio. Isso se resolve assim:

ssh-copy-id welington@192.168.5.3

Transferindo arquivos

Transferir arquivos entre servidores é tão simples quanto acessar o seu terminal para digitar comandos e além de simples é extremamente útil, por isso um tutorial básico sobre SSH não estaria completo se não falasse sobre este aspecto.

Para não nos alongarmos muito o comando para transferência de arquivos é o que segue:

scp ORIGEM DESTINO

Onde, tanto a ORIGEM, quanto o DESTINO devem ter o seguinte formato:

usuário@servidor:caminho/arquivo

Quanto ao usuário e ao servidor consideremos o que já sabemos sobre o ssh e ainda, se tratarmos de arquivos locais devemos descartar esta parte e o “:”.

Caminho/Arquivo é o arquivo que desejamos copiar, com o seu respectivo caminho. Dependendo do contexto esta informação poderá ser omitida mas observe que se o arquivo está em uma máquina remota obrigatoriamente o “:” sempre deverá estar ali.

Vejamos os exemplos a seguir para clarear:

Exemplo 1: Enviar o arquivo /home/welrbraga/meupacote.tgz, da minha máquina, para a pasta /tmp do servidor 192.168.5.3, onde meu login é welington.

scp /home/welrbraga/meupacote.tgz welington@192.168.5.3:/tmp

Exemplo 2: Fazer o inverso do exemplo anterior. Trazer o arquivo /tmp/meupacote.tgz, do servidor 192.168.5.3, onde meu login é welington, para a minha máquina.

scp welington@192.168.5.3:/tmp/meupacote.tgz /home/welrbraga

Exemplo 3: Copiar o arquivo projetos.rar que está no servidor 192.168.5.3 home do usuário welington, para o home do usuário “braga” no servidor 192.168.5.5.

scp welington@192.168.5.3:projetos.rar braga@192.168.5.5:

 

Veja neste último exemplo a necessidade de colocar o “:” após o servidor quando trata-se de arquivos remotos. Se você esquecer disto para sua surpresa será criada uma cópia do arquivo projetos.rar em um arquivo “braga@192.168.5.5” na sua máquina.

Lembre-se que no caso de não informarmos o caminho para o arquivo será considerado que ele esteja no diretório home do seu usuário (para arquivos remotos), ou o diretório atual (para arquivos locais).

Conclusão

Há muito o que se falar sobre o SSH e este texto acabaria virando um livro se todos os seus recursos fossem abordados, o que não é meu propósito. Acredito que com estas instruções eu tenha conseguido alcançar o público que esperava. Os iniciantes na área de administração de servidores Linux.

Aqui no blog eu já escrevi alguns outros textos sobre este assunto e que talvez também lhe seja útil, por isso não vou citar nenhuma referência que não a própria seção SSH aqui do blog e o manual do ssh que é acessível a partir da linha de comandos do seu computador digitando-se “man ssh”.