SSH SCP

Veja outros truques 25 ssh cmdhttp://blog.urfix.com/25-ssh-commands-tricks/

Autenticação de chave pública

Conecte com um host sem senha utilizando autenticação com chave pública. A ideia é anexar sua chave pública ao arquivo authorized_keys2 no host remoto. Para esse exemplo vamos conectar o host-client ao host-server, a chave é gerada no cliente. Com o cygwin você pode ter que criar seu diretório home e o diretório .ssh com# mkdir -p /home/USER/.ssh

• Utilize o ssh-keygen para gerar um par de chaves. ~/.ssh/id_dsa é a chave privada, ~/.ssh/id_dsa.pub é a chave pública.
• Copie somente a chave pública ao servidor e anexe-a ao arquivo ~/.ssh/authorized_keys2 no home do seu servidor.

# ssh-keygen -t dsa -N ''
    # cat ~/.ssh/id_dsa.pub | ssh you@host-server "cat - >> ~/.ssh/authorized_keys2"

Utilizando o cliente Windows a partir do ssh.com

A versão não comercial do cliente ssh.com pode ser baixado do ftp principal: ftp.ssh.com/pub/ssh/. As chaves geradas pelo cliente ssh.com precisam ser convertidas pelo servidor OpenSSH. Isso pode ser feito com o comando ssh-keygen.

• Crie um par de chaves com o cliente ssh.com: Configurações – Autenticação de usuário – Gera Nova….
• Eu utilizo chave do tipo DSA; comprimento com chave de 2048.
• Copie a chave pública gerada pelo cliente ssh.com para o servidor dentro do diretório ~/.ssh.
• As chaves estão dentro de C:\Documents and Settings\%USERNAME%\Application Data\SSH\UserKeys.
• Utilize o comando ssh-keygen no servidor para converter a chave:

  # cd ~/.ssh
      # ssh-keygen -i -f keyfilename.pub >> authorized_keys2
  

Nota: Utilizamos uam chave DSA, RSA também é possível. A chave não é protegida por uma senha.

Utilizar o putty para o Windows

Puttyhttp://www.chiark.greenend.org.uk/~sgtatham/putty/download.html é um cliente ssh simples e livre para Windows.

• Crie um par de chaves com o programa puTTYgen.
• Salve as chaves pública e privada (dentro into C:\Documents and Settings\%USERNAME%\.ssh por exemplo).
• Copie a chave pública no servidor, dentro do diretório ~/.ssh:

  # scp .ssh/puttykey.pub root@192.168.51.254:.ssh/

• Utilize o comando ssh-keygen no servidor para converter a chave para o OpenSSH:

  # cd ~/.ssh
      # ssh-keygen -i -f puttykey.pub >> authorized_keys2
  

• Aponte o local a chave privada nas configurações do putty: Conexão – SSH – Auth

Verificar fingerprint

No primeiro login, ssh perguntará se o host desconhecido com a impressão digital (fingerprint) tem que ser armazenado nos hosts conhecidos. Para evitar um ataque man-in-the-middle, o administrador do servidor pode te enviar o fingerprint do servidor que é então comparado no primeiro login. Utilize ssh-keygen -l para obter a fingerprint (no servidor):

# ssh-keygen -l -f /etc/ssh/ssh_host_rsa_key.pub      # Para chave RSA
    2048 61:33:be:9b:ae:6c:36:31:fd:83:98:b7:99:2d:9f:cd /etc/ssh/ssh_host_rsa_key.pub
    # ssh-keygen -l -f /etc/ssh/ssh_host_dsa_key.pub      # Para chave DSA (padrão)
    2048 14:4a:aa:d9:73:25:46:6d:0a:48:35:c7:f4:16:d4:ee /etc/ssh/ssh_host_dsa_key.pub

Agora o cliente que estiver conectando á esse servidor pode verificar que está conectando ao servidor correto:

# ssh linda
    A authenticity of host 'linda (192.168.16.54)' can't be established.
    DSA key fingerprint is 14:4a:aa:d9:73:25:46:6d:0a:48:35:c7:f4:16:d4:ee.
    Are you sure you want to continue connecting (yes/no)? yes

Transferência segura de arquivo

Some simple commands:

