Original em formato texto com marcações para conversão em HTML, processo automatizado com scripts e txt2tags.
Dicas, instalar e configuar, exemplos de linha de comando e indicações de tutoriais.
Os comandos e dicas podem não atender as suas necessidades, não ser compatível com sua instalação, tente adaptar ao seu ambiente. SSH é muito útil para adminstrar maquinas remotamente, transferir arquivos e outros serviços, modo de operação semelhante ao Telnet mas de forma segura, os dados e senhas trafegam pela rede em modo criptografados.
Também funciona com servidor para estações windows em conexões como putty, winscp, FreeNX e outros...
Considere que os pacotes do protocolo ssh são os mesmos na maioria das distribuições, as diferenças entre as distros estão nos comandos para instalar e iniciar o servidor sshd, também algumas diferenças entre as próprias versões do SSH.
SSH tem pacotes para clientes e servidor, os pacotes cliente servem para fazer conexões com outras maquinas, iniciar a conexão a partir da maquina local, os pacotes servidor servem para atender as requisições, receber e atender os pedidos de conexões de outras maquinas, na maquina local precisa dos pacotes cliente e na maquina remota precisa dos pacotes servidor para completar a conexão, a parte cliente basta instalar e executar os comandos, a parte servidor requer o daemon rodando (sshd), portanto, além da instalação precisa iniciar o serviço e refinar o ajuste a seu modo.
Dependendo do perfil de instalação já inclue todos os pacotes ou nem instala, como exemplo, CL10 com perfil "servidor Samba", em tempo de instalação não inclue os pacotes do ssh, mas podem ser instalaos a qualquer momento, a seguir alguns exemlos de comandos para verificar e instalar, exemplos para linha de comando, pode fazer o mesmo serviço em ambiente gráfico via synaptic e outras ferramentas.
Lembre que somente o root tem poderes para instalar programas, torne root com su -, também requer o CD 1 e CD2 ou a maquina configurada para buscar os pacotes na internet.
Ver quais pacotes estão instalados; rpm -qa | grep ssh
Ver quais os pacotes disponiveis para instalar: apt-cache search ssh
Instalar somente o cliente ssh
apt-get install openssh openssh-clients
Instalar somente o servidor ssh
apt-get install openssh openssh-server
Instalar todos os pacotes do ssh, cliente + server
apt-get install openssh openssh-clients openssh-server
Iniciar (levantar) o servidor sshd execute: service sshd start
Iniciar o servidor ssh no boot (automatizar para iniciar o serviço junto com o boot da maquina tanto em modo 3 texto ou 5 gráfico).
chkconfig --level 35 sshd on
Ou simplesmente: chkconfig sshd on
Após alguma alteração na configuração precisa reiniciar o serviço, execute: service sshd restart
Parar o servidor ssh, execute: service sshd stop
Resultado de alguns comandos.
resultado do comando: rpm -qa | grep ssh
[root@faqcl10 tmp]# rpm -qa | grep ssh openssh-clients-3.8.1p1-60281cl openssh-server-3.8.1p1-60281cl openssh-3.8.1p1-60281cl
Ambiente, FC5 x86_64 instalado com perfil default Gonome, sem seleção de pacotes manual.
Neste perfil de instalação, já instala o cliente e server do SSH, vem configurado para exportar o X "X11Forwarding yes" e comentada a linha que permite login remoto como root "#PermitRootLogin yes", para liberar, retire o comentário desta diretiva em /etc/ssh/sshd_config, evite esta alteração em micros de cara para internet.
Já vem instalado mas não vem configurado para iniciar o servidor sshd automaticamente.
Iniciar o servidor sshd manualmente service sshd start
Parar o servidor sshd manualmente service sshd stop
Reiniciar o servidor sshd manualmente service sshd restart
Conferir se está rodando; status service sshd status
configurações permanente no boot, use chkconfig, para iniciar o servidor sshd no boot;
chkconfig sshd on
Use o gerenciador de pacotes preferido para instalar, veja o pacotes instalados no FC5 test3
[root@localhost ssh]# rpm -qa | grep ssh openssh-askpass-4.3p2-1 openssh-4.3p2-1 openssh-server-4.3p2-1 openssh-clients-4.3p2-1
Executar programas da interface gráfica na maquina remota, na mquina local, abra um konsole e digite a linha de comando para fazer a conexão com a opção -X, no console remoto execute os programas, para executar gerereciador nautilus ou konqueror, depois de completar a conexão, digite na linha de comando o nome do aplicativo e enter, exemplo de formato da linha de comando;
ssh -X user-remoto@ip-remoto
ssh -X zago@192.168.1.64
konqueror
nautilus
Continue consultando este documento, tem mais exemplos e dicas...
Ambiente, CentOS 4.3 - x86_64 instalado com perfil default Gnome, sem seleção de pacotes manual.
Neste perfil de instalação, já instala o cliente e server do SSH, vem configurado para exportar o X "X11Forwarding yes" e comentada a linha que permite login remoto como root "#PermitRootLogin yes", para liberar, retire o comentário desta diretiva em /etc/ssh/sshd_config, evite esta alteração em micros de cara para internet.
Resumo de alguns comandos;
Iniciar o servidor sshd manualmente service sshd start
Parar o servidor sshd manualmente service sshd stop
Reiniciar o servidor sshd manualmente service sshd restart
Conferir se está rodando; status service sshd status
configurações permanente no boot, use chkconfig, para iniciar o servidor sshd no boot;
chkconfig sshd on
Use o gerenciador de pacotes preferido para instalar, veja o pacotes instalados no CentOS 4.3 - x86_64
[root@localhost ~]# rpm -qa | grep ssh openssh-clients-3.9p1-8.RHEL4.12 openssh-3.9p1-8.RHEL4.12 openssh-askpass-gnome-3.9p1-8.RHEL4.12 openssh-server-3.9p1-8.RHEL4.12 openssh-askpass-3.9p1-8.RHEL4.12
Por default já vem configurado para exportar o X com esta linha no /etc/ssh/sshd_config
`` ForwardX11Trusted yes``
Faça a conexão ssh com a diretiva -X para executar programas da interface gráfica na maquina remota, segue alguns exemplos para uso em linha de comando no konsole.
ssh -X user-remoto@ip-remoto
ssh -X zago@192.168.1.64
Depois de completada a conexão, digite o nome do pacote da interface gráfica e enter
konqueror
nautilus
Ou tudo na mesma linha de comando
ssh -X -C zago@192.168.1.64 /usr/bin/nautilus
Esta linha de comando abre o nautilus na interface gráfica local.
Continue consultando este documento, tem mais exemplos e dicas sobre X remoto via ssh...
Ambiente; estação de trabalho com instalação do KDE, sem seleção de pacotes adicionais.
Neste perfil de instalação já inclue o cliente e server SSH, também inclue o firewall negando acesso remoto via ssh, desativar ou configurar firewall, execute yast2 -> Segurança e usuários -> Firewall
Conforme o perfil de instalação pode não incluir o ssh, caso falhe ou não foi selecionado no perfil de instalação, procure e instale o pacote openssh, procure no yast ou no seu gerenciador de pacotes, lembre de iniciar o serviço após a instalação, veja exemplos abaixo.
Por default já vem configurado para exportar o X "X11Forwarding yes" e comentada a linha que permite login remoto como root "#PermitRootLogin yes", para liberar, retire o comentário desta diretiva em /etc/ssh/sshd_config.
Se preferir permitir conexão direta como root, em um konsole como root, copie e cole as duas linhas abaixo, altera a configuração e reinicia o serviço sshd;
sed -i "s/#PermitRootLogin yes/PermitRootLogin yes/g" /etc/ssh/sshd_config
rcsshd restart
Quando tiver problemas com acesso remoto, verifique se o firewall está habilitado, faça teste com firewall desabilitado e depois que funcionar implemente suas regras, dependendo da instalação o firewall vem habilitado e negando acesso remoto via ssh, permite conexão no konsole da própria maquina mas não responde a conexões de outras maquinas da rede, em algumas instalações volta ao prompt sem mensagem alguma, isto é caracterisco do firewall ativado.
Por default o firewall nega conexão remota, sem firewall o ssh vem configurado para aceitar conexão remota de qualquer usuário do sistema, a segurança pode ser combinada com regras de firewall e configurações do ssh para limitar quem pode ou não fazer login, configure em /etc/ssh/sshd_config e implemente outras regras de segurança, tem varias dicas em outros tópicos deste documento e nas mensagens do FAQ.
Configurar para iniciar o servidor sshd junto com o boot chkconfig sshd on
SUSE usa formato diferente, "rc" mais o daemon do serviço, formando uma palavra mais a opção desejada, exemplos;
Iniciar o servidor sshd manualmente rcsshd start
Parar o servidor sshd manualmente rcsshd stop
Reiniciar o servidor sshd manualmente rcsshd restart
Conferir se está rodando; status rcsshd status
Inciar automaticamente junto com o boot
chkconfig, marcar para iniciar serviço junto com o boot; chkconfig daemon on/off, exemplo para iniciar ssh
chkconfig sshd on
Listar todos os serviços disponíveis para seleção com chkconfig, marcados ou não.
chkconfig --list
suse10:~ # chkconfig --list | grep ssh sshd 0:off 1:off 2:off 3:on 4:off 5:on 6:off
Perfil KDE para estação de trabalho não inclue instalação automatica dos pacotes para servidor do ssh.
Instalar via interface gráfica, execute mcc e procure pelo pacote openssh-server
Instalar via linha de comando, execute:
urpmi install openssh-server service sshd status
Rodando Kurumin a partir do CD ou instalado em HD.
ssh - instalar e configurar
Na instalação default inclue o cliente ssh (openssh-client)
Para permitir conexões remotas, login remoto a partir de outras maquinas, instale o pacote openssh-server, procure por ele no gerenciador de pacotes, instalando pelo "aptitude, adept, smart ", exemplo via smart na linha de comando
smart install openssh-server
Via aptitude
aptitude install openssh-server
Prontinho, durante a instalação já inicia o daemon sshd para aceitar conexões remotas.
Configuração default permite login de root e exportando o X.
PermitRootLogin yes
X11Forwarding yes
Demais comandos e uso são os mesmos de qualquer distro.
Neste tópico, comandos e dicas exclusivo sobre a distro, demais comandos, consulte a documentação geral, comum a todas as distros.
Instalar via linha de comando, como root, execute;
apt-get install ssh
Esta linha de comando inicia um dialogo com instruções e avisos, faça as opções e prossiga com a instalação, no final da instalação o cliente e server são instalados, conforme as opções já inicia o servidor ssh (sshd) automaticamente, permitindo conexões remotas e uso do cliente ssh.
Por default já vem liberado login de root "PermitRootLogin yes", para impedir login como root, altere esta diretiva para "no".
Exportar o X, altere a diretiva "X11Forwarding no" para "X11Forwarding yes", ou simplesmente copie e cole;
sed -i "s/X11Forwarding no/X11Forwarding yes/g" /etc/ssh/sshd_config
Não consegui executar aplicativos do X remotamente, abre o aplicativo na própria maquina e não na maquina remota de onde dispara o comando, algo muito estranho que não acontece em outras distros, qualquer dia procuro entender isto e postar a solução aqui.
Usuário; na maquina que roda o servidor sshd, precisa criar o usuário e definir senha como sendo um usuário local, na conexão remota tem que indicar o usuário e senha do sistema remoto, tanto na linha de comando ou outro cliente ssh, usuário cliente ssh são os mesmos do sistema remoto e não precisa existir no cliente, veja na documetação de sua distro sobre criar usuários e senhas, no FAQ ssh.txt neste diretório tem mensagens com algumas dicas de firewall e como melhorar o controle desta conexão.
Saber quais clientes estão conectados, use a variavel de ambiente $SSH_CLIENT.
[zago@speedy zago]$ echo $SSH_CLIENT 192.168.1.53 33033 22
Veja também os resultados de;
netstat -na
w
DEBUG - LOG - faça a conexão com -vv para exibir as mensagens, ajuda na localização de problemas, tente também iniciar o iniciar o servidor em modo debug (ssh -d) e conectar com o cliente, provavelmente o servidor vai exibir as mensagens de erros, tais como permissões e etc..., exemplos
ssh -v zago@localhost ssh -vv zago@192.168.1.3 /usr/sbin/sshd -d service sshd status
Copia preservando data e permissões de arquivos,(ownership e timestamp) use -p minusculo, cuidado que -P maiusculo indica a porta, direto do man scp.
-p Preserves modification times, access times, and modes from the original file.
Exemplo de copia do dirlocal mantendo as permissões no destino em dirremoto.
scp -rp dirlocal user@IP:/dirremoto
Testar a conexão, faça a conexão na propria maquina, no console use um dos exemplos;
ssh login_usuário_válido@localhost ssh login_usuário_válido@ip_da-propria-maquina ssh zago@192.168.1.53 ssh zago@localhost
Concluindo a conexão indica que a configuração local está OK, falhando conexão externa indica problemas externos como firewall, rede, rotas e etc..
[zago@zago zago]$ ssh zago@localhost The authenticity of host 'localhost (127.0.0.1)' can't be established. RSA key fingerprint is 6c:d1:55:25:11:1e:3a:7e:71:59:33:4c:cb:9e:79:ef. Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added 'localhost' (RSA) to the list of known hosts. zago@localhost's password: Last login: Tue Oct 11 11:24:33 2005 [zago@zago zago]$ netstat -na Conexões Internet Ativas (servidores e estabelecidas) Proto Recv-Q Send-Q Endereço Local Endereço Remoto Estado tcp 0 0 0.0.0.0:111 0.0.0.0:* OUÇA tcp 0 0 0.0.0.0:22 0.0.0.0:* OUÇA tcp 0 0 0.0.0.0:631 0.0.0.0:* OUÇA tcp 0 0 127.0.0.1:33057 127.0.0.1:22 ESTABELECIDA
DEBUG - LOG - faça a conexão com -vv para exibir as mensagens, ajuda na localização de problemas, tente também iniciar o iniciar o servidor em modo debug (ssh -d) e conectar com o cliente, provavelmente o servidor vai exibir as mensagens de erros, tais como permissões e etc..., exemplos
ssh -v zago@localhost ssh -vv zago@192.168.1.3
Falha na conexão, na reinstalação, troca de IP e outras alterações, pode falhar a conexão e retornar um aviso que existe alguém interceptando a conexão, que é um ataque ou violação, esta mensagem também ocorre em caso de ataque real, portanto tem duas possibilidades, um real ataque ou a maquina destino não é mais a mesma utilizada em conexão anterior com este IP, isto ocorre porque mudou a chave, como não é possivel saber a causa, por segurança recusa a conexão.
Tendo certeza que não se trata de sniffer na rede ou ataque e que é provavel a troca de IP ou instalação então edite o arquivo, .ssh/known_hosts que fica no home do usuário e remova a entrada deste IP (chave velha), neste arquivo procure pela linha com o IP remoto que causou o problema e apague-o, ou remova o diretorio todo (todas as chaves), depois faça a conexão que vai recriar as chaves, vai recriar como sendo a primeira conexão com esta maquina, veja o exemplo, primeiro remove o .ssh e depois conecta por ssh:
[zago@zago zago]$ rm -rf ~/.ssh [zago@zago zago]$ ssh zago@192.168.1.1 The authenticity of host '192.168.1.1 (192.168.1.1)' can't be established. DSA key fingerprint is 32:57:2a:2b:e6:1b:da:b2:33:fe:88:2f:33:cd:b1:91. Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added '192.168.1.1' (DSA) to the list of known hosts. zago@192.168.1.1's password: Last login: Thu Jul 18 13:22:19 2002 from 192.168.1.53
Removenda a linha com sed.
Remover linha que inicia com IP 192.168.1.205, utilizo para remover chave de IP que foi moficado no arquivo ~/.ssh/known_hosts
sed -i '/^192.168.1.205/d' ~/.ssh/known_hosts
Em minhas instalações de testes isto é repetitivo, para não ficar repetindo a digitação, coloquei no inicio do .bash_history, outra opção que utilizo, criar script e passar o IP na linha de comando, script que utilizo em minhas instalações.
cat /usr/bin/zzsedip
#!/bin/bash sed -i "/^$1/d" ~/.ssh/known_hosts
Com este script basta passar o IP na linha de comando, digitar zzse e tecla tab para completar, depois tecle um espaço e IP que deseja remover
zzsedip 192.168.1.205
Agora é só voltar com as setas até a linha que deu erro e dar enter para criar nova chave e completar a conexão...
Mais uma medida de segurança, restringir o acesso somente aos usuários listados na configuração do ssh, no CL10 o final do /etc/ssh/sshd_conf vem assim;
#Banner /some/path #VerifyReverseMapping no Subsystem sftp /usr/libexec/sftp-server
Para incluir os usuários que poderão se conectar via ssh, acrescente no final de /etc/ssh/sshd_conf, AllowUsers mais o nome de login dos usuários separados por espaços, exemplo;
Subsystem sftp /usr/libexec/sftp-server AllowUsers anderson zago erika carol
Enquanto não utilizada a diretiva "AllowUsers" qualquer usuário da maquina pode conectar via ssh. Quando acrescenta-la, passa a permitir apenas os usuários listados e válidos na maquina, esta diretiva prevalece sobre a regra "default" que permite login de todos.
A porta padrão do ssh é 22, por isto tem muitos scripts que ficam tentando conexão nesta porta, por este e outros motivos, pode se alterar a porta do ssh, por exemplo, alterar de 22 para porta 2222, use seu editor preferido para editar o arquivo /etc/ssh/sshd_config e procure pela linha; #Port 22 altere para Port 2222, observe que além de alterar a porta, também precisa remover o comentário da linha, caso não encontre esta linha, pode adicionar no inicio do arquivo, depois de efetuar a alteração, precisa reiniciar o serviço, veja no tópico sobre instalação, para testar na própria maquina, em um konsole execute a linha de comando neste formato;
ssh -p 2222 IP-ou-dominio -l usuario ssh -p 2222 192.168.1.2 -l zago ssh -p 222 zago@192.168.1.2
Ocorrendo erros, procure interpretar a mensagem de erro, verifique a configuração, entre as principais causas, verifique se o serviço ssdh (servidor ssh) está rodando, regras de firewall bloqueando acesso, se está tentando com usuário permitido na configuração do ssh.....
Existem diversas opções e regras para redirecionar um pedido que chega da internet para uma estação ou servidor que estão atrás do firewall, pode ser por porta, IP ou protocolo.
Segue alguns exemplos;
Redirecionar ssh, independe do cliente, na origem pode ser utilizado linha de comando do ssh, fish no konqueror, putty em cliente windows, o que importa é a porta, os demais requisitos ficam por conta da configuração do cliente e servidor, exemplo para redirecionar tudo que chega na porta 22 (usada pelo ssh), redirecionar para a estação com IP 192.168.1.53, todos os pedidos que chegam no firewall e porta 22 serão redirecionados.
$iptables -t nat -A PREROUTING -p tcp -s 0/0 --dport 22 -i eth0 -j DNAT --to 192.168.1.53:22
ssh user@IP, ou ssh zago@200.200.200.200, quando este pedido chega no Firewall com IP 200.200.200.200 é automaticamente redirecionado para a estação com IP 192.168.1.53 que atenderá o pedido e completará a conexão.
Outra opção, usar porta diferente, assim pode redirecionar cada porta para estações especificas, também pode redirecionar com troca de porta, neste exemplo a 2222 será redirecionada para 22, nesta regra vai redirecionar para a estação, somente os pedidos que chegam na porta 2222, os demais pedidos na porta 22 ou outra qualquer serão tratados por outras regras.
$iptables -t nat -A PREROUTING -p tcp -s 0/0 --dport 2222 -i eth0 -j DNAT --to 192.168.1.53:22
ssh -p 2222 zago@200.200.200.200
o (-p 2222) serve para indicar a porta, os pedidos que chegarem na porta 22 seguem outras regras, pode ser redirecionada para outra maquina ou atendida pela própria maquina do firewall.
$iptables -t nat -A PREROUTING -p tcp -s 200.204.198.164 --dport 2222 -i eth0 -j DNAT --to 192.168.1.53:22
Liberando somente conexões para a rede interna, regra aplicável em micros que compartilha a internet, com duas placas de rede, uma para a rede interna e outra de cara para internet, conectada ao modem, considerando que a placa que está de cara para internet seja a eth0, inclua esta regra no firewall.
iptables -A INPUT -p tcp -i eth0 --syn --dport 22 -j DROP
ajuste o device de rede (eth0) conforme sua instalação, em conexões via pppoe o device deve ser (ppp0), observe que esta regra fecha qualquer tentativa de conexão via ssh chegando pela eth0 mas continua aceitando todas que chegam pela eth1
Caso queira liberar somente alguns IP da rede interna, use regras neste formato.
iptables -A INPUT -p tcp -s $IP_PERMITIDO1 --dport 22 -j ACCEPT iptables -A INPUT -p tcp -s $IP_PERMITIDO2 --dport 22 -j ACCEPT iptables -A INPUT -p tcp -s $IP_PERMITIDO3 --dport 22 -j ACCEPT iptables -A INPUT -p tcp -s $IP_PERMITIDO4 --dport 22 -j ACCEPT iptables -A INPUT -p tcp --dport 22 -j DROP
As variaveis de $IP_PERMITIDO1 a $IP_PERMITIDO4 devem ser definidas no inicio do script de firewall ou substituidas pelo IP, a ultima linha fecha para os demais IP tanto da rede interna como da internet.
Liberar acesso remoto somente para um IP conhecido, para manutenção, no inicio do firewall defina a variável $IP_PERMITIDO ou substitua no exemplo abaixo;
iptables -A INPUT -p tcp -s $IP_PERMITIDO --dport 22 -j ACCEPT iptables -A INPUT -p tcp --dport 22 -j DROP
Liberar mais de um IP, repita a primeira linha alterando a variável ou inserindo o IP diretamente.
Liberar acesso somente a um IP e negar para os demais.
iptables -I INPUT -p tcp -s $IP_PERMITIDO --dport 22 -j ACCEPT iptables -I INPUT -p tcp -s 0.0.0.0/0 --dport 22 -j DROP
Knocking on servers doors
Para facilitar a separação das linhas, todas iniciam com $iptables, também estão separadas por uma linha em branco
Tópico em elaboração no SUSE 10.1. Falhou e qualquer dia continuo com os testes...
rpm -ivh DenyHosts-2.4b-python2.4.noarch.rpm
error: Failed dependencies:
/bin/env is needed by DenyHosts-2.4b-python2.4.noarch
python(abi) = 2.4 is needed by DenyHosts-2.4b-python2.4.noarch
versão do python instalado
smart install python warning: python-2.4.2-18@i586 is already installed
SSH permite conexão segura e criptografada, ideal para conexão remota para configuração ou administração, completada a conexão tem um console (shell) da maquina remota, quando iniciar a conexão a partir de um konsole do ambiente gráfico, pode copiar e colar linhas de comandos ou textos entre o konsole e navegador ou editor de textos, muito útil e pratico, pode abrir diversas conexões com a mesma maquina ou maquinas diferentes.
Exemplos de linha de comando pra conexão com a maquina remota, formato (ssh user@IP), as linhas abaixo tem o mesmo resultado:
ssh zago@192.168.1.53
ssh -l zago 192.168.1.53
ssh -p 22 192.168.1.2 -l zago
Quando se usa porta diferente, exemplo para quem usa na porta 2222
ssh -p 2222 192.168.1.2 -l zago
Algumas instalações vem configurada para não aceitar conexão do root, tem duas soluções, conectar com user comum e tornar root com (su -), ou alterar a confgiruação para permitir liberar login do root.
Algumas distros na configuração default permite login de root, como exemplo o Debian (Sarge), outras vem com este recurso bloqueado, como exemplo o CL10.
Na instalação padrão do CL10 não é permitido login do root diretamente, mas quando precisar fazer algo como root, efetue login como usuario comum e depois digite "su -" e a senha do root para se tornar root, quando aos poderes e recursos não faz diferença, caso prefira, pode liberar login de root diretamente, altere para "yes" a diretiva (PermitRootLogin no) em:
/etc/ssh/sshd_config
altere a linha PermitRootLogin no
para PermitRootLogin yes
Reinicie o sshd service sshd restart
Prontinho, já pode fazer a conexão como root.
Ou simplificando em uma tacada só, comando pra copiar e colar:
sed -i "s/PermitRootLogin no/PermitRootLogin yes/g" /etc/ssh/sshd_config
service sshd restart
Prontinho, na linha de comando pode executar todos os comandos disponíveis no console, quando configurado para exportar o X, faça a conexão com a diretiva -X para executar aplicativos do ambiente gráfico, veja também outros tópicos neste documento, como executar aplicativos do ambiente gráfico, exportar o X.
Executar comando remoto e encerrar conexão, comandos que não requer interação, como iniciar, parar e ver status de serviços, quando precisa somente executar o comando e encerrar a conexão, pode fazer tudo em uma única linha de comando, exemplo para ver status do servidor samba, desligar o micro, iniciar serviço, ver o resultado do comando free;
ssh -C zago@192.168.1.120 /usr/bin/smbstatus \; free
Desligar maquina remota;
ssh -C root@192.168.1.70 poweroff
Em manutenção de arquivos de configuração é comum fazer a conexão via ssh para depois executar o comando, seja comandos simples como ver espaço em disco, arquivos ou editar algum .conf, para estes casos pode passar o comando junto com a linha de comando da conexão, no final do comando já cai no console da maquina local e evita o trabalho de fazer e encerrar a conexão, no caso de executar somente um comando, como ls, du ou até mesmo editar um .conf, no final do comando, tem o resultado remoto mas cai no console local.
Alguns exemplos, após a linha de comando quando solicitado, informe a senha do usuário remoto , entre maquinas configuradas para conexão sem senha executa o comando direto.
Formato da linha de comando;
ssh userremoto@ipremoto 'comando' ssh zago@192.168.1.2 '(comando)' ssh zago@192.168.1.2 '(rm ~/teste.txt)'
Alguns exemplos; executar "ls -la" no diretório "/etc/rc.d" da maquina remota;
ssh zago@192.168.1.193 'ls -la /etc/rc.d'
Conferir o ultimo acesso do usuário no console, pode verificar o ultimo acesso no .bash_history, .bashrc ou outro arquivo de controle, exibe no console local os dados do arquivo na maquina remota.
ssh zago@192.168.1.2 'stat -c %x .bash_history'
Com ssh configurado para aceitar conexão remota do root, pode usar root em lugar de zago no exemplo acima.
Editar arquivo na maquina remota, lembre que vale as permissões na maquina remota para o usuário da conexão, também pode configurar a maquina remota para aceitar conexão do root, mas isto depende da sua segurança, exemplo de uso do editor "vi" para editar/alterar o arquivo remoto /etc/squid/negapalavra.txt, exemplo de linha de comando;
ssh zago@192.168.1.193 'vi /etc/squid/negapalavra.tx'
Exemplo para ver status do servidor samba, ver o resultado do comando free;
ssh -C zago@192.168.1.120 /usr/bin/smbstatus \; free
Desligar maquina remota;
ssh -C root@192.168.1.70 poweroff
Iniciar webmin e ver espaço livre em disco
ssh -C root@192.168.1.120 /etc/rc.d/init.d/webmin start\; df
Quando não for possível passar todos os parametros na linha de comando, crie script e salve na maquina remota, depois é só executar o script, exemplo para backup.
ssh -C root@192.168.1.70 meuscript.sh
Executar aplicativo do ambiente gráfico remoto passando parametros na linha de comando.
Nesta opção fecha a conexão ao fechar o aplicativo, serve somente para executar comandos ou programas remotos, exemplo de pesquisa no Google via Konqueror na maquina remota, passando como parametro o nome do aplicativo (konqueror) mais a string de pesquisa (howto freenx).
ssh -X -C zago@192.168.1.64 konqueror gg:howto+freenx
Neste formato de linha de comando acima, basta executar no konsole da maquina local para fazer a conexão e abrir o konqueror com o resultado da pesquisa no Google, recebe a tela na maquina local mas executa o konqueror e navega pela maquina remota.
Quando o termo da pesquisa tem mais de uma palavra, use o sinal "+" em lugar de espaço para não abrir abas para cada palavra.
Sincronizar a hora via ssh, mais uma "gambi".
Em maquinas sem acesso a internet, pode usar ssh para pegar a data de outra maquina da rede, tudo em uma linha de comando, fazendos alguns testes com ssh para executar comando remoto, resolvi testar esta opção e funcionou, achei interessante acrescentar aqui, pode até ser útil como exercicio sobre ssh.
Linha de comando para testar, mostrar hora da maquina remota no console local. horacerta=`ssh zago@192.168.1.2 'date |tr -s " " |cut -d" " -f4'` && echo -s $horacerta Password: 22:23:29 Linha de comando para alterar a hora local horacerta=`ssh zago@192.168.1.2 'date |tr -s " " |cut -d" " -f4'` && date -s $horacerta
Enviar arquivos para outra maquina da rede local ou internet, use no formato;
scp arquivo-a-copiar userdestino@ipdestino:~/
Após o IP acrescente dois pontos barra normal e caminho completo, para copiar para o home do usuário destino, pode substituir o caminho do home do usuário por "til", segue alguns exemplos de linha de comando.
Copiar arqteste.txt para o home do usuário destino:
scp arqtest.txt zago@192.168.1.53:~/
Copiar arqteste.txt para o sub-diretório do home do usuário, /home/zago/copias/faq
scp arqtest.txt zago@192.168.1.53:~/copias/faq
Observe que foi substituido o /home/zago por "til", o comando acima pode ser substituido por este sem o til;
scp arqtest.txt zago@192.168.1.53:/home/zago/copias/faq
Copiar todos os arquivos e sub-diretórios a partir do prompt de comando local para o home do usuário zago no destino.
scp -r * zago@192.168.1.53:~/
Copiar para um sub-diretorio especifico no micro de destino, não use (~) e informe o caminho:
scp -r * zago@192.168.1.53:/home/copias/copiadoserv
Salvar no destino com outro nome, também acrescentar a data e hora de criação:
scp -r /home/samba zago@192.168.1.53:/home/zago/servsamba-`date +%d.%b.%Y-%H-%M`
Resultado; caminho e nome do arquivo no destino tem este formato: /home/zago/servsamba-08.Ago.2004-17-14
Atualizar paginas do Apache, requer alteração de permissão para usuário gravar.
scp -r * zago@192.168.1.2:/srv/www/default/html/zago
Download, buscar arquivos e diretórios em outra maquina, copiar da maquina remota para maquina local, pode fazer a conexão e a partir da linha de comando remota executar outra linha de comando para enviar arquivos para sua maquina, isto implica em fazer a conexão para depois enviar os arquivos, caso queira somente transferir os arquivos para sua maquina, então não precisa fazer a conexão, em uma tacada só, a solução mais simples é esta;
scp -r user-remoto@maquina_remota:~/sub-diretório/diretorio-download .
scp user-remoto@maquina_remota:~/sub-diretório/arquivo-download .
O ponto no final da linha indica para salvar no diretório atual.
scp -r zago@192.168.1.120:~/isos .
Onde; zago é usuário da maquina remota, 192.168.1.120 é o IP da maquina remota, isos é o diretório na maquina remota que quero copiar para a maquina local, observe ponto no final, indica para salvar a copia no diretorio local, mesmo diretório que executou a linha de comando, no exemplo acima -r indica para copiar o diretório isos, para copiar arquivos use neste formato para copiar o arquivo teste.txt
scp zago@192.168.1.120:~/teste.txt .
Salvar em outro local, substitua o ponto pelo caminho na maquina local, exemplo para salvar na maquina local em /home/zago/tmp
scp zago@192.168.1.120:~/teste.txt /home/zago/tmp
scp -r zago@192.168.1.120:~/isos /home/zago/tmp
scp -r zago@192.168.1.120:/home/zago/isos /home/zago/tmp
Este recurso é muito prático na copia de configuração de outra maquina da rede ou até mesmo via internet, exemplo de copia do script de firewall de outra maquina.
scp zago@200.200.200.200:/etc/rc.d/firewall.sh /etc/rc.d
Copiar o diretório squid com os arquivos de acl,
scp -r zago@200.200.200.200:/etc/squid /etc/
Dependendo do arquivo ou diretório, como nos exemplos acima, precisa ser root na maquina local para gravar e permissão de leitura na maquina remota.
Tem um espaço separador entre o nome do arquivo ou diretório remoto e o caminho local.
Dois comandos na mesma linha, use ; para indicar o proximo comando, mesmo assim tem que digitar a senha duas vezes.
Exemplo para download e apagar. Prático para transferir arquivos de backup, apagar depois da cópia.
scp zago@192.168.1.2:~/teste.txt . ;ssh zago@192.168.1.2 '(rm ~/teste.txt)' O resultado é mesmo que digitar em duas linhas. scp zago@192.168.1.2:~/teste.txt . ssh zago@192.168.1.2 '(rm ~/teste.txt)' Quando for o mesmo usuário nas duas maquinas, pode omitir o usuário, neste formato. scp 192.168.1.2:~/teste.txt . ;ssh 192.168.1.2 '(rm ~/teste.txt)'
Quando a maquina remota está atrás de firewall, pode fazer conexões de maquina em maquina, copiar de uma para outra até disponibilizar em local com acesso direto ou simplesmente acessar o firewall remoto e incluir uma regra que redirecione para a maquina que deseja alcançar, veja dicas no tópico sobre redirecionamento que permite o acesso direto a maquina atrás de firewall.
Exemplo de comando em uma estação para acessar outra estação atrás de outra rede que tem firewall redirecionando a porta 2222 para a estação remota, baixar para o diretório local o diretório remoto /etc/postfix.
scp -P 2222 -r zago@200.200.200.200:/etc/postfix .
Cópia via scp em scripts executados pelo cron, precisa configurar ssh sem senha.
Segue alguns relatos e problemas.
Monte o script e acrescente no cron com o mesmo usuário configurado para usar ssh sem senha, execute crontab -e no console deste usuário, no script funciona a mesma linha de comando que funciona no console, teste no console ou execute o script manaulmente para testar.
Script dentro do /etc/cron.hourly ou /etc/cron.dayli
Nesta condição o script é executado como root, portanto vai procurar a chave ssh no chaveiro do root /root/.ssh, quando o usuário destino for outro, precisa usar executar com sudo para pegar a chave do usuário (sudo -u usuáriodestino). Veja exemplo em ambiente é CL10 ou SUSE 10.1 com usuário zago configurado para usar ssh sem senha.
Parte do script que está em /etc/cron.hourly, copiar arquivos.
# enviar por scp para outra maquina, requer ssh sem senha configurado cd /backup Copiar todos arquivos do diretório corrente /usr/bin/sudo -u zago /usr/bin/scp * zago@192.168.1.205:/home/copias/samba Copiar diretório e sub-diretório /usr/bin/sudo -u zago scp -r /backup/ter zago@192.168.1.53:/home/copias/teste
O formato acima funciona sem problemas, no manual tem outras opções que falharam, como exemplo dois formatos indicados no manual que não deu certo no CL10 e SUSE 10.1.
su - zago scp -r /backup/ter zago@192.168.1.53:/home/copias/teste scp -i /home/zago/.ssh/authorized_keys -r /backup/ter zago@192.168.1.53:/home/copias/teste
Pode se fazer em duas partes, criar o tar e depois enviar via ssh, com boot pelo Live CD/DVD não é possível criar arquivos grandes, a solução é salvar direto na maquina remota, o uso de Live CD é muito prático, principalmente na copia ou restauração de instalação, também nos casos de copia de arquivos do restou de instalações danificadas que não inciam o sistema local, pelo Live CD pode acessar o disco e salvar a copia em maquina remota via ssh, o uso tar é opcional, diminue o tamanho dos arquivos e consumo de banda.
O tar acessa somente discos montados, portanto precisa montar a partição que deseja fazer a copia, sem montar o tar não tem acesso aos arquivos, mas não deve estar rodando o sistema, diferente do "dd" que não deve montar a partição, o processo mais seguro é fazer boot pela outra instalação que tenha no HD, caso seja partição única ou não tenha como fazer boot por outro HD ou partição, então procure fazer o boot com uma distro que roda direto do CD, por exemplo o Kurumin, os comandos a seguir foram aplicados para copia da instalação do SUSE 10 na partição /dev/hda3 com sistema de arquivos riserfs, feito o boot pelo CD do Kurumin, configurar a rede e executar estes comandos abaixo para salvar a copia em outra maquina da rede, neste exemplo a maquina remota tem ip 192.168.1.120, comandos executados como root no konsole do Kurumin.
mount /dev/hda3 /mnt/hda3 tar zcvf - /mnt/hda3 | ssh zago@192.168.1.120 "cat > suse10-hda3-ecs741.tar.gz" umount /mnt/hda3
Comentando; estas linhas de comando, monta a partição de origem da copia, e salva na maquina remota com ip 192.168.1.120 o arquivo suse10-hda3-ecs741.tar.gz dentro do home do usuário zago, arquivo criado no destino;
-rw-r--r-- 1 zago zago 923955200 2005-12-18 16:21 suse10-hda3-ecs741.tar.gz
Explicando de outra forma, quando está com dois HD na maquina ou tem mais de uma partição, pode executar a tarefa acima por partes, execute os comandos na partição ou ponto de montagem diferente da origem da cópia, os comandos abaixo tem o mesmo resultado das duas linhas acima; cuidado para não salvar no mesmo local de origem.
cd /root mount /dev/hda3 /mnt/hda3 tar zcvf suse10-hda3-ecs741.tar.gz /mnt/hda3 scp suse10-hda3-ecs741.tar.gz zago@192.168.1.120:~/ rm -rf suse10-hda3-ecs741.tar.gz umount /mnt/hda3
Outra opção é montar um compartilhamento (NFS) e executar o comando neste ponto de montagem, considerando que tenha um diretório remoto montado em /mnt/bkremoto, então pode executar estes comandos com resultado similar ao da primeira opção tar+ssh.
cd /mnt/bkremoto mount /dev/hda3 /mnt/hda3 tar zcvf suse10-hda3-ecs741.tar.gz /mnt/hda3 umount /mnt/hda3
Operação inversa, recuperar a instalação, o principio é o mesmo, fazer boot pelo Live CD, montar a partição que deseja recuperar, fazer backup da instalação antiga, apagar todos os arquivos e executar o comando que pega o .tar.gz remoto para descompactar no ponto de montagem; não consegui recuperar direto rodando Kurumin via CD, minha solução é fazer em duas estapas, copiar o backp para a maquina local e depois descompactar no ponto de montagem, segue os comandos executados como root no konsole da maquina local;
mount /dev/hda3 /mnt/hda3 cd /mnt/hda3 # observe o ponto no final da linha abaixo, indica que vai salvar no diretório local ou indique o caminho scp zago@192.168.1.120:~/suse10-hda3-ecs741.tar.gz . tar -zxvf suse10-hda3-ecs741.tar.gz -C / umount /mnt/hda3 # pode apagar a copia local do suse10-hda3-ecs741.tar.gz, caso tenha espaço sobrando, considere manter esta copia.
Onde; zago@192.168.1.120, zago é usuário na maquina remota 192.168.1.120 que guarda o arquivo de backup.
Deve existir alguma forma mais elegante, como falhou a tentativa direta e este procedimento resolve meu problema, copiar o arquivo para a maquina local e despois descompactar no ponto de montagem, então paro por aqui, mas vale tentar outras opções como via NFS para não ocupar espaço local com a copia do arquivo, pode complicar quando não tem espaço sobrando no HD local nem NFS, nestes casos precisa pesquisar por alternativa que faça direto via tar+ssh.
Neste tópico, copia de arquivos ou diretórios da maquina local e salvar em maquina remota, estes comandos podem ser executados no console da própria maquina, pode copiar e colar, usar em script em conexões via ssh sem senha, ou simplesmente digitar na linha de comando, diferente do exemplo anterior (cópia da instalação), o principio é o mesmo, a diferença está na montagem, copia completa do sistema não deve ser feita com sistema montado, enquanto a cópia de arquivos locais não tem este problema e já tem acesso aos mesmo, portanto, pode executar a linha de comando direto, exceto com boot pelo Live CD que requer a montagem da partição para acesso aos arquivos e ou diretórios.
Fique atendo quanto às permissões, o usuário local precisa pelo menos ter acesso de leitura, tenha cuidado com backjup de arquivos em uso, seja banco de dados ou arquivos de usuários.
Exemplo, copiar da maquina local o conteúdo de /home/zago/guiaz/samba, criar e salvar no destino (maquina remota) o arquivo samba.tar.gz dentro do /home/antonio, 192.168.1.164 é o IP da maquina remota e antonio é o usuário remoto, na maquina local é outro usuário com permissão permissão de leitura no diretório local, cuidado com as permissões, tanto de leitura local como de gravação remota.
tar zcvf - /home/zago/guiaz/samba | ssh zago@192.168.1.164 "cat > samba.tar.gz"
Existem muitas maneiras de montar esta linha de comando, segue alguns exemplos;
Usando um nome de arquivo em variável, pode fixar um nome ou pegar dados da maquina local para formar o nome, útil em backup, exemplos; TMPFILE=${HOSTNAME}, TMPFILE=samba, requer mais uma linha para criar a variável, exemplo com nome de arquivo igual ao nome da maquina local.
TMPFILE=${HOSTNAME}
tar cf - /home/zago/guiaz/samba | ssh zago@192.168.1.164 "gzip -c > ${TMPFILE}.tar.gz"
No exemplo acima, o arquivo destino tem o nome igual ao da maquina de origem, exemplo faqcl10.zago.eti.br.tar.gz
O caminho completo não precisa ser informado quando o arquivo ou sub-diretório está dentro do diretório corrente, exemplo do comando executando dentro de /home/zago/guiaz;
tar zcvf - samba | ssh zago@192.168.1.164 "cat > samba.tar.gz"
Também pode copiar varios arquivos, como pode usar dd para salvar no destino, (adaptei este exemplo da Dicas-l, minha colinha para trocar somente nomes de arquivos)
`` tar -czvf - arquivo1 arquivo2 arquivo3 | ssh zago@192.168.1.164 dd of=/home/zago/arquivao.tar.gz ``
Ideal quando não tem espaço suficiente na maquina local para salvar a imagem
dd if=/dev/hda1 | ssh zago@192.168.1.120 dd of=copia-a7n8-xp.img
Forneça a senha do usuário-destino quando solicitada.
Recuperar a instalação (restore) com a imagem em outra maquina da rede, quando acessar a imagem em compartilhamento montado, entre no diretório onde se encontra a imagem e dispare o comando, tem exemplos no tutorial indeicado acima sobre uso em diretório local, ou via ssh (na maquina remota) no mesmo diretório onde está a imagem, use neste formato de linha de comando;
OBS, não é recomendado o uso de root, neste exemplo precisa dos poderes de root para gravar, como user comum vai dar erro de permissão, ajuste a seu modo o acesso ao "dd" para user comum gravar no device, em minhas instalações cofiguro o ssh para aceitar conexão direta de root, observe a utilização do root nos exemplos a seguir;
Recuperar a partir de imagem sem compactação;
cat a7v8x-dd-winXPhda1.img | ssh -l root 192.168.1.192 '(dd of=/dev/hda1)'
Este exemplo e copia e recuperação se aplicam a qualquer tipo de partição, independe do sistema operacional ou sistema de arquivos, os comandos acima fazem a copia e restaura a instalação do Win XP instalado em sistema NTFS, o mesmo formato de comando funciona em partições Linux, tenha o cuidado de copiar todas as partições do sistema e no destino precisa de espaço livre superior ao tamanho das partições que deseja copiar.
Procure por mais exemplos no Google, tem muitas opções e formato de linha de comando, na caixa de pesquisa tente algo como; dd+ssh
Como usar screen;
Muito simples, execute; screen, se falhar, instale o pacote screen.
dentro do prompt dele execute o programa ou script, para sair de deixar o programa rodando, pressione as teclas
CTRL+A e depois d - Ctrl + a + d
isto roda screen em segundo plano e volta ao console normal, para reconectar, execute
screen -R
Exemplo com mais detalhes, no console normal execute; screen, exibe uma mensagem, basta enter para continuar e cair de volta na linha de comando, parece que voltou ao console mas está rodando dentro de uma sessão screen que tem o prompt igual ao console, a execução de programas ou scripts na linha de comando do screen, são executados dentro de uma sessão screen, para executar, seu
programa ou script, basta dar o comando como se faz no console normal, exemplo, usar wget para baixar o ISO do kurumin, ótimo para usar outra maquina, por exemplo o micro do firewall que fica ligado à noite e fins de semana, na saída do expediente, faça uma conexão via ssh, e depois acompanhe remotamante ou no inicio do dia seguinte, recupere a sessão do screen para ver os resultados, aqui usei o exemplo do wget, o mesmo principio se aplica em scripts de backup e outros programas, exemplo de linha de comando para baixar o Kurumin, execute screen e depois;
wget ftp://ftp.las.ic.unicamp.br/pub/kurumin/kurumin-6.0-alpha4.iso
Na tela continua as mensagens do wget, caso queira encerrar a conexão e manter o download, não tem problema, pode sair do screen e depois encerrar a conexão, fazer logoff ou fechar o console.
Sair do screen e manter o programa rodando, pressione as teclas CTRL+A, solte e depois tecle d
Isto volta ao console normal do sistema, e exibe a mensagem [detached], isto inidica que saiu da sessão do screen, mas ele continua rodando, agora pode fechar o terminal (console), fazer logout ou encerrar a conexão remota via ssh que o programa continua rodando até o fim...
Reconectar na sessão existente, a que foi fechada anteriormente, pode voltar na tela e continuar acompanhando as mensagens ou dar comandos, recuperar (voltar na tela do screen), pode ser feita a qualquer momento e de qualquer local, a partir do mesmo console, ou até mesmo de outra conexão remota via ssh, até mesmo de outro computador, faça sempre com o mesmo usuário que disparou o comando inicial, para se conectar, (reconectar) na sessão screen já existente, execute;
screen -R
Prontinho, de volta na tela como se não tivesse saído de lá, com todas as mensagens no console como se tivesse mantido a conexão o tempo todo, serve para conferir mais tarde se terminou normal, ver as mensagens no console, inclusive as mensagens geradas durante o tempo que estava desconectado.
Pode abrir varias sessões, para facilitar procure nomear as sessões com -S nomeprocesso, (-S sessionname) e recuperar com -r nomeprocesso (-r sessionowner/[pid.tty.host])
screen -S sshtal screen -S torrenttal screen -r sshtal screen -r torrenttal
Isto é um resumo muito simples, veja no manual que tem muito mais....
Instalar, procure na sua distro pelo pacote screen, resultados no console do SUSE 10
smart search screen screen - A program to allow multiple screens on a VT100/ANSI Terminal screen-debuginfo - Debug information for package screen
consulte o manual, man screen, tem muitas opções...., veja quantas linhas;
zago@suse64:~> man screen | wc -l 3423
nohup é útil para deixar processo rodando em maquina remota, exemplo de download fora do horário de expediente, seja via wget ou bittorrent, script de backup ou qualquer outra tarefa demorada que não requer interação com o usuário, basta executar a linha de comando e encerrar a conexão que o processo continua atá o fim, tem um log, grava os resultados no arquivo nohup.out para posterior verificação ou acompanhe com "tail -f" enquanto são gravadas no arquivo.
Faça a conexão via ssh, inicie a linha de comando com nohup espaço mais a linha de comando que usaria normalmente no console, depois feche a conexão que o processo continua em execução, exemplo de uso com wget, o principio se aplica a outros programas e scripts, aqui o wget serve somente como exemplo de download da ISO do Kurumin, faça uma conexão via ssh com a maquina remota e no console execute;
nohup wget ftp://ftp.las.ic.unicamp.br/pub/kurumin/kurumin-6.0-alpha4.iso
este comando retorna;
linux:~ # nohup wget ftp://ftp.las.ic.unicamp.br/pub/kurumin/kurumin-6.0-alpha4.iso nohup: appending output to `nohup.out'
Pode encerrar a conexão que o processo continua rodando até concluir a tarefa, neste caso até concluir o download.
Observe que os resultados são desviados para o arquivo nohup.out este arquivo é criado no diretório corrente, no mesmo que disparou o comando, para acompanhar as mensagens, use tail -f nohup.out, pode encerrar e refazer a conexão de outro local ou outro micro qualquer e continuar acompanhando as mensagens, mesmo depois de encerrada a tarefa, os logs continuam em nohup.out, portanto acessíveis a qualquer momento, útil para acompanhar o resultado posteriormente, em script de backup com tar, use o modo verbose -v para gerar as mensagens.
Instalar nohup, procure no pacote coreutils, veja também o manual man nohup e nohup --help, parte do man no CL10
NOME
nohup - executa um comando imune a interrupções de conexão, com a saída
para um dispositivo não tty.
SINOPSE
nohup comando [arg...]
Pode eliminar a digitação de senhas, principalmente em conexões automatizadas com scripts ou conexões repetitivas, precisa criar a chave e copiar para a outra maquina, segue os comandos prontos para copiar e colar, claro que precisa ajustar para seu usuário e IP da maquina remota, basta copiar e colar as linhas abaixo, dar enter duas vezes em resposta à mensagem que pede a frase.
Os comandos são executados na maquina local pelo usuário que vai fazer a conexão, requer o sshd rodando na maquina remota para copia da chave, a primeira linha cria a chave, a segunda exporta e faz a copia para a maquina remota, a terceira faz a copia na maquina e local e prontinho, comandos que utilizo em instalações do CL10 e SUSE 10.1
ssh-keygen -t dsa -f ~/.ssh/id_dsa cat ~/.ssh/id_dsa.pub | ssh zago@192.168.1.120 'cat - >> ~/.ssh/authorized_keys' cat ~/.ssh/id_dsa.pub >> ~/.ssh/authorized_keys
Prontinho para conectar sem digitar a senha, o formato da linha de comando não muda, somente elimina a necessidade de digitar senhas, ideal para uso em scripts e entre maquinas com conexões repetitivas.
Para as demais conexões continua tudo normal, quando tiver problema com alguma chave, não apague o ~/.ssh para não remover esta chave, edite o arquivo ~/.ssh/known_hosts e remova a linha que inicia com o IP problemático.
Sobre segurança e outros cuidados, continue pesquisando, voce sabe o que tem a proteger!.
Tutoriais relacionados a ssh sem senha;
Non-interactive ssh password auth
Passar senha na linha de comando e scripts.
http://sourceforge.net/projects/sshpass/
Ambiente de teste, SUSE 10.1 instalado como estação de trabalho, com perfil KDE.
Não encontrei rpm, a solução foi instalar a partir dos fontes.
Para compilar precisa instalar make e gcc, via smart execute.
smart install make -y smart install gcc -y
download do pacote sshpass-1.00.tar.gz e salvar em /tmp/sshpass.
Para instalar, entre no diretório onde salvou e como root execute estas linhas de comando.
mkdir /tmp/sshpass cp sshpass-1.00.tar.gz /tmp/sshpass cd /tmp/sshpass tar zxvf sshpass-1.00.tar.gz cd sshpass-1.00 ./configure make make install
Depois de instalado consulte o manual man sshpass
-p passar a senha na linha de comando, ideal para usar em scripts.
-f pegar a senha em arquivo, indique o caminho e arquivo com a senha
Detalhe muito importante, só funciona entre maquinas que já tenha feito alguma conexão via ssh, não encontrei uma maneira de responder yes naquela mensagem da primeira conexão. Caso tente a primeira conexão com sshpass, ao dar enter cai para proxima linha e não acontece nada, fica com o cursor travado.
A solução é fazer uma conexão via ssh, depois sair que sshpass funciona nas demais conexões entre as maquinas.
Não funciona no console do root, em minha instalação padrão só funcionou a partir do console de usuário, caso fique com cursor travado no console do root, saia ou abre outro console como user normal, não procurei saber se isto é configurável ou não.
Alguns exemplos de linha de comando
sshpass -p senhadestino ssh usuario@ipdestino
sshpass -p minhasenha ssh zago@192.168.1.120
sshpass -p minhasenha ssh -l zago 192.168.1.120
sshpass -f /home/zago/senhasamba ssh zago@192.168.1.120
SSH em ambiente gráfico via KONQUEROR
Digite na URL do Konqueror: fish://zago:senhadozago@192.168.1.2/home/
ou fish://zago:senhadozago@dominio.com.br/home/
Onde: zago -> é um usuário existente no destino e senhadozago é a senha do usuário 192.168.1.2 -> é o IP da maquina destino, ou use o dominio.
Acessar diretamente um diretório especifico, exemplo, servidor Apache em;
192.168.1.2/srv/www/default/html/zago
Cuidado com as permissões, neste exemplo zago é o owner (dono do diretório) e a senha sehadozago, basta digitar (ou colar) na URL do Konqueror:
fish://zago:senhadozago@192.168.1.2/srv/www/default/html/zago
fish://zago:senhadozago@www.seudominio.com.br/srv/www/default/html/
Ou efetuar login e cair no home do usuário que fez login e navegar entre os diretórios.
fish://zago:senhadozago@192.168.1.2
Requer usuário válido no destino e o servidor sshd rodando, executar o konqueror remotamente mesmo que na maquina destino não tenha o ambiente gráfico rodando, requer no minimo o konqueror instalado na maquina remota, muito prático para navegar pelos diretórios e arquivos via Konqueror para apagar, editar e movimentar arquivos e diretórios, lembre dos direitos que o usuário tenha sobre os arquivos e diretórios na maquina remota.
Completada a conexão, ajuste o Konqueror para ocupar a metade da tela e abra outro Konqueror e ajuste para ocupar a outra metade da tela, assim vai ter dois Konqueror, cada um ocupando a metade da tela, um na maquina remota e o outro na maquina local, conforme as permissões pode editar, apagar, mover ou copiar arquivos entre as janelas, ou melhor entre as maquinas, basta copiar e colar, recortar e copiar ou simplesmente arrastar de uma janela pra outra.
Automatizando a conexão, crie atalho no desktop, pode criar varios atalhos sendo uma pra cada maquina remota, no exemplo abaixo foi utilizada uma maquina da rede interna, funciona também com qualquer maquina na internet que o ssh funcione via terminal, basta ter o servidor ssh rodando, usuário e senha.
No Konqueror - CL9 e CL10 - Criar atalho para conexão via fish.
Clique em qualquer area livre do desktop pra iniciar o prcesso de criar atalho.
clique com botão auxiliar (botão direito) -> Criar Novo -> arquivo -> Link para Aplicativo --> Aba Executar -> Comando :
kfmclient openProfile filemanagement fish://zago:senhadozago@192.168.1.2/home/zago
OBS. Este caminho muda conforme a versão do konqueror, independente da versão, coloque a linha de comando no campo destinado ao nome do aplicativo ou linha de comando.
Onde: zago é um usuário valido na maquina remota, senhadozago é a senha do usuário zago na maquina remota, 192.168.1.2 é o IP da maquina remota, /home/zago é o diretório corrente na maquina remota, exemplo para o diretório remoto (/srv/www/default/html/zago/faq) torna-lo como diretório corrente na conexão use este formato:
kfmclient openProfile filemanagement fish://zago:senhadozago@192.168.1.2/srv/www/default/html/zago/faq
Depois é só dar um clique no ícone do atalho para o konqueror fazer a conexão e abrir como diretório corrente, o diretório da maquina remota informado no comando, neste exemplo o diretório /srv/www/default/html/zago/faq, lembre das permissões e usar login e senha validos como se faz na conexão via ssh em linha de comando.
Caso não queira colocar a senha no atalho, então na caixa comando a linha neste formato:
kfmclient openProfile filemanagement fish://192.168.1.2/home/zago
Neste formato, quando der um clique no atalho, no konqueror vai abrir uma janela para digitar a senha e completar a conexão.
Lembre que todas as maquinas que vão receber a conexão precisa do sshd rodando, veja também as permissões e as regras do firewall tem que permitir a conexão.
Pode copiar o atalho pra outra maquina ou usuário, também pode fazer copia para outro nome e editar (alterar) a linha de comando, procure pelo sub-diretório Desktop dentro do /home/usuario, todos os atalhos do desktop estão neste sub-diretório do usuário.
Executar programas remotamente em ambiente gráfico via conexão ssh.
Executar programas na maquina remota, aplicativos instalados em outra maquina, kmail, evolution, mozilla e etc....
Na maquina local tem que estar em ambiente gráfico, precisa fazer a conexão via terminal do ambiente gráfico, (konsole no KDE ou outro conforme o ambiente gráfico) na maquina local nao precisa do mesmo pacote instalado, na maquina remota não importa se iniciou em modo texto ou gráfico, o que importa é ter instalado o pacote que deseja executar e claro o servidor X(Xfree) ou X(xorg), também o servidor ssh rodando e configurado para exportar o X, com a opção X11Forwarding yes
Algumas distro como no Mandriva 2006 já vem configurado, em outras como no CL10 e Debian precisa ajustar a configuração para exportar o X (ambiente gráfico) via ssh, como fazer no Conectiva 10.
edite e faça esta alteração no arquivo: /etc/ssh/sshd_config
procure pela linha: #X11Forwarding no
altere para: X11Forwarding yes
Após esta alteração precisa reiniciar o servidor ssh. service sshd restart
Na maquina cliente, que vai receber as telas do programa executado remotamente, precisa fazer a conexão com a opção -X, na linha de comando execute neste formato ssh -X user@IP
Exemplo para usuário zago conectar na maquina com IP 192.168.1.86:
ssh -X zago@192.168.1.86
onde zago é usuário valido no servidor com IP 192.168.1.86, após digitar a senha e cair na linha de comando, basta digitar o nome do programa que deseja executar, exemplo executar gerenciador de pacotes em ambiente gráfico na maquina remota para instalar programas:
synaptic
smart --gui
Navegador, cliente de e-mail ou qualquer outro pacote do ambiente gráfico.
mozilla, gnome-terminal, konqueror, evolution, kmail ...
Claro que chamando kmail na maquina remota, vai ter acesso aos e-mail do usuário na maquina remota, pode até fazer isto entre maquinas da rede interna ou via internet para acessar seu cliente de e-mail remotamente.
Passar nome do aplicativo na linha de comando da conexão, em conexões especificas para executar aplicativo, pode passar o caminho e nome do programa junto com a linha de comando da conexão, alguns exemplos para digitar ou colar no konsole;
ssh -X -C zago@192.168.1.53 /usr/lib/kde3/bin/konqueror ssh -X -C zago@192.168.1.53 /usr/lib/kde3/bin/kmail
A opção -C transmite os dados compactados, economiza banda de rede, portanto opcional, cuidado que consome mais processamento, em maquinas com poucos recursos pode não valer a pena, faça testes e comparativos para avaliar a melhor opção em seu ambiente.
Localizar os executáveis, procure com whereis ou find e cole o caminho na linha de comando.
Simplificando, linha de comando para configurar sshd_config, comando para copiar e colar:
sed -i "s/#X11Forwarding no/X11Forwarding yes/g" /etc/ssh/sshd_config
reinicie o sshd service sshd restart
Feche a conexão, faça nova conexão neste formato: ssh -X zago@192.168.1.53
Quando efetuar estas alterações via conexão remota (ssh), feche a conexão para reconectar com a opção -X.
Mesmo que a maquina em uso não tenha acesso à internet, pode fazer conexão via ssh com maquina que tenha acesso para navegar, a partir do console remoto, pode chamar o navegador com a URL desejada:
konqueror www.zago.eti.br/menu.html
lynx www.zago.eti.br/menu.html
Ou em uma tacada só, conectar, chamar o konqueror, abrir um site, passar os dados da pesquisa para o Google, isto mesmo, na linha de comando já passa o que quer pesquisar para abrir o konqueror com o resultado da pesquisa, teste estes exemplos;
ssh -X -C zago@192.168.1.120 /usr/lib/kde3/bin/konqueror gg:faq+zago ssh -X -C zago@192.168.1.120 /usr/lib/kde3/bin/konqueror www.zago.eti.br/menu.html
Xterm - abre um konsole remoto
xterm -e ssh dominio.com.br xterm -e ssh ip.da.maquina.remota xterm -e ssh 192.168.1.53
Neste formato abre um terminal, digite a senha pra completar o login e ter na tua maquina um console da maquina remota.
Veja da documentação da distro, conforme a versão do ssh ou da distro pode ocorrer diferenças, como exemplo no CentOS 4.3 vem configurado para exportar o X com esta linha no /etc/ssh/sshd_config
`` ForwardX11Trusted yes``
rsync - Sincronismo de conteúdo entre servidores.
Transferir o conteúdo de diretórios ou partições entre dois computadores.
Unison - resultado da pesquisa no SUSE 10.1
Name: unison Summary: A file synchronization tool Description: Unison is a file synchronization tool for Unix and Windows. It allows two replicas of a collection of files and directories to be stored on different hosts (or different disks on the same host), modified separately, then brought up to date by propagating the changes in each replica to the other.
Conexão CAINDO.
SSH perdendo conexão, inicia copia de arquivos e cai a conexão, demora no login e comportamento inesperado.....
Procure descobrir se não tem outra maquina na rede com mesmo IP.
Sempre que ocorre perda da conexão, lentidão e outros problemas inesperados, pode ser algum problema de cabos, HUB ou configuração da rede, o mais provável é outra maquina com mesmo IP, isto é fatal, até funciona por alguns segundos mas perde a conexão, basta mudar o IP que soluciona o problema, caso não resolva, verifique também se não tem outros erros na configuração da rede, rota default, DNS e outros detalhes.
Testar conexão.
Quando não tem outra maquina para testar pode usar a própria maquina, é isto mesmo, execute a linha de comando como se faz em uma conexão remota, use outro usuário da mquina e o mesmo IP da maquina local, vai conectar na própria maquina por ssh, na primeira vez responda yes por extenso e pronto, chave nova e instalação padrão Ok.
Ocorrendo erros de conexão revise o seu firewall, se o daemon está rodando e verifique os arquivos de configuração, /etc/hosts.deny, /etc/ssh/sshd_config e outros...
Variável de ambiente
Ver qual maquina esta conectada em seu micro use a variavel de ambiente $SSH_CLIENT.
Falha na conexão
Quando tentar conexão com maquina que tenha o mesmo IP que já foi utilizado em conexão anterior, receberá um aviso em inglês que diz mais ou menos, que existe alguém interceptando a conexão, que é um ataque ou violação, esta mensagem também ocorre em caso de ataque, portanto tem duas possibilidades, um real ataque ou a maquina destino não é mais a mesma utilizada em conexão anterior com este IP, isto ocorre porque mudou a chave, como não é possivel saber a causa, por segurança recusa a conexão.
Tendo certeza que não se trata de sniffer na rede ou ataque e que é provavel a troca de IP ou instalação então edite o arquivo, .ssh/known_hosts que fica no home do usuário e remova a entrada deste IP (chave velha), neste arquivo procure pelaa linha com o IP remoto que causou o problema e apague-o, ou remova o diretorio todo, depois faça a conexão que vai recriar as chaves, vai recriar como sendo a primeira conexão com esta maquina, veja o exemplo, primeiro remove o .ssh e depois conecta por ssh:
[zago@zago zago]$ rm -rf ~/.ssh [zago@zago zago]$ ssh zago@192.168.1.1 The authenticity of host '192.168.1.1 (192.168.1.1)' can't be established. DSA key fingerprint is 32:57:2a:2b:e6:1b:da:b2:33:fe:88:2f:33:cd:b1:91. Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added '192.168.1.1' (DSA) to the list of known hosts. zago@192.168.1.1's password: Last login: Thu Jul 18 13:22:19 2002 from 192.168.1.53
FALHA NA CONEXÃO command not found
Em uma instalação que faltou o pacote opensssh-clients, quando tentava em outras maquinas copiar arquivos pra esta maquina via ssh, ocorria nas outras maquinas a mensagem de erro: bash: line 1: scp: command not found lost connection
Este erro confunde até pra explicar, em resumo, no servidor ssh que não tem o pacote openssh-clients instaldo, vai provocar a mensagem de erro nas estações que tentar enviar arquivos via ssh pra este servidor. Na estação que executar scp pra enviar o arquivo, não tem erro algum, mas a impressão é de um erro local, mesmo com a falta do pacote openssh-clients, funciona pra conexão remota mas não funciona pra copiar arquivos, pra resolver o problema faça a instalação destes pacotes:
apt-get install openssh openssh-clients openssh-server
Explicando a mensagem de erro: bash: line 1: scp: command not found
Quando instalei somente os pacotes openssh e openssh-server, conseguia fazer conexão por ssh, executar comandos na maquina remota, mas não conseguia copiar aquivos com scp, muito estranho, tentei copiar aquivos do CL9 pro CL10 e no CL9 retornava a mensagem de erro: (bash: line 1: scp: command not found), então fiz os seuintes testes:
copiar arquivo com ssh pra própria maquina rodando CL9 funciona direitinho como também pra outras maquinas com CL9 e CL10 instalado com perfil desktop corporativo, veja resultado:
zago@mail zago]$ scp sm56 zago@192.168.1.53:/tmp zago@192.168.1.53's password: sm56 100% |*****************************************************************************| 2531 00:00
Ao executar o mesmo comando na mesma maquina mas apontando pro IP da maquina com CL-10 que também está com o sshd rodando, retorna o erro:
[zago@mail zago]$ scp sm56 zago@192.168.1.1:/tmp zago@192.168.1.1's password: bash: line 1: scp: command not found lost connection
Na maquina com CL10 que tinha instalado os pacotes openssh openssh-server, instalei também o pacote openssh-clients e resolveu o problema.
Após instalar mais este pacote, sem reiniciar o sshd, voltei pra maquina com CL9 e executei a mesma linha de comando:
scp sm56 zago@192.168.1.1:/tmp e funcionou sem mensagem de erro.