(o cliente é muito mais do que parece ser)
Artigo Relacionado
SSH Server (artigo que fala sobre o servidor SSH)
O SSH (Secure SHell) é um protocolo da camada de aplicação usado para acessar máquinas remotas e executar todas as tarefas como se tivesse fisicamente na máquina local. Ele roda em cima de TCP, sendo que para realizar a conexão, existe o comando "ssh" que implementa esse protocolo de acesso a máquinas remotas. Esse comando tem o objetivo de substituir outros como rlogin, rsh e famoso telnet, acrescentando mecanismos de segurança para uma comunicação encriptada entre dois hosts numa rede insegura. Além disso, é possível usar esse canal seguro do SSH para executar aplicações X11/gráficas.
Ao iniciar uma conexão SSH várias informações em nível de aplicação são trocadas para prover a encriptação de dados em nível também de aplicação. Essas informações são: a versão do protocolo SSH (1 ou 2), os algoritmos de encriptação, as chaves de codificação etc. Depois dessa troca, todos os dados da camada de aplicação são enviados encriptados. Só para se ter uma idéa dos pacotes e informações trocadas, a seguir é mostrada uma captura de um tráfego SSH realizada pelo Wireshark:
Instalação do cliente SSH
# apt-get update ; apt-get install openssh-client (com essa instalação o comando ssh já estará disponível)
Obs: ao instalar o cliente SSH três comandos ficam disponíveis: ssh, scp e o sftp. O primeiro é para acesso remoto seguro, o segundo é para cópia remota segura e o terceiro um FTP seguro. SSH significa Secure SHell, SCP Secure Copy e SFTP Secure File Transfer Program. Também existem os comandos rsh e rcp que são alias para o ssh e scp, respectivamente.
Os comandos usados a seguir são os mais comuns e que geralmente não necessitam de configurações especiais para funcionar. Eles usam a autênticação por senha, conhecido como "password authentication", que já vem habilitado por padrão no SSH. Nesse caso, os arquivos "/etc/passwd" e "/etc/shadow" são utilizados. Os algoritmos de criptografia, hash e compressão disponíveis para o "ssh" são o Diffie-Hellman, SHA, AES, CBC, 3DES, Blowfish, Cast, ArcFour, RijnDael, CTR, MD5, HMAC, UMAC, Ripemd, Zlib etc. Isso pode ser visto usando o Wireshark ou usando as opções "-vvv" do comando "ssh". Geralmente e de maneira automática, é escolhido o algoritmo de criptografia Diffie-Hellman em conjunto com o SHA e o RSA para verificar se a assinatura está correta. Com esses algoritmos é criado um túnel criptografado para que a senha seja transmitida seguramente (a senha nunca é passada em texo puro) e os dados subsequente também.
Comandos do cliente SSH
# ssh 172.16.200.254 (o usuário usado nessa conexão ssh será o mesmo que está logando. Neste caso será o root - observe o "#" no inicio do comando que indica quem está logado é o root)
# ssh [email protected] (especifica o usuário "suporte")
# ssh -l suporte 172.16.200.254 (idem)
# ssh -l suporte 172.16.200.254 -p 1555 (idem, especificando a porta)
# ssh -l suporte 172.16.200.254 -p 1555 ls /home(idem, especificando o comando a ser usado no servidor remoto. Não permanece logado no servidor remoto)
Obs: ao executar comando (ex: ls, cp etc) com o `ssh` tudo o ocorrerá no servidor remoto. Assim, não se consiguirá copiar um arquivo da máquina remota para a máquina local. Para isso, use o ´scp´. Isso vale para comando também (ex: /etc/init.d/servico restart), ele será executado na máquina remota. Contudo, as saídas padrão e de erro aparecerão na máquina local.
# ssh -1 -l suporte 172.16.200.254 -p 1555 ls /home(idem, especificando o protocolo ssh versão 1 que trabalha com encriptação simples)
# ssh -2 -l suporte 172.16.200.254 -p 1555 ls /home(idem, especificando o protocolo ssh versão 2 que trabalha com encriptação mais elaborada)
# ssh -4 -l suporte 172.16.200.254 -p 1555 ls /home(idem, forçando o uso do IPv4)
# ssh -6 fe80::250:daff:fe73:c49f%eth0 (forçando o uso do IPv6. Deve-se especificar a interface local de rede usada para a comunicação que nesse caso foi a "eth0")
# scp arq.txt 172.16.200.254:/home/(copia o "arq.txt" da máquina local para o diretório "/home/" da máquina 172.16.200.254)
# scp 172.16.200.254:/etc/resolv.conf /tmp (copia o "/etc/resolv.conf" da máquina 172.16.200.254 para o diretório "/tmp" da máquina local)
# scp 172.16.200.254:/etc/resolv.conf /tmp -P 1555 (idem, mas usando a port 1555)
# scp 172.16.200.254:/etc/resolv.conf* /tmp -P 1555 (idem, só que copiará todos os arquivos que iniciarem com "resolv.conf")
# scp -r [email protected]:/var/www /tmp (copia recursivamente o diretorio "/var/www/" da maquina "172.16.200.254" para o diretorio "/tmp/" da maquina local. Alem disso, especifica que o usuaria que vai logar e o "root", ou seja, o usuario de destino)
Obs1: Vale evidenciar que ao definir um usuário que será usado para autênticação, ele deve existir no destino (máquina remota). Por exemplo, ao usar o comando "ssh [email protected]", o usuário "suporte" deve existir na máquina remota. Com isso, podemos observar que o usuário que definimos com o comando "ssh" é um usuário do destino.
Obs2: Com as observações acima, vimos que precisamos de um usuário no destino. Contudo, também temos um usuário de origem que nada mais é que o usuário o qual estamos logados no momento. Vamos supor a seguinte situação: a máquina local se chama "workstation01", o seu domínio é "matrix.lan.br" e estamos logados como "root". Já a máquina remota, a qual estamos tentando nos conectar via SSH, se chama "server05", o seu domínio é "debian.wan.br" e tentaremos logar o usuário "suporte". O comando na máquina local para logar na máquina remota seria assim: ssh [email protected]. Até aqui tudo tranquilo né? Contudo, podemos extrair algumas informações de todos esses dados. O "[email protected]" é o nome completo do usuário de origem, ou seja, da máquina local. Já [email protected] é o nome completo do usuário de destino, ou seja, da máquina remota.
Obs3: Agora que já foi colocado as duas observações acima, vamos suporte um outra situação: a máquina local se chamasse "workstation01", o seu domínio é "matrix.lan.br" e estamos logados como "root". Já a máquina remota, a qual estamos tentando nos conectar via SSH, se chamasse "server05", o seu domínio é "debian.wan.br" e tentaremos logar o usuário "root". O comando na máquina local para logar na máquina remota poderia ser assim: ssh server05.debian.wan.br. Até aqui tudo tranquilo né? Contudo, podemos extrair alguns dados novamente. O "[email protected]" é o nome completo do usuário de origem, ou seja, da máquina local. Já o nome completo do usuário de destino, ou seja, da máquina remota foi [email protected]. Apesar do nome de usuário serem iguais, eles pertencem a máquinas diferentes.
Obs4: Esses conceitos das observações acima são muito importantes, pois são utilizados em arquivos como "/etc/hosts.allow" e "/etc/hosts.deny" do TCPWrapper que podem permitir ou bloquear uma determinada conexão remota através do nome do usuário de origem.
Os comandos utilizados até agora devem satisfazer a maioria dos casos, mas se estiverem pensando em algo mais elaborado e seguro, utilizando as melhores e atuais técnicas de criptografia, então veja os comandos a seguir. Veja que podemos usar dois algoritmos de criptografia o RSA e o DSA. Escolha um desses. Só para conhecimento, se pode utilizar os dois algoritmos simultaneamente:
# ssh-keygen (gera, gerencia e converte chaves de autenticação. Ao digitar esse comando, estaremos gerando um par de chaves RSA, uma pública e uma privada. Será pedido para digitar um PASSPHRASE, caso não se digite, não haverá PASSPHRASE. Por padrão, a nossa chave privada será salva em "~/.ssh/id_rsa" e a pública em "~/.ssh/id_rsa.pub". Dependendo da versão do RSA, esses nomes para chaves privada e pública poderão ser "~/.ssh/identity" e "~/.ssh/identity.pub", respectivamente. Também, será mostrada a fingerprint/impressão digital da chave também conhecida como HASH. Além disso, será mostrada uma imagem em modo texto que é chamada de randomart/arte randômica, onde é exposto que os pares de chaves terão 2048 bits. Veja na figura a seguir como ficou isso tudo)
Obs1: a PASSPHRASE é armazenada na chave privada. Vale destacar, também, que na chave privada (~/.ssh/id_rsa) somente o dono tem direito de ler e escrever. Já na chave pública (~/.ssh/id_rsa.pub) o dono tem tem direito de ler e escrever, contudo o grupo e os outros tem direito de ler. Isso é uma questão de segurança que envolve o conceito de chave pública e privada. A PASSPHRASE deve sempre ser considerada como uma aliada na segurança e não como uma inimiga da usabilidade, pois imaginem que a sua chave privada seja roubada, a única proteção para que o bandido não se passe por você será a PASSPHRASE.
Obs2: para conhecimento, os nomes da chave privada "~/.ssh/identity" e da chave pública "~/.ssh/identity.pub" devem significar que foram geradas a partir da versão 1 do protocolo SSH, usando o algoritmo RSA. Já os nomes da chave privada "~/.ssh/id_rsa" e da chave pública "~/.ssh/id_rsa.pub" devem significar que foram geradas a partir da versão 2 do protocolo SSH, usando o algoritmo RSA. Além disso, os nomes da chave privada "~/.ssh/id_dsa" e da chave pública "~/.ssh/id_dsa.pub" devem significar que foram geradas a partir da versão 2 do protocolo SSH, usando o algoritmo DSA. No entando, ao exportar ou disponibilizar as chaves públicas de qualquer versão do SSH e de qualquer algoritmo, elas devem ter o nome "~/.ssh/authorized_keys".
Agora com as chaves a nossa disposição, enviaremos a chave pública para o servidor que queremos nos conectar. Mas aí vem a pergunta: Como fazer isso? e também vem outra pergunta: Como fazer isso de forma segura? A resposta é simples, utilizaremos o comando "scp", conforme exposto a abaixo:
# ssh-copy-id -i 172.16.200.254 (copia a chave pública "id_rsa.pub" para o servidor "172.16.200.254", sendo que ela ficará na pasta "/root/.ssh/" com o nome "authorized_keys". Essa conexão remota esta utilizando o usuário "root", por causa do cerquila "#". O "-i" supõe que não está sendo usada o "ssh-agent + ssh-add")
# scp id_rsa.pub 172.16.200.254:/root/.ssh/authorized_keys (idem, só para conhecimento)
Obs: no comando "scp" mostrado acima, ao copiar a chave pública do cliente para o servidor, o seu nome foi mudado de "id_rsa.pub" para "authorized_keys". Isso foi intencional, pois por padrão o servidor SSH no Debian GNU/Linux ao receber uma tentativa de conexão, procurará pelo arquivo "~/.ssh/authorized_keys" ou "~/.ssh/authorized_keys2" . Isso está configurado dentro do arquivo de configuração do servidor SSH em "/etc/ssh/sshd_config" na linha chamada "AuthorizedKeysFile". Lembre-se que ao modificar tal arquivo é necessário digitar o comando "/etc/init.d/ssh restart".
# ssh 172.16.200.254 (agora sim, será pedido a PASSPHRASE digitada anteriormente. Digiti-a para conseguir entrar no servidor SSH utilizando o algoritimo de criptografia RSA. Caso se erre por três vezes a PASSPHRASE ou aperte o ENTER sem digitar algo será pedido que use a autenticação simples por senha, ou seja, sem chaves privada e pública. Essa conexão remota está utilizando o usuário "root", por causa do cerquila "#")
Obs1: dependendo da versão do SSH que esteja usando, a chave privada RSA poderá se chamar "id_rsa" ou "identity". Mas isso pode ser mudado dentro do arquivo de configuração. No caso de um cliente SSH, basta verificar a linha chamada "IdentityFile" dentro de "/etc/ssh/ssh_config". No Debian GNU/Linux existem 3 linhas "IdentityFile" comentadas apontando para 3 arquivos diferentes: "id_rsa", "identity" e "id_dsa" (incluí esse último arquivo só para conhecimento, pois ele trabalha com chaves DSA em vez do RSA). Apesar de tais linhas estarem comentadas, ao usar o comando "ssh" (como é o caso do comando acima) será tentado usar como chave privada esses três arquivos para conexão com o servidor SSH. A chave privada que existir será confrontada com a chave pública que está no servidor. Se a PASSPHRASE digitada estiver correta, o login será efetuado.
IMPORTANTÍSSIMO: caso tenha problemas com o comando anterior utilize esse comando para debugar: ssh [email protected] -vvv .
Obs2: tenha sempre em mente que, de uma forma geral, o cliente sempre trabalha com a chave privada e o servidor (computador que vai ser acessado remotamente) sempre com a chave pública ;-)
# scp arq.txt 172.16.200.254:/home/ (agora sim, também será pedido a PASSPHRASE digitada anteriormente. Digiti-a para conseguir copiar o arquivo para o servidor SSH, utilizando o algoritimo de criptografia RSA)
# ssh-agent (gera uma saída na tela, conforme figura a seguir. Como pode ser visto, gera algumas variáveis de ambiente projetadas para cache da chave privada, usada na autênticação da chave pública. A ideia do ssh-agent é criar uma chave, armazenando-a para autenticar um usuário sem a necessidade de digitar uma senha)
# eval $(ssh-agent) ou eval `ssh-agent` (idem, só que lê a saída que é gerada na tela pelo comando "ssh-agent" e a executa)
# ssh-add (adiciona as chaves privadas que estão no cache do "ssh-agent", ou seja, do agente de autênticação. As chaves são as que estão dentro de ~/.ssh/. Ao digitar esse comando será pedido a PASSPHRASE. Então, digite-a)
TESTE
# ssh 172.16.200.254 (veja que agora foi acessada a máquina remota sem pedir a PASSPHRASE)
# ssh-keygen -t dsa (gera, gerencia e converte chaves de autenticação. Ao digitar esse comando, estaremos gerando um par de chaves DSA, uma pública e uma privada. Será pedido para digitar um PASSPHRASE, caso não se digite, não haverá PASSPHRASE. Por padrão, a nossa chave privada será salva em "~/.ssh/id_dsa" e a pública em "~/.ssh/id_dsa.pub". Na versão 1 do SSH, esses nomes para chaves privada e pública poderão ser "~/.ssh/identity" e "~/.ssh/authorized_keys", respectivamente (na verdade o nome authorized_keys é usado quando exportamos a chave pública para o computador remoto). Também, será mostrada a fingerprint/impressão digital da chave também conhecida como HASH. Além disso, será mostrada uma imagem em modo texto que é chamada de randomart/arte randômica, onde é exposto que os pares de chaves terão 1024 bits. Veja na figura a seguir como ficou isso tudo)
Obs: a PASSPHRASE é armazenada na chave privada. Vale destacar, também, que na chave privada (~/.ssh/id_dsa) somente o dono tem direito de ler e escrecrer. Já na chave pública (~/.ssh/id_dsa.pub) o dono tem tem direito de ler e escrever, contudo o grupo e os outros tem direito de ler. Isso é uma questão de segurança que envolve o conceito de chave pública e privada.
Agora com as chaves a nossa disposição, enviaremos a chave pública para o servidor que queremos nos conectar. Mas aí vem a pergunta: Como fazer isso? e também vem outra pergunta: Como fazer isso de forma segura? A resposta é simples, utilizaremos o comando "scp", conforme exposto a abaixo:
# scp id_dsa.pub 172.16.200.254:/root/.ssh/authorized_keys2 (copia a chave pública "id_rsa.pub" para o servidor "172.16.200.254", sendo que ela ficará na pasta "/root/.ssh/" com o nome "authorized_keys2". Essa conexão remota está utilizando o usuário "root", por causa do cerquila "#")
Obs: no comando "scp" mostrado acima, ao copiar a chave pública do cliente para o servidor, o seu nome foi mudado de "id_dsa.pub" para "authorized_keys2". Isso foi intencional, pois por padrão o servidor SSH no Debian GNU/Linux ao receber uma tentativa de conexão, procurará pelo arquivo "~/.ssh/authorized_keys" ou "~/.ssh/authorized_keys2". Isso está configurado dentro do arquivo de configuração do servidor SSH em "/etc/ssh/sshd_config" na linha chamada "AuthorizedKeysFile". Lembre-se que ao modificar tal arquivo é necessário digitar o comando "/etc/init.d/ssh restart".
# ssh 172.16.200.254 (agora sim, será pedido a PASSPHRASE digitada anteriormente. Digiti-a para conseguir entrar no servidor SSH utilizando o algoritimo de criptografia RSA. Caso se erre por três vezes a PASSPHRASE ou aperte o ENTER sem digitar algo será pedido que use a autenticação simples por senha, ou seja, sem chaves privada e pública. Essa conexão remota esta utilizando o usuário "root", por causa do cerquila "#")
Obs1: dependendo da distribuição que esteja usando, a chave privada DSA poderá se chamar "id_dsa" ou "identity". Mas isso pode ser mudado dentro do arquivo de configuração. No caso de um cliente SSH, basta verificar a linha chamada "IdentityFile" dentro de "/etc/ssh/ssh_config". No Debian GNU/Linux existem 3 linhas "IdentityFile" comentadas apontando para 3 arquivos diferentes: "id_rsa", "identity" e "id_dsa". Apesar de tais linhas estarem comentadas, ao usar o comando "ssh" (como é o caso do comando acima) será tentado usar como chave privada desses três arquivos para conexão com o servidor SSH. A chave privada que existir será confrontada com a chave pública que está no servidor. Se a PASSPHRASE digitada estiver correta, o login será efetuado.
IMPORTANTÍSSIMO: caso tenha problemas com o comando anterior utilize esse comando para debugar: ssh [email protected] -vvv .
Obs2: tenha sempre em mente que, de uma forma geral, o cliente sempre trabalha com a chave privada e o servidor (computador que vai ser acessado remotamente) sempre com a chave pública ;-)
# scp arq.txt 172.16.200.254:/home/ (agora sim, também será pedido a PASSPHRASE digitada anteriormente. Digiti-a para conseguir copiar o arquivo para o servidor SSH, utilizando o algoritimo de criptografia DSA)
# ssh-agent (gera uma saída na tela, conforme figura a seguir. Como pode ser visto, gera algumas variáveis de ambiente projetadas para cache da chave privada, usada na autênticação da chave pública. A ideia do ssh-agent é criar uma chave, armazenando-a para autenticar um usuário sem a necessidade de digitar uma senha)
# eval $(ssh-agent) ou eval `ssh-agent` (idem, só que lê a saída que é gerada na tela pelo comando "ssh-agent" e a executa)
# ssh-add (adiciona as chaves privadas que estão no cache do "ssh-agent", ou seja, do agente de autênticação. As chaves são as que estão dentro de ~/.ssh/. Ao digitar esse comando será pedido a PASSPHRASE. Então, digite-a)
TESTE
# ssh 172.16.200.254 (veja que agora foi acessada a máquina remota sem pedir a PASSPHRASE)
Host Based Authentication é um tipo de acesso remoto sem o uso de senha, baseando-se no HostName ou IP do cliente em conjunto a chave RSA ou DSA do servidor.
Arquivo de configuração# vi /etc/ssh/ssh_config
HostbasedAuthentication yes (especifica a autênticação baseada em host)
EnableSSHKeysign yes (é usado pelo XXX para acessar as chaves do host local e gerar um assinatura digital requerida durante o host-based authentication na versão 2 do SSH)
Agora que já configuramos o cliente, acesse o artigo SSH Server na parte "Host Based Authentication" para saber como configurar o servidor. Depois disso, digite o comando a seguir para testar:
# ssh usuario@endereco_servidor (não deverá ser solicitada a digitação de senha)# vi /etc/ssh/ssh_config (arquivo de configuração global do cliente ssh. Toda vez que é executado o comando "ssh" e seus equivalentes o arquivo "/etc/ssh/ssh_config" é lido)
# vi ~/.ssh/config (arquivo de configuração individual dos usuários)
Host * (o "Host" significa uma sessão separada e o "*" significa que vale para todos os hosts, ou seja, inicia uma sessão onde as opções valerarão para todos os hosts)
#ForwardAgent no ()
#ForwardX11 no (essa opção faz com que as conexões X11 sejam aceitas. O padrão é "no". Mais detalhes sobre essas opção, vá ao final desse artigo)
#ForwardX11Trusted yes (para uma maior compatibilidade com programas X11, essa opção deve ser "yes", fazendo com que o cliente "ssh" seja considerado confiável não previnindo roubo de dados/conexão X11. O padrão no Debian é "yes")
#RhostsRSAAuthentication no (especifica a autênticação baseada em rhosts deve ser com RSA. Somente para usada na versão 1 do SSH. Para a versão 2 use "HostbasedAuthentication")
#RSAAuthentication yes (especifica se o cliente pode usar a autênticação RSA. Esta opção só é válida para a versão 1 do SSH)
#PasswordAuthentication yes (especifica se o cliente pode usar a autênticação por senha)
#HostbasedAuthentication no (especifica a autênticação baseada em rhosts deve ser com RSA. Somente para usada na versão 2 do SSH. Para a versão 1 use "RhostsRSAAuthentication")
#Port 22 (especifica a porta padrão para conectar no host remoto. O padrão é 22)
#Protocol 2,1 (especifica a versão do protocolo SSH que deve ser suportado em ordem de preferência. Nesse caso a preferência é a versão 2 e depois a 1)
#SendEnv LANG LC_* (especifica quais variáveis do ambiente local deve ser enviadas para o servidor/host remoto. Somente suportado na versão 2)
HashKnownHosts yes (indica se o SSH deve fazer o HASH do endereço IP e do HostName do computador remoto e armazená-los em "~/.ssh/known_hosts". É nesse arquivo onde é armazenada a chave púbica RSA do servidor que também é conhecida como RSA key fingerprint. Na primeira vez em que autenticar em uma máquina remota será necessário aceitar o "RSA key fingerprint" para conseguir o acesso, conforme figura a seguir. Cada IP e HostName deve ter seu respectivo conteúdo dentro de "~/.ssh/known_hosts", mesmo que eles especifiquem a mesma máquina. A opção "HashKnownHosts" não influencia no aparecimento da mensagem abaixo. Sendo que nesse arquivo se tem três informações relacionadas IP, HostName e RSA Key fingerPrint)
Quando o cliente ssh detecta uma possibilidade de DNS Spoofing ou quando o endereço IP e o RSA key fingerprint da máq. remota mudar ao mesmo tempo, o cliente não consiguirá se conectar e a mensagem da figura abaixo aparecerá. Para resolver isso, basta apagar o conteúdo do arquivo "~/.ssh/known_hosts" na máquina cliente. A opção "HashKnownHosts" não influencia na mensagem abaixo.
Obs1: na verdade o ssh sempre irá fazer o hash. A diferença de habilitar ou não a opção "HashKnownHosts" é que ao habilitá-lo, o conteúdo do "~/.ssh/known_hosts" relacionado ao HostName e IP ficará criptografado por hash. Já ao desabilitá-lo todas essas informações estarão visíveis.
Obs2: o conteúdo de "~/.ssh/known_hosts" no cliente é o mesmo do "/etc/ssh/ssh_host_rsa_key.pub" e "/etc/ssh/ssh_host_dsa_key.pub" da máq. remota adicionado do IP e HostaName. Em outras palavras, o "~/.ssh/known_host" armazena as chaves públicas do servidores que ficam em "/etc/ssh/ssh_host_rsa_key.pub" e em "/etc/ssh/ssh_host_dsa_key.pub". Só para conhecimento, as chaves privadas do servidor ficam em "/etc/ssh/ssh_host_rsa_key" e "/etc/ssh/ssh_host_dsa_key".
Obs3: só para conhecimento também, o "RSA key fingerprint", "RSA public Key" e "/etc/ssh/ssh_host_rsa_key.pub" são a mesma coisa. Além disso, "RSA host key" e "/etc/ssh/ssh_host_rsa_key" são a mesma coisa também.
GSSAPIAuthentication yes (especifica se a autênticação do usuário baseada em GSSAPI é permitida)
GSSAPIDelegateCredentials no (delega credênciais para o servidor)
Esse recurso do "SSH" que será mostrado é muito interessante e que poucos sabem. Imaginem trazer programas do ambiente gráfico de um computador remoto para o seu computador usando o comando "ssh". Será que é possível? Sim, totalmente possível e fácil. Por exemplo, se meu equipamente não tivesse o OpenOffice instalado, eu poderia conectar via "ssh" numa máquina que tivesse e trazer tal programa para a minha tela. Que bom, não? O único pré-requisito para isso é que as duas pontas (maquina remota e local) tenha o ambiente gráfico (mais especificamente o servidor gráfico - X11). Para o MS-Windos também é possível, basta usar o XMing (X11 do Windows). Então, vamos ver como fazer isso entre dois Linux:
# vi /etc/ssh/ssh_config (arquivo de configuração global do cliente ssh)#ForwardX11 no (não é necessário mudar essa opção, pois através do opção "-X" do comando "ssh" poderemos fazer isso em tempo de execução. Essa opção faz com que as conexões X11 sejam aceitas. O padrão é "no")
#ForwardX11Trusted yes (para uma maior compatibilidade com programas X11, essa opção deve ser "yes", fazendo com que o cliente "ssh" seja considerado confiável não previnindo roubo de dados/conexão X11. O padrão no Debian é "yes")
Agora que já vimos algumas opções X11 do arquivo de configuração do cliente "ssh", mostrarei, logo abaixo, como é fácil trazer programas que estão num computador remoto para a nossa tela. Só para constar, a máquina que será acessada remotamente (servidor "ssh"), por padrão, já está configurada para aceitar um tunnel X11 "ssh", contudo caso queira saber mais detalhes sobre, acesse SSH Server e procure pelas opções "X11Forwarding" e "X11DisplayOffset")
# ssh -X remote_address (remote_address deve ser substituído pelo endereço IP ou Hostname da máquina remota)
# openoffice (caso a máquina remota tenha o "OpenOffice instalado, ele será trazido para sua tela. Tente outros programas. Também vale ressaltar que ao tentar procurar por algum documento/arquivo com o OpenOffice, ele procurará dentro dos diretórios do computador remoto)
Referências Bibliográgicas
http://www.juniper.net/techpubs/software/erx/junose61/swconfig-system-basics/html/passwords-security-config7.html