# scp file.txt host-two:/tmp
    # scp joe@host-two:/www/*.html /www/tmp
    # scp -r joe@host-two:/www /www/tmp

No Konqueror ou Midnight Commander é possível acessar um sistema de arquivo remoto com o endereço fish://user@gate. No entanto a implementação é muito lenta.
Além disso é possível montar uma pasta (um diretório) remoto com sshfs, um cliente sistema de arquivo (file system client) baseado no SCP. Veja fuse sshfshttp://fuse.sourceforge.net/sshfs.html.

ssh_exchange_identification: Connection closed by remote host

Com esse erro tente o seguinte no servidor:

echo 'SSHD: ALL' >> /etc/hosts.allow
    /etc/init.d/sshd restart

Tunelamento

Tunelamento SSH lhe permite direcionar ou reverter a porta na conexão SSH, assim garantindo o tráfego e acessar portas que caso contrario estariam bloqueadas. Isso só funciona com TCP. A nomenclatura geral para direcionamento e reverso é (veja também exemplo de ssh e NAT):

# ssh -L localport:desthost:destport user@gate  # desthost como visto a partir do gate
    # ssh -R destport:desthost:localport user@gate  # direciona a sua porta local para o destino
        # desthost:localport como visto a partir do cliente iniciando o túnel
    # ssh -X user@gate   # Forçar o X direcionar

Isso vai conectar ao gate e direcionar a porta local ao host desthost:destport. Note que desthost é o host de destino como visto pelo gate, então se a conexão é para o gate, então desthost é o localhost. Mais do que o direcionamento de uma porta é possível.

Direcionamento direto no gate

Digamos que queremos acessar CVS (porta 2401) e http (porta 80) que estão executando no gate. Isso é o exemplo mais simples, desthost é assim o localhost, e nós usamos a porta 8080 localmente ao invés da 80 então não precisamos ser o root. uma vez que a sessão ssh está aberta, ambos os serviços estão acessíveis nas portas local.

# ssh -L 2401:localhost:2401 -L 8080:localhost:80 user@gate

Direcionamento de Netbios e de área de trabalho remota para um segundo servidor

Diagmos que um servidor smb Windows está porta trás do gate e não está rodando ssh. Precisamos de acesso para o compartilhamento smb e também para a área de trabalho no servidor.

# ssh -L 139:smbserver:139 -L 3388:smbserver:3389 user@gate

O compartilhamento smb pode agora ser acessado com o \\127.0.0.1\, mas somente se o compartilhamento local for desabilitado, por que to compartilhamento local está escutando na porta 139.
É possível manter o compartilhamento local habilitado, para isso precisamos criar um novo dispositivo virtual com um novo endereço de IP para o túnel, o compartilhamento smb será conectado nesse endereço. Além disso o RPD local já está escutando na 3389, então nós escolhemos a 3388. Para esse exemplo vamos utilizar o IP virtual de 10.1.1.1.

• Com o putty utilize a Source port=10.1.1.1:139. É possível criar dispositivos de loop e de túnel múltiplos. No Windows 2000, somente o putty funcionou para mim. No Windows Vista também direcionou para a porta 445 em adição à porta 139. Também no Vista o patch KB942624 impede a porta 445 direcionar, então eu tive que desinstalar esse path no Vista.
• Com o cliente ssh.com, desabilite “Allow local connections only”. Já que ssh.com vinculará todos os endereços, somente um único compartilhamento pode ser conectado.

Agora crie a interface de loopback com o IP 10.1.1.1:

• # System->Control Panel->Add Hardware # Yes, Hardware is already connected
  # Add a new hardware device (at bottom).
• # Install the hardware that I manually select # Network adapters # Microsoft , Microsoft Loopback Adapter.
• Configure o endereço de IP do dispositivo falso (fake) para o IP 10.1.1.1 máscara 255.255.255.0, sem gateway.
• advanced->WINS, Enable LMHosts Lookup; Disable NetBIOS over TCP/IP.
• # Abilite o Cliente para as redes Microsofts. # Desabilite Compartilhamento de Arquivo e Impressora para as Redes Microsoft.

Eu TIVE que reiniciar para que isso funcionasse. Agora conecte ao compartilhamento smb com \\10.1.1.1 e o remote desktop para 10.1.1.1:3388.

Debug

Se isso não estiver funcionando:

• As portas estão direcionadas: netstat -an? Olhe para 0.0.0.0:139 ou 10.1.1.1:139
• O telnet conecta em 10.1.1.1 139?
• Você precisa do checkbox “Local ports accept connections from other hosts” (portas locais aceitam conexões a partir de outros hosts).
• O “File and Printer Sharing for Microsoft Networks” está desabilitado na interface loopback?

Conecte dois clientes atrás do NAT

Suponhamos que dois clientes por trás de um gateway NAT e o cliente cliadmin tem que conectar ao cliente cliuser (o destino), ambos pode logar ao gate com o ssh e estão rodando linux com o sshd. Você não precisa acessar de qualquer lugar desde que as portas no gate estejam acima do 1024. Nós usamos 2022 no gate. Também desde que o gate seja utilizado localmente, a opção GatewayPorts não é necessária.
No cliente cliuser (a partir do destino para o gate):

# ssh -R 2022:localhost:22 user@gate            # direciona o cliente 22 para o gate:2022

No cliente cliadmin (a partir do host para o gate):

# ssh -L 3022:localhost:2022 admin@gate         # direciona o cliente 3022 para o gate:2022

Agora o admin pode conectar diretamente ao cliente cliuser com:

# ssh -p 3022 admin@localhost                   # local:3022 -> gate:2022 -> client:22

Conect ao VNC atrás do NAT

Suponhamos que um cliente Windows com VNC escutando na porta 5900 tem que ser acessado a partir do NAT.
No cliente cliwin para o gate:

# ssh -R 15900:localhost:5900 user@gate

No cliente cliadmin (a partir do host para o gate):

# ssh -L 5900:localhost:15900 admin@gate

Agora o admin pode conectar diretamente ao cliente VNC com:

# vncconnect -display :0 localhost

Cave (Dig) um túnel ssh multi-hop

Suponhamos que você não consiga alcançar um servidor diretamente com o ssh, mas somente via múltiplos hosts intermediários (por questões de roteamento por exemplo). Algumas vezes é necessário obter uma conexão direta cliente – servidor, por exemplo para compilar arquivos com o scp, ou direcionar outras portas como smb ou vnc.
Um jeito de fazer isso é acorrentar túneis (chain tunnels together) para direcionar uma porta para o servidor ao longo dos saltos. Essa porta “carrier” somente alcança seu destino final na ultima conexão para o servidor.
Suponhamos que queremos direcionar a porta ssh de um cliente para um servidor em dois saltos (hops). Um vez que o túnel é construído, é possível conectar ao servidor diretamente do cliente (e também adicionar um outra porta de direcionamento).

Cria túnel em um shell

cliente -> host1 -> host2 -> servidor e cave (dig) o túnel 5678

client># ssh -L5678:localhost:5678 host1        # 5678 é uma porta arbitraria para o túnel
    host_1># ssh -L5678:localhost:5678 host2        # acorrenta 5678 do host1 para o host2
    host_2># ssh -L5678:localhost:22 server         # termina o túnel na porta 22 no server

Use o túnel com um outro shell

cliente -> servidor utilizando o túnel 5678

# ssh -p 5678 localhost                         # conecta diretamente do cliente para o servidor
    # scp -P 5678 myfile localhost:/tmp/            # ou copie um arquivo diretamente utilizando o túnel
    # rsync -e 'ssh -p 5678' myfile localhost:/tmp/ # ou utilizando rsync em um arquivo diretamente ao servidor

Script de autoconectar e manter vivo (keep alive)

Eu utilizo variações do seguinte script para manter a máquina alcançável no túnel ssh reverso. A conexão é automaticamente reconstruída e fechada. Você pode adicionar múltiplos túneis -L ou -R em uma linha.

#!/bin/sh
    COMMAND="ssh -N -f -g -R 3022:localhost:22 colin@cb.vu"
    pgrep -f -x "$COMMAND" > /dev/null 2>&1 || $COMMAND
    exit 0

1 * * * * colin /home/colin/port_forward.sh     # entrada crontab (aqui de hora em hora)