{"id":421,"date":"2013-03-08T18:55:33","date_gmt":"2013-03-08T21:55:33","guid":{"rendered":"http:\/\/www.viazap.com.br\/?p=421"},"modified":"2013-03-08T18:55:33","modified_gmt":"2013-03-08T21:55:33","slug":"ssh-traducao-da-man-page","status":"publish","type":"post","link":"https:\/\/blog.clusterweb.com.br\/?p=421","title":{"rendered":"SSH – Tradu\u00e7\u00e3o da man page"},"content":{"rendered":"\n\n\n\n\n\n
Sinopse \/ Descri\u00e7\u00e3o<\/b><\/p>\n
Nome:<\/p>\n

SSH<\/em> – Cliente OpenSSH SSH (programa de login remoto)<\/p>\n

Sinopse:<\/p>\n

ssh [ -1246AaCfgKkMNnqsTtVvXxYy ] [ -b bind_address ][ -c cipher_spec ]
\n[ -D [bind_address:]port][ -e escape_char ][ -F configfile ][ -i identity_file ]
\n[ -L [bind_address:]port:host:hostport][ -l login_name ][ -m mac_spec ]
\n[ -O ctl_cmd ][ -o option ][ -p port ][ -R [bind_address:]port:host:hostport]
\n[ -S ctl_path ][ -w local_tun [:remote_tun]] [user@]hostname [ command ]<\/p>\n

Descri\u00e7\u00e3o:<\/p>\n

O SSH (cliente SSH) \u00e9 um programa para conectar-se e executar comandos em m\u00e1quina remota. \u00c9 proposital substituir o “rlogin” e o “rsh” e prover comunica\u00e7\u00f5es criptografadas de forma segura entre dois hosts n\u00e3o confi\u00e1veis sobre uma rede n\u00e3o segura. As conex\u00f5es X11 e portas TCP arbitr\u00e1rias, tamb\u00e9m podem ser encaminhadas atrav\u00e9s do canal seguro.<\/p>\n

O SSH conecta-se e faz o login em um hostname espec\u00edfico (com nome de usu\u00e1rio opcional). O usu\u00e1rio deve provar sua identidade \u00e0 m\u00e1quina remota usando um dos v\u00e1rios m\u00e9todos, dependendo da vers\u00e3o usada do protocolo (veja abaixo).<\/p>\n

Se o comando \u00e9 especificado, ele \u00e9 executado em um host remoto ao inv\u00e9s de um acesso shell.<\/p>\n

As op\u00e7\u00f5es est\u00e3o a seguir:<\/p>\n

-1<\/strong> :: Obriga o SSH a tentar somente a vers\u00e3o 1 do protocolo;<\/p>\n

-2<\/strong> :: Obriga o SSH a tentar somente a vers\u00e3o 2 do protocolo;<\/p>\n

-4<\/strong> :: Obriga o SSH a usar somente endere\u00e7os IPv4;<\/p>\n

-6<\/strong> :: Obriga o SSH a usar somente endere\u00e7os IPv6;<\/p>\n

-A<\/strong> :: Ativa o encaminhamento de uma conex\u00e3o de autentica\u00e7\u00e3o de agente. Isto tamb\u00e9m pode ser especificado numa base por host em um arquivo de configura\u00e7\u00e3o.<\/p>\n

O agente encaminhado deve ser ativado com cuidado. Usu\u00e1rios com a habilidade de ignorar arquivos de permiss\u00f5es em um host remoto (para o socket Unix-domain do agente) podem acessar o agente local pela conex\u00e3o encaminhada.<\/p>\n

Um atacante n\u00e3o pode obter material chave de um agente, por\u00e9m, ele pode executar opera\u00e7\u00f5es nas chaves que permite sua autentica\u00e7\u00e3o usando identidades carregadas no agente.<\/p>\n

-a<\/strong> :: Desativa o encaminhamento da conex\u00e3o da autentica\u00e7\u00e3o do agente;<\/p>\n

-b bind_address<\/strong> :: Usa bind_address na m\u00e1quina local como o endere\u00e7o origem da conex\u00e3o. \u00c9 \u00fatil somente em sistemas com mais de um endere\u00e7o.<\/p>\n

-C<\/strong> :: Requer compress\u00e3o de todos os dados (incluindo stdin, stdout, stderr, e dados encaminhados via X11 e conex\u00f5es TCP). O algoritmo de compress\u00e3o \u00e9 o mesmo usado pelo gzip(1), e o “n\u00edvel” pode ser controlado pela op\u00e7\u00e3o “CompressionLevel” da vers\u00e3o 1 do protocolo.<\/p>\n

A compress\u00e3o \u00e9 desejada em linhas de modem e outras conex\u00f5es mais lentas, mas ir\u00e1 somente diminuir as coisas em conex\u00f5es r\u00e1pidas. O valor padr\u00e3o pode ser definido em uma base host-para-host nos arquivos de configura\u00e7\u00e3o.<\/p>\n

Veja a op\u00e7\u00e3o compress\u00e3o:<\/p>\n

-c cipher_spec<\/strong> :: Seleciona a especifica\u00e7\u00e3o de cifra para criptografar a sess\u00e3o. A vers\u00e3o 1 do protocolo permite a especifica\u00e7\u00e3o de uma cifra \u00fanica.<\/p>\n

Os valores suportados s\u00e3o “3des”, “blowfish”, e “des”:<\/p>\n

    \n
  • O “3des” (triplo-des) \u00e9 uma tripla (encripta-decripta-encripta) com tr\u00eas diferentes chaves. Acredita-se que seja seguro.<\/li>\n
  • O “blowfish” \u00e9 uma cifra de bloco r\u00e1pida, parece ser muito seguro e bem mais r\u00e1pido que o 3des.<\/li>\n
  • O “des” \u00e9 suportado somente no cliente ssh para interoperabilidade com a implementa\u00e7\u00e3o do protocolo 1 que n\u00e3o suporta a cifra 3des. Seu uso \u00e9 fortemente desencorajado devido \u00e0s defici\u00eancias criptogr\u00e1ficas. O padr\u00e3o \u00e9 o “3des”.<\/li>\n<\/ul>\n

    Para a vers\u00e3o 2 do protocolo, cipher_spec \u00e9 uma lista de cifras separadas por v\u00edrgula listadas em ordem de prefer\u00eancia. Veja a palavra-chave “Ciphers” para mais informa\u00e7\u00f5es.<\/p>\n

    -D [bind_address:]porta<\/strong> :: Especifica um encaminhamento de uma porta de n\u00edvel de aplica\u00e7\u00e3o local “din\u00e2mica”. Funciona alocando um socket para escutar a porta no lado local, opcionalmente limitado pelo espec\u00edfico “bind_address”.<\/p>\n

    Quando uma conex\u00e3o \u00e9 feita nessa porta ela \u00e9 encaminhada sobre o canal seguro, e o protocolo da aplica\u00e7\u00e3o \u00e9 depois usado para determinar onde se conectar na m\u00e1quina remota.<\/p>\n

    Atualmente os protocolos SOCKS4 e SOCKS5 s\u00e3o suportados, e o SSH ir\u00e1 atuar como um servidor SOCKS. Somente o usu\u00e1rio root pode encaminhar portas privilegiadas. Encaminhamentos din\u00e2micos de portas podem ser especificados no arquivo de configura\u00e7\u00e3o.<\/p>\n

    Endere\u00e7os IPv6 podem ser especificados com uma sintaxe alternativa:<\/p>\n

    [ bind_address\/]porta<\/em><\/p>\n

    Ou colocando o endere\u00e7o entre chaves. Somente o superusu\u00e1rio pode encaminhar portas privilegiadas. Por padr\u00e3o a porta local \u00e9 limitada de acordo com a configura\u00e7\u00e3o do GatewayPorts. Por\u00e9m um “bind_address” expl\u00edcito pode ser usado para ligar a conex\u00e3o com o endere\u00e7o espec\u00edfico.<\/p>\n

    O “bin_address” de “localhost” indica que a porta escutada pode ser limitada somente para o usu\u00e1rio local, enquanto um endere\u00e7o vazio, ou ‘*’, indica que a porta deve estar dispon\u00edvel para todas as interfaces.<\/p>\n

    -e escape_char<\/strong> :: Define o caractere de escape para sess\u00f5es com tty (default: “~”). O caractere de escape \u00e9 somente reorganizado no come\u00e7o de uma linha. Se o caractere de escape for seguido por um ponto (‘.’) fecha a conex\u00e3o; seguido por Ctrl-Z<\/strong> suspende a conex\u00e3o; e seguido por si mesmo envia o caractere de escape uma vez. Definindo o caractere como “none”\/”nenhum” desativa quaisquer escapes e torna a sess\u00e3o completamente transparente.<\/p>\n

    -F configfile<\/strong> :: Especifica um arquivo de configura\u00e7\u00e3o alternativo por usu\u00e1rio. Se um arquivo de configura\u00e7\u00e3o \u00e9 passado por linha de comando, o arquivo de configura\u00e7\u00e3o de todo o sistema (\/etc\/ssh\/ssh_config<\/em>) ser\u00e1 ignorado. O padr\u00e3o para um arquivo de configura\u00e7\u00e3o por usu\u00e1rio \u00e9: ~\/.ssh\/config<\/em>.<\/p>\n

    -f<\/strong> :: Pede para o SSH ir para background antes da execu\u00e7\u00e3o do comando. \u00c9 \u00fatil se o SSH vai perguntar por senhas ou frases secretas, mas o usu\u00e1rio o quer em background. Isto implica em “-n”. O modo recomendado para iniciar programas X11 em um site remoto \u00e9 com alguma coisa do tipo: ssh -f host xterm.<\/p>\n

    Se a op\u00e7\u00e3o de configura\u00e7\u00e3o “ExitOnForwardFailure” for definida como “yes”, logo, um cliente iniciado com “-f” ir\u00e1 esperar por todos os encaminhamentos das portas remotas serem estabelecidas com sucesso antes de colocarem a si mesmos em background.<\/p>\n

    -g<\/strong> :: Permite hosts remotos conectarem-se \u00e0 portas de encaminhamento locais.<\/p>\n

    -I smartcard_device<\/strong> :: Especifica o dispositivo que SSH deve usar para se comunicar com um smartcard usado para guardar a chave privada RSA dos usu\u00e1rios. Esta op\u00e7\u00e3o est\u00e1 dispon\u00edvel apenas se o suporte para dispositivos smartcards forem compilados (padr\u00e3o n\u00e3o \u00e9 suportado).<\/p>\n

    -i identity_file<\/strong> :: Seleciona um arquivo de onde cada identidade (chave privada) para autentica\u00e7\u00f5es RSA ou DAS s\u00e3o lidas. O padr\u00e3o \u00e9 ~\/.ssh\/identity<\/em> para a vers\u00e3o 1 do protocolo, e ~\/.ssh\/id_rsa<\/em> e ~\/.ssh\/id_dsa<\/em> para a vers\u00e3o 2 do protocolo.<\/p>\n

    Arquivos de identidade devem ser especificados em uma base por host em um arquivo de configura\u00e7\u00e3o. \u00c9 poss\u00edvel ter m\u00faltiplas op\u00e7\u00f5es “-i” (e m\u00faltiplas identidades especificadas em um arquivo de configura\u00e7\u00e3o).<\/p>\n

    -K<\/strong> :: Ativa a autentica\u00e7\u00e3o GSSAPI e encaminha (delega\u00e7\u00e3o) das credenciais GSSAPI para o servidor.<\/p>\n

    -k<\/strong> :: Desativa o encaminhamento (delega\u00e7\u00e3o) das credenciais GSSAPI para o servidor.<\/p>\n

    -L [bind_address:]port:host:hostport<\/strong> :: Especifica que a porta passada no host local (cliente) deve ser encaminhada para o host passado e porta no lado remoto.<\/p>\n

    Isso funciona basicamente alocando-se um socket para escutar uma porta no lado local, opcionalmente ligada ao “bind_address”. Sempre que uma conex\u00e3o \u00e9 feita nessa porta, a conex\u00e3o \u00e9 encaminhada sobre o canal seguro, e a conex\u00e3o \u00e9 feita na porta do host (host port) da m\u00e1quina remota.<\/p>\n

    Encaminhamentos de portas podem ser especificados em um arquivo de configura\u00e7\u00e3o. Endere\u00e7os IPv6 podem ser especificados com uma sintaxe alternativa:<\/p>\n

    [ bind_address\/]port\/host\/hostport<\/em><\/p>\n

    Ou, colocando o endere\u00e7o entre chaves. Somente o superusu\u00e1rio pode encaminhar portas privilegiadas. Por padr\u00e3o, a porta local \u00e9 ligada de acordo com a configura\u00e7\u00e3o GatewayPorts. Por\u00e9m, um “bind_address” expl\u00edcito pode se usado para ligar a conex\u00e3o a um endere\u00e7o espec\u00edfico.<\/p>\n

    O “bind_address” de um “localhost” indica que a porta que escuta seja ligada somente para o usu\u00e1rio local, enquanto um endere\u00e7o vazio, ou ‘*’, indica que a porta deve estar dispon\u00edvel para todas as interfaces.<\/p>\n

    -l login_name<\/strong> :: Especifica o usu\u00e1rio a logar na m\u00e1quina remota. Isto tamb\u00e9m pode ser especificado em uma base por host em um arquivo de configura\u00e7\u00e3o.<\/p>\n

    -M<\/strong> :: Coloca o cliente SSH no modo “master” para compartilhamento de conex\u00e3o. M\u00faltiplas op\u00e7\u00f5es “-M” coloca o SSH no modo “master” com confirma\u00e7\u00e3o necess\u00e1ria antes que conex\u00f5es escravas sejam aceitas. Veja a descri\u00e7\u00e3o do ControlMaster em “ssh_config(5)” para mais detalhes.<\/p>\n

    -m mac_spec<\/strong> :: Adicionalmente, para o protocolo vers\u00e3o 2, uma lista de algoritmos MAC (c\u00f3digo de autentica\u00e7\u00e3o de mensagem) separada por v\u00edrgulas pode ser especificada em ordem de prefer\u00eancia. Veja a palavra chave MAC para mais informa\u00e7\u00f5es.<\/p>\n

    -N<\/strong> :: N\u00e3o executa um comando remoto. Pode ser \u00fatil apenas para portas de encaminhamento (apenas protocolo vers\u00e3o 2).<\/p>\n

    -n<\/strong> :: Redireciona a sa\u00edda “stdin” para \/dev\/null<\/em> (na verdade, previne a leitura do “stdin”). Deve ser usado quando o SSH roda em background. Um truque comum \u00e9 usar isso para executar programas X11 em uma m\u00e1quina remota. Por exemplo:<\/p>\n

    $ ssh -n shadows.cs.hut.fi emacs &<\/strong><\/p>\n

    Ir\u00e1 iniciar um Emacs em shadows.cs.hut.fi<\/em>, e a conex\u00e3o X11 ser\u00e1 automaticamente encaminhada sobre um canal criptografado. O programa SSH ir\u00e1 ser colocado em background (isso n\u00e3o funciona se o SSH precisar perguntar por uma senha ou frase secreta. Veja tamb\u00e9m a op\u00e7\u00e3o: -f).<\/p>\n

    -O ctl_cmd<\/strong> :: Controla uma conex\u00e3o ativa multiplexando processos mestre. Quando a op\u00e7\u00e3o “-O” \u00e9 especificada, o argumento “ctl_cmd” \u00e9 interpretado e passado para o processo mestre. Os comandos v\u00e1lidos s\u00e3o:<\/p>\n

      \n
    • check<\/em> :: Checa se o processo mestre est\u00e1 executando;<\/li>\n
    • exit<\/em> :: Solicita o mestre para sair.<\/li>\n<\/ul>\n

      -o option<\/strong> :: Pode ser usado para fornecer op\u00e7\u00f5es no formato usado no arquivo de configura\u00e7\u00e3o. Isto \u00e9 \u00fatil para especificar op\u00e7\u00f5es que n\u00e3o s\u00e3o separadas por uma flag de linha de comando.<\/p>\n

      Para detalhes completos das op\u00e7\u00f5es listadas abaixo, e seus poss\u00edveis valores, veja o “ssh_config(5)”:<\/p>\n

        \n
      • AddressFamily<\/li>\n
      • BatchMode<\/li>\n
      • BindAddress<\/li>\n
      • ChallengeResponseAuthentication<\/li>\n
      • CheckHostIP<\/li>\n
      • Cipher<\/li>\n
      • Ciphers<\/li>\n
      • ClearAllForwardings<\/li>\n
      • Compression<\/li>\n
      • CompressionLevel<\/li>\n
      • ConnectionAttempts<\/li>\n
      • ConnectTimeout<\/li>\n
      • ControlMaster<\/li>\n
      • ControlPath<\/li>\n
      • DynamicForward EscapeChar<\/li>\n
      • ExitOnForwardFailure<\/li>\n
      • ForwardAgent<\/li>\n
      • ForwardX11<\/li>\n
      • ForwardX11Trusted<\/li>\n
      • GatewayPorts<\/li>\n
      • GlobalKnownHostsFile<\/li>\n
      • GSSAPIAuthentication<\/li>\n
      • GSSAPIDelegateCredentials<\/li>\n
      • HashKnownHosts<\/li>\n
      • Host<\/li>\n
      • HostbasedAuthentication<\/li>\n
      • HostKeyAlgorithms<\/li>\n
      • HostKeyAlias<\/li>\n
      • HostName<\/li>\n
      • IdentityFile<\/li>\n
      • IdentitiesOnly<\/li>\n
      • KbdInteractiveDevices<\/li>\n
      • LocalCommand<\/li>\n
      • LocalForward<\/li>\n
      • LogLevel<\/li>\n
      • MACs<\/li>\n
      • NoHostAuthenticationForLocalhost<\/li>\n
      • NumberOfPasswordPrompts<\/li>\n
      • PasswordAuthentication<\/li>\n
      • PermitLocalCommand<\/li>\n
      • Port<\/li>\n
      • PreferredAuthentications<\/li>\n
      • Protocol<\/li>\n
      • ProxyCommand<\/li>\n
      • PubkeyAuthentication<\/li>\n
      • RekeyLimit<\/li>\n
      • RemoteForward<\/li>\n
      • RhostsRSAAuthentication<\/li>\n
      • RSAAuthentication<\/li>\n
      • RemoteForward<\/li>\n
      • RhostsRSAAuthentication<\/li>\n
      • RSAAuthentication<\/li>\n
      • SendEnv<\/li>\n
      • ServerAliveInterval<\/li>\n
      • ServerAliveCountMax<\/li>\n
      • StrictHostKeyChecking<\/li>\n
      • TCPKeepAlive<\/li>\n
      • Tunnel<\/li>\n
      • TunnelDevice<\/li>\n
      • UsePrivilegedPort<\/li>\n
      • User<\/li>\n
      • UserKnownHostsFile<\/li>\n
      • VerifyHostKeyDNS<\/li>\n
      • VisualHostKey<\/li>\n
      • XAuthLocation<\/li>\n<\/ul>\n

        -p porta<\/strong> :: Porta para conectar no host remoto. Isto pode ser especificado em uma base por host no arquivo de configura\u00e7\u00e3o.<\/p>\n

        -q<\/strong> :: Modo quieto. Faz com que a maioria das mensagens de aviso e diagn\u00f3stico sejam suprimidas. Apenas erros fatais s\u00e3o exibidos. Se um segundo “-q” \u00e9 dado, ent\u00e3o, mesmo erros fatais s\u00e3o suprimidos, exceto aqueles produzidos por argumentos errados.<\/p>\n

        -R [endere\u00e7o_de_liga\u00e7\u00e3o:]porta:host:porta_do_host<\/strong> :: Especifica que a dada porta no host (servidor) remoto ser\u00e1 direcionada para o host e porta dados no lado no local.<\/p>\n

        Isto funciona por meio de uma aloca\u00e7\u00e3o de socket para escutar a porta no lado remoto, e quando a conex\u00e3o \u00e9 feita nesta porta, a conex\u00e3o \u00e9 direcionada sobre um canal seguro, e uma conex\u00e3o \u00e9 feita para host na porta “porta_do_host” da m\u00e1quina local.<\/p>\n

        Direcionamento de portas pode tamb\u00e9m ser especificado no arquivo de configura\u00e7\u00e3o. Portas privilegiadas s\u00f3 podem ser direcionadas quando estiver logado como root na m\u00e1quina remota. Endere\u00e7os IPv6 podem ser especificados por meio de uma inclus\u00e3o do endere\u00e7o entre colchetes ou usando uma sintaxe alternativa:<\/p>\n

        [bind_address\/]host\/port\/hostport<\/em><\/p>\n

        Por padr\u00e3o o socket que est\u00e1 escutando no servidor ser\u00e1 ligado para a interface de loopback<\/em> somente. Isto pode ser sobrescrito especificando um endere\u00e7o_de_liga\u00e7\u00e3o. Um endere\u00e7o_de_liga\u00e7\u00e3o vazio, ou o endere\u00e7o ‘*’, indica que o socket remoto deve escutar em todas as interfaces. Especificando um endere\u00e7o_de_liga\u00e7\u00e3o remoto s\u00f3 ir\u00e1 ter sucesso se a op\u00e7\u00e3o GatewayPorts do servidor estiver habilitada (veja: ssh_config(5) ).<\/p>\n

        Se o argumento porta for ‘0’, a porta de escuta ser\u00e1 dinamicamente alocada no servidor e reportada para o cliente em tempo de execu\u00e7\u00e3o. Quando usado junto com “-O forward”, a porta alocada ser\u00e1 impressa na sa\u00edda padr\u00e3o.<\/p>\n

        -S caminho_ctl<\/strong> :: Especifica a localiza\u00e7\u00e3o de um socket de controle para compartilhamento de conex\u00e3o, ou a cadeia “none” para desabilitar o compartilhamento de conex\u00e3o. Consulte a descri\u00e7\u00e3o de ControlPath e ControlMaster em ssh_config(5) para mais detalhes.<\/p>\n

        -s<\/strong> :: Pode ser usado para requisitar uma invoca\u00e7\u00e3o de um subsistema no sistema remoto. Subsistemas s\u00e3o uma caracter\u00edstica do protocolo SSH2 o qual facilita o uso do SSH como um transporte seguro para outras aplica\u00e7\u00f5es (ex.: sftp(1)). O subsistema \u00e9 especificado como o comando remoto.<\/p>\n

        -T<\/strong> :: Desativa a aloca\u00e7\u00e3o de pseudo-tty<\/em>.<\/p>\n

        -t<\/strong> :: For\u00e7a a aloca\u00e7\u00e3o pseudo-tty. Isto pode ser usado para executar programas arbitr\u00e1rios baseados em tela em uma m\u00e1quina remota, o qual pode ser muito \u00fatil, por exemplo, quando estiver implementando servi\u00e7os de menu. M\u00faltiplas op\u00e7\u00f5es “-t” for\u00e7am a aloca\u00e7\u00e3o tty, mesmo se o SSH n\u00e3o tem um tty local.<\/p>\n

        -V<\/strong> :: Mostra o n\u00famero da vers\u00e3o e sai.<\/p>\n

        -v<\/strong> :: Modo de detalhe. Faz o SSH imprimir mensagens de depura\u00e7\u00e3o sobre o seu progresso. Isto \u00e9 \u00fatil para depurar problemas de conex\u00e3o, autentica\u00e7\u00e3o e configura\u00e7\u00e3o. M\u00faltiplas op\u00e7\u00f5es “-v” aumentam o detalhamento. O m\u00e1ximo \u00e9 3.<\/p>\n

        -w – local_tun[:remote_tun]<\/strong> :: Requisita um encaminhamento de dispositivo de encapsulamento com os dispositivos tun(4) especificados entre o cliente (local_tun) e o servidor (remote_tun).<\/p>\n

        Os dispositivos podem ser especificados por ID num\u00e9rico ou pela palavra-chave “any” (qualquer), que faz utilizar o pr\u00f3ximo dispositivo de encapsulamento dispon\u00edvel.<\/p>\n

        Se “remote_tun” n\u00e3o for especificado, “any” \u00e9 utilizado por padr\u00e3o. Veja tamb\u00e9m as diretivas Tunnel e TunnelDevice em ssh_config(5)<\/em>. Se a diretiva Tunnel estiver indefinida, ser\u00e1 definido o modo de encapsulamento padr\u00e3o, que \u00e9 “point-to-point” (ponto-a-ponto).<\/p>\n

        -X<\/strong> :: Habilita o encaminhamento de X11. Isto pode ser especificado por host no arquivo de configura\u00e7\u00e3o.<\/p>\n

        O encaminhamento de X11 deve ser habilitado com cuidado. Usu\u00e1rios com a habilidade de contornar permiss\u00f5es de arquivos no host remoto (para o banco de dados de autoriza\u00e7\u00e3o X do usu\u00e1rio) podem acessar o display X11 local atrav\u00e9s da conex\u00e3o encaminhada.<\/p>\n

        Uma pessoa pode atacar e conseguir fazer atividades como monitoramento de teclas pressionadas. Por esta raz\u00e3o, o encaminhamento X11 est\u00e1 sujeito, por padr\u00e3o, \u00e0 extens\u00e3o de restri\u00e7\u00f5es X11 SECURITY (seguran\u00e7a).<\/p>\n

        Por favor, refira-se \u00e0 op\u00e7\u00e3o “-Y” do SSH e a diretiva ForwardX11Trusted no “ssh_config(5)” para mais informa\u00e7\u00f5es.<\/p>\n

        -x<\/strong> :: Desativa o encaminho de X11.<\/p>\n

        -Y<\/strong> :: Habilita o encaminhamento confi\u00e1vel de X11. O encaminhamento confi\u00e1vel de X11 n\u00e3o est\u00e1 sujeito aos controles de extens\u00e3o X11 SECURITY.<\/p>\n

        -y<\/strong> :: Envia informa\u00e7\u00f5es do log utilizando o m\u00f3dulo de sistema syslog(3). Por padr\u00e3o, esta informa\u00e7\u00e3o \u00e9 enviada para stderr<\/em>.<\/p>\n

        O SSH, adicionalmente, poder\u00e1 obter dados de configura\u00e7\u00e3o de um arquivo de configura\u00e7\u00e3o por usu\u00e1rio e um arquivo abrangente do sistema. O formato do arquivo e as op\u00e7\u00f5es de configura\u00e7\u00e3o, s\u00e3o descritos em “ssh_config(5)”.<\/p>\n

        O SSH sai com o status de sa\u00edda do comando remoto, ou com 255, se um erro ocorrer.<\/p>\n<\/div>\n<\/td>\n<\/tr>\n

Autentica\u00e7\u00e3o<\/b><\/p>\n
O cliente SSH<\/em> do OpenSSH<\/em> suporta os protocolos SSH 1 e 2. O protocolo 2 \u00e9 o padr\u00e3o, com SSH voltando para o protocolo 1 se detectar que o protocolo 2 n\u00e3o \u00e9 suportado. Estas configura\u00e7\u00f5es podem ser alteradas usando a op\u00e7\u00e3o Protocol em “ssh_config(5)”, ou impostas usando as op\u00e7\u00f5es “-1” e “-2” (veja acima).<\/p>\n

Ambos os protocolos suportam m\u00e9todos semelhantes de autentica\u00e7\u00e3o, mas o protocolo 2 \u00e9 prefer\u00edvel, pois proporciona mecanismos adicionais de confidencialidade (o tr\u00e1fego \u00e9 encriptado usando AES, 3DES, Blowfish, CAST128, ou Arcfour) e integridade (HMAC-MD5, HMAC-SHA1, UMAC-64, HMAC-RIPEMD160). O protocolo 1 carece de um forte mecanismo para assegurar a integridade da conex\u00e3o.<\/p>\n

Os m\u00e9todos dispon\u00edveis para autentica\u00e7\u00e3o s\u00e3o:<\/p>\n

Caracteres \/ Encaminhamento \/ Chaves de host<\/b><\/p>\n
\n

Caracteres de escape<\/h1>\n

Quando um pseudo-terminal for requisitado, o SSH suporta um n\u00famero de fun\u00e7\u00f5es atrav\u00e9s do uso de um caractere de escape.<\/p>\n

Um simples til (~) pode ser enviado como “–“, ou colocando um caractere na frente no til que n\u00e3o esteja descrito abaixo. O caractere de escape deve sempre seguir uma quebra de linha para ser interpretado como especial.<\/p>\n

O caractere de escape pode ser trocado nos arquivos de configura\u00e7\u00e3o usando a diretiva de configura\u00e7\u00e3o EscapeChar<\/em> ou na linha de comando pela op\u00e7\u00e3o “-e”.<\/p>\n

Os escapes suportados (assumindo o padr\u00e3o ‘-‘) s\u00e3o:<\/p>\n

    \n
  • -. :: Desconectar.<\/li>\n
  • -^Z :: SSH em background.<\/li>\n
  • -# :: Listar as conex\u00f5es encaminhadas.<\/li>\n
  • -& :: Coloca o SSH em background no logout quando estiver esperando conex\u00f5es encaminhadas\/ sess\u00f5es X11 terminarem.<\/li>\n
  • -? :: Mostra uma lista de caracteres de escape.<\/li>\n
  • -B :: Envia um BREAK para o sistema remoto (s\u00f3 \u00e9 \u00fatil para o procotolo SSH vers\u00e3o 2 e se o par suportar).<\/li>\n
  • -C :: Abre a linha de comando. Atualmente, isto permite a adi\u00e7\u00e3o de encaminhamento de portas usando as op\u00e7\u00f5es “-L”, “-R” e “-D” (veja acima). Tamb\u00e9m permite o cancelamento de encaminhamentos de porta remotos existentes usando “-KR[endere\u00e7o_de_liga\u00e7\u00e3o:]porta”.<\/li>\n
  • !command :: Permite o usu\u00e1rio executar um comando local se a op\u00e7\u00e3o PermitLocalCommand<\/em> estiver habilitada em “ssh_config(5)”. Uma ajuda b\u00e1sica est\u00e1 dispon\u00edvel, usando a op\u00e7\u00e3o “-h”.<\/li>\n
  • -R :: Requisita o rechaveamento da conex\u00e3o (s\u00f3 \u00e9 \u00fatil para o protocolo SSH vers\u00e3o 2 e se o par suportar).<\/li>\n<\/ul>\n

    Encaminhamento TCP<\/h1>\n

    O encaminhamento de conex\u00f5es TCP arbitr\u00e1rias, sobre o canal seguro, podem ser especificadas ou na linha de comando ou no arquivo de configura\u00e7\u00e3o. Uma poss\u00edvel aplica\u00e7\u00e3o para o encaminhamento TCP \u00e9 uma conex\u00e3o segura para um servidor de correio eletr\u00f4nico; outra \u00e9 ir atrav\u00e9s de firewalls.<\/p>\n

    No exemplo abaixo deparamos com a encripta\u00e7\u00e3o da comunica\u00e7\u00e3o entre um cliente e servidor IRC, mesmo que o servidor IRC n\u00e3o suporte comunica\u00e7\u00f5es encriptadas diretamente.<\/p>\n

    Isto funciona da seguinte maneira. O usu\u00e1rio conecta no host remoto usando SSH, especificando uma porta para ser usada para encaminhar conex\u00f5es para o servidor remoto. Depois disso pode-se iniciar o servi\u00e7o o qual ser\u00e1 encriptado na m\u00e1quina cliente, conectando na mesma porta local, e o SSH ir\u00e1 encriptar e encaminhar a conex\u00e3o.<\/p>\n

    O exemplo a seguir encapsula uma sess\u00e3o IRC da m\u00e1quina cliente “127.0.0.1” (localhost) para o servidor remoto “server.example.com”:<\/p>\n

    $ ssh -f -L 1234:localhost:6667 server.example.com sleep 10
    \n$ irc -c ‘#users’ -p 1234 pinky 127.0.0.1<\/strong><\/p>\n

    Isto encapsula uma conex\u00e3o para o servidor IRC “server.example.com”, unindo ao canal “#users”, com nickname “pinky”, usando a porta 1234. N\u00e3o importa qual porta \u00e9 usada, desde que seja maior que 1023 (lembre-se: somente o root pode abrir sockets em portas privilegiadas) e n\u00e3o conflita com qualquer porta que j\u00e1 esteja em uso. A conex\u00e3o \u00e9 encaminhada para a porta 6667 no servidor remoto, j\u00e1 que esta \u00e9 a porta padr\u00e3o para servi\u00e7os IRC.<\/p>\n

    A op\u00e7\u00e3o “-f” faz o SSH ficar em background e o comando remoto “sleep 10” \u00e9 especificado para permitir uma quantidade de tempo (10 segundos, no exemplo) para iniciar o servi\u00e7o que ir\u00e1 ser encapsulado. Se nenhuma conex\u00e3o for feita no tempo especificado, o SSH sair\u00e1.<\/p>\n

    Encaminhamento X11<\/h1>\n

    Se a vari\u00e1vel ForwardX11<\/em> estiver definida como “yes” (ou veja acima a descri\u00e7\u00e3o das op\u00e7\u00f5es “-X”, “-x”, e “-Y”) e o usu\u00e1rio estiver usando X11 (a vari\u00e1vel de ambiente DISPLAY est\u00e1 definida), a conex\u00e3o para o display X11 \u00e9 automaticamente encaminhada para o lado remoto, de tal maneira que, quaisquer programas X11 iniciados pelo shell (ou comando) ir\u00e3o atrav\u00e9s do canal encriptado, e a conex\u00e3o para o verdadeiro servidor X ser\u00e1 feita a partir da m\u00e1quina local.<\/p>\n

    O usu\u00e1rio n\u00e3o deve definir DISPLAY manualmente. Encaminhamento de conex\u00f5es X11 podem ser configuradas pela linha de comando ou nos arquivos de configura\u00e7\u00e3o.<\/p>\n

    O valor definido para DISPLAY pelo SSH ir\u00e1 apontar para a m\u00e1quina servidor, mas com um n\u00famero de display maior que zero. Isto \u00e9 normal, e acontece porque o SSH cria um servidor X “proxy” na m\u00e1quina servidor para encaminhar conex\u00f5es sobre o canal encriptado.<\/p>\n

    O SSH tamb\u00e9m ir\u00e1 definir dados Xauthority<\/em> automaticamente na m\u00e1quina servidor. Para este fim, ele criar\u00e1 um cookie de autoriza\u00e7\u00e3o aleat\u00f3ria, armazen\u00e1-lo em Xauthority no servidor, e verificar que as conex\u00f5es encaminhadas que carregam esse cookie e substitu\u00ed-lo pelo cookie real quando a conex\u00e3o \u00e9 aberta. O cookie de autentica\u00e7\u00e3o real nunca \u00e9 enviado para a m\u00e1quina servidor (e nenhum cookie \u00e9 enviado na \u00edntegra).<\/p>\n

    Se a vari\u00e1vel ForwardAgent \u00e9 definida como “yes” (ou veja a descri\u00e7\u00e3o das op\u00e7\u00f5es “-A” e “-a”, acima) e o usu\u00e1rio est\u00e1 usando um agente de autentica\u00e7\u00e3o, a conex\u00e3o com o agente \u00e9 automaticamente encaminhada para o lado remoto.<\/p>\n

    Verificando chaves de host<\/h1>\n

    Ao se conectar a um servidor pela primeira vez, um fingerprint<\/em> (impress\u00e3o digital) da chave p\u00fablica do servidor \u00e9 apresentado ao usu\u00e1rio (a menos que a op\u00e7\u00e3o foi StrictHostKeyChecking<\/em> desativada). Fingerprints podem ser determinados usando “ssh-keygen(1)”:<\/p>\n

    $ ssh-keygen -l -f \/etc\/ssh\/ssh_host_rsa_key<\/strong><\/p>\n

    Se o fingerprint j\u00e1 \u00e9 conhecido, ele pode ser comparado e a chave pode ser aceita ou rejeitada. Por causa da dificuldade de comparar chaves de host s\u00f3 de olhar para cadeias hexadecimais, tamb\u00e9m h\u00e1 suporte para comparar chaves de host visualmente, usando arte aleat\u00f3ria.<\/p>\n

    Ao definir a op\u00e7\u00e3o VisualHostKey para “yes”, um pequeno gr\u00e1fico ASCII \u00e9 exibido em cada login para um servidor, n\u00e3o importando se a sess\u00e3o em si \u00e9 interativa ou n\u00e3o.<\/p>\n

    Ao aprender o padr\u00e3o que um servidor conhecido produz, um usu\u00e1rio pode facilmente descobrir que a chave de host mudou quando um padr\u00e3o completamente diferente \u00e9 exibido. Por causa que estes padr\u00f5es n\u00e3o s\u00e3o amb\u00edguos no entanto, um padr\u00e3o que se parece com o padr\u00e3o lembrado apenas d\u00e1 uma boa probabilidade de que a chave de host \u00e9 a mesma, e n\u00e3o uma prova garantida.<\/p>\n

    Para obter uma lista dos fingerprints, juntamente com sua arte aleat\u00f3ria para todos os hosts conhecidos, a seguinte linha de comando pode ser usada:<\/p>\n

    $ ssh-keygen -lv -f -\/.ssh\/known_hosts<\/strong><\/p>\n

    Se o fingerprint \u00e9 desconhecido, um m\u00e9todo alternativo est\u00e1 dispon\u00edvel: “fingerprints de SSH verificados por DNS”. Um registro de recurso (RR) adicional, SSHFP, \u00e9 adicionado a um zonefile (arquivo de zonas) e o cliente que est\u00e1 conectando poder\u00e1 comparar o fingerprint com aquele da chave apresentada.<\/p>\n

    Neste exemplo, estamos conectando um cliente para um servidor (host.example.com). O registro de recurso SSHFP deve, primeiramente, ser adicionado ao zonefile para “host.example.com”:<\/p>\n

    $ ssh-keygen -r host.example.com<\/strong><\/p>\n

    As linhas de sa\u00edda ter\u00e3o de ser adicionadas ao zonefile. Para verificar que a zona est\u00e1 respondendo consultas de impress\u00f5es digitais:<\/p>\n

    $ dig -t SSHFP host.example.com<\/strong><\/p>\n

    Finalmente, o cliente conecta:<\/p>\n

    $ ssh -o “VerifyHostKeyDNS ask” host.example.com<\/strong>
    \n[…]
    \nMatching host key fingerprint found in DNS.<\/p>\n

    Are you sure you want to continue connecting (yes\/no)?<\/p><\/blockquote>\n

    Para mais informa\u00e7\u00f5es, veja o VerifyHostKeyDNS<\/em>, op\u00e7\u00e3o em “ssh_config(5)”.<\/p>\n<\/div>\n<\/td>\n<\/tr>\n

Base Virtual \/ Ambiente \/ Files<\/b><\/p>\n
\n

SSH – Base Virtual de Redes Privadas<\/h1>\n

SSH cont\u00e9m suporte para Virtual Private Network (VPN) tunnelling<\/em> usando tun(4) rede pseudo-device permitindo que duas redes se juntem de forma segura. O “sshd_config(5)”, op\u00e7\u00e3o de configura\u00e7\u00e3o PermitTunnel, controla se o servidor suporta isso, e em que n\u00edvel (camada 2 ou 3 de tr\u00e1fego).<\/p>\n

O exemplo a seguir, iria ligar a rede cliente “10.0.50.0\/24” com a rede remota “10.0.99.0\/24” usando uma conex\u00e3o ponto-a-ponto a partir de “10.1.1.1” a “10.1.1.2”, desde que o servidor SSH esteja rodando no gateway para a rede remota, em “192.168.1.15”, permitir.<\/p>\n

No cliente:<\/p>\n

# ssh -f -w 0:1 192.168.1.15 true
\n# ifconfig tun0 10.1.1.1 10.1.1.2 netmask 255.255.255.252
\n# route add 10.0.99.0\/24 10.1.1.2<\/strong><\/p>\n

No servidor:<\/p>\n

# ifconfig tun1 10.1.1.2 10.1.1.1 netmask 255.255.255.252
\n# route add 10.0.50.0\/24 10.1.1.1<\/strong><\/p>\n

O acesso do cliente pode ser mais afinado atrav\u00e9s do arquivo \/root\/.ssh\/authorized_keys<\/em> (veja abaixo) e a op\u00e7\u00e3o do servidor PermitRootLogin. A entrada a seguir, permitir\u00e1 conex\u00f5es em tun(4) dispositivo 1 para o usu\u00e1rio “Jane” e em tun dispositivo 2 para o usu\u00e1rio “john”, se PermitRootLogin \u00e9 definido para “forced-commands-only”:<\/p>\n

tunnel=”1″,command=”sh \/etc\/netstart tun1″ ssh-rsa … jane
\ntunnel=”2″,command=”sh \/etc\/netstart tun2″ ssh-rsa … John<\/div>\n

Desde que uma instala\u00e7\u00e3o SSH-based implica em certa quantidade de sobrecarga, pode ser mais adequado para instala\u00e7\u00f5es tempor\u00e1rias, como para VPNs sem fio. VPNs mais permanentes s\u00e3o melhores fornecidas por ferramentas, como “ipsecctl(8)” e “isakmpd(8)”.<\/p>\n

Ambiente<\/h1>\n

SSH normalmente define as seguintes vari\u00e1veis de ambiente:<\/p>\n

    \n
  • DISPLAY – A vari\u00e1vel DISPLAY indica a localiza\u00e7\u00e3o do servidor X11. \u00c9 automaticamente definida por SSH para apontar a um valor na forma de “hostname:n”, onde “hostname” indica o host onde o shell \u00e9 executado e ‘n’ \u00e9 um inteiro “- 1. ssh” utiliza este valor especial para transmitir conex\u00f5es X11 pelo canal seguro. O usu\u00e1rio normalmente n\u00e3o deveria definir DISPLAY explicitamente, como que vai tomar a conex\u00e3o X11 insegura (e exigir\u00e1 ao usu\u00e1rio copiar manualmente qualquer autoriza\u00e7\u00e3o necess\u00e1ria de cookies).<\/li>\n
  • HOME – Definido para o caminho do diret\u00f3rio HOME do usu\u00e1rio.<\/li>\n
  • LOGNAME: Sin\u00f4nimo de USER – Definido para compatibilidade com sistemas que utilizam esta vari\u00e1vel.<\/li>\n
  • MAIL – Definido para o caminho da caixa postal (mailbox) do usu\u00e1rio.<\/li>\n
  • PATH – Definido para o caminho (PATH) padr\u00e3o, conforme especificado na compila\u00e7\u00e3o do SSH.<\/li>\n
  • SSH_ASKPASS – Se SSH precisar de uma senha, ele ir\u00e1 ler a senha do terminal atual se ele foi executado a partir de um terminal. Se SSH n\u00e3o tem um terminal associado a ele, mas DISPLAY e SSH_ASKPASS est\u00e3o definidos, ele ir\u00e1 executar o programa especificado por SSH_ASKPASS e abrir\u00e1 uma janela X11 para ler a senha. Isso \u00e9 particularmente \u00fatil quando se chama ssh de um “.xsession” ou escrita relacionada (note que em algumas m\u00e1quinas, pode ser necess\u00e1rio redirecionar a entrada de \/dev\/null<\/em> para fazer este trabalho).<\/li>\n
  • SSH_AUTH_SOCK – Identifica o caminho de um dom\u00ednio UNIX-soquete usado para se comunicar com o agente.<\/li>\n
  • SSH_CONNECTION – Identifica as extremidades da conex\u00e3o cliente e servidor. A vari\u00e1vel cont\u00e9m quatro espa\u00e7os de valores separados: endere\u00e7o IP do cliente, n\u00famero de porta do cliente, endere\u00e7o IP do servidor e n\u00famero de porta do servidor.<\/li>\n
  • SSH_ORIGINAL_COMMAND – Esta vari\u00e1vel cont\u00e9m a linha de comando original se um comando for\u00e7ado \u00e9 executado. Ele pode ser usado para extrair os argumentos originais.<\/li>\n
  • SSH_TTY – Este \u00e9 definido para o nome da tty (caminho para o dispositivo) associado com o shell atual ou comando. Se a sess\u00e3o atual n\u00e3o tem tty, esta vari\u00e1vel n\u00e3o est\u00e1 definida.<\/li>\n
  • TZ – Esta vari\u00e1vel \u00e9 definida para indicar o fuso hor\u00e1rio atual se ele foi definido quando o daemon (servidor) foi iniciado (i.e. o daemon (servidor) passa o valor para novas conex\u00f5es).<\/li>\n
  • User – Definido para o nome do usu\u00e1rio logado.<\/li>\n<\/ul>\n

    Al\u00e9m disso, o SSH l\u00ea ~\/.ssh\/environment<\/em>, e adiciona linhas do formato “VARNAME = value” para o ambiente, se o arquivo existe, e os usu\u00e1rios t\u00eam permiss\u00e3o para mudar seu ambiente. Para mais informa\u00e7\u00f5es, consulte o PermitUserEnvironment<\/em> op\u00e7\u00e3o em “sshd_config(5)”.<\/p>\n

    Files<\/h1>\n
      \n
    • ~\/.rhosts<\/em> :: Este arquivo \u00e9 utilizado para autentifica\u00e7\u00e3o do host-based (veja acima). Em algumas m\u00e1quinas este arquivo pode precisar ser de leitura \u00e0 todos se o diret\u00f3rio home do usu\u00e1rio est\u00e1 em uma parti\u00e7\u00e3o NFS, porque “sshd(8)” o l\u00ea como root. Al\u00e9m disso, este arquivo deve ser de propriedade do usu\u00e1rio, e n\u00e3o deve ter permiss\u00f5es de grava\u00e7\u00e3o para ningu\u00e9m. A permiss\u00e3o recomendada para a maioria das m\u00e1quinas \u00e9 de leitura\/escrita para o usu\u00e1rio, e n\u00e3o acess\u00edveis por outros.<\/li>\n
    • ~\/.shosts<\/em> :: Este arquivo \u00e9 utilizado exatamente como “.rhosts”, mas permite a autentica\u00e7\u00e3o host-based sem permitir login com rlogin\/rsh.<\/li>\n
    • ~\/.ssh\/<\/em> :: Este diret\u00f3rio \u00e9 o local padr\u00e3o para todas as configura\u00e7\u00f5es espec\u00edficas do usu\u00e1rio e informa\u00e7\u00f5es de autentica\u00e7\u00e3o. N\u00e3o h\u00e1 nenhuma exig\u00eancia geral para manter todo o conte\u00fado do diret\u00f3rio em segredo, mas as permiss\u00f5es recomendadas s\u00e3o de leitura \/escrita\/execu\u00e7\u00e3o para o usu\u00e1rio, e n\u00e3o acess\u00edveis por outros.<\/li>\n
    • ~\/.ssh\/authorized_keys<\/em> :: Lista as chaves p\u00fablicas (RSA\/DSA) que podem ser usadas para fazer login como este usu\u00e1rio. O formato deste arquivo \u00e9 descrito na p\u00e1gina do manual do “sshd(8)”. Este arquivo n\u00e3o \u00e9 altamente sens\u00edvel, mas as permiss\u00f5es recomendadas s\u00e3o de leitura\/escrita para o usu\u00e1rio, e n\u00e3o acess\u00edveis por outros.<\/li>\n
    • ~\/.ssh\/config<\/em> :: Este \u00e9 o arquivo de configura\u00e7\u00e3o por usu\u00e1rio. O formato de arquivo e op\u00e7\u00f5es de configura\u00e7\u00e3o s\u00e3o descritas em “ssh_config(5)”. Devido ao potencial para o abuso, este arquivo deve ter permiss\u00f5es restritas: leitura\/escrita para o usu\u00e1rio, e n\u00e3o acess\u00edveis por outros. Ele pode ser de um grupo-grav\u00e1vel desde que o grupo em quest\u00e3o tenha apenas o utilizador.<\/li>\n
    • ~\/.ssh\/environment :: Cont\u00e9m defini\u00e7\u00f5es adicionais para vari\u00e1veis de ambiente; veja em AMBIENTE, acima.<\/li>\n
    • ~\/.ssh\/identity, ~\/.ssh\/id_dsa<\/em> e ~\/.ssh\/id_rsa<\/em> :: Cont\u00e9m a chave privada para autentica\u00e7\u00e3o. Esses arquivos cont\u00eam dados sens\u00edveis e devem ser leg\u00edveis pelo usu\u00e1rio mas n\u00e3o acess\u00edveis por outros (ler\/escrever\/executar). O SSH ir\u00e1 simplesmente ignorar um arquivo de chave privada se for acess\u00edvel por outros. \u00c9 poss\u00edvel especificar uma senha ao gerar a chave que ser\u00e1 usada para criptografar a parte sens\u00edvel deste arquivo utilizando 3DES.<\/li>\n
    • ~\/.ssh\/identity.pub, ~\/.ssh\/id_dsa.pub<\/em> e ~\/.ssh\/id_rsa.pub<\/em> :: Cont\u00e9m a chave p\u00fablica para autentica\u00e7\u00e3o. Esses arquivos n\u00e3o s\u00e3o sens\u00edveis e podem (mas n\u00e3o precisam) ser lidos por qualquer pessoa.<\/li>\n
    • ~\/.ssh\/known_hosts<\/em> :: Cont\u00e9m uma lista de chaves host para todos os hosts do usu\u00e1rio conectados que ainda n\u00e3o est\u00e3o na lista de todo o sistema de chaves host conhecidos. Veja sshd(8) para mais detalhes sobre o formato deste arquivo.<\/li>\n
    • ~\/.ssh\/rc<\/em> :: Comandos deste arquivo s\u00e3o executados por ssh quando o usu\u00e1rio faz login, pouco antes do shell do usu\u00e1rio (ou comando) \u00e9 iniciado. Veja a p\u00e1gina de manual do sshd(8) para mais informa\u00e7\u00f5es.<\/li>\n
    • \/etc\/hosts.equiv<\/em> :: Este arquivo \u00e9 para autentifica\u00e7\u00e3o do host-based (veja acima). Ele s\u00f3 deve ser escrito pelo root.<\/li>\n
    • \/etc\/ssh\/shosts.equiv<\/em> :: Este arquivo \u00e9 utilizado da mesma maneira como o hosts.equiv, mas permite a autentica\u00e7\u00e3o host-based sem permitir login com rlogin\/rsh.<\/li>\n
    • \/etc\/ssh\/ssh_config<\/em> :: Arquivo de configura\u00e7\u00e3o Systemwide. O formato de arquivo e op\u00e7\u00f5es de configura\u00e7\u00e3o s\u00e3o descritas em ssh_config (5).<\/li>\n
    • \/etc\/ssh\/ssh_host_key, \/etc\/ssh\/ssh_host_dsa_key<\/em> e \/etc\/ssh\/ssh_host_rsa_key<\/em> :: Estes tr\u00eas arquivos cont\u00eam as partes privadas das chaves host e s\u00e3o usados para a autentifica\u00e7\u00e3o do host-based. Se a vers\u00e3o do protocolo 1 \u00e9 usado, ssh deve ser setuid root, j\u00e1 que a chave do anfitri\u00e3o \u00e9 leg\u00edvel apenas pelo root. Para o protocolo vers\u00e3o 2, ssh usa ssh-keysign(8) para acessar as chaves host, eliminando a exig\u00eancia do ssh ser setuid root quando o login \u00e9 baseado em host de autentica\u00e7\u00e3o. Por padr\u00e3o o ssh n\u00e3o \u00e9 setuid root.<\/li>\n
    • \/etc\/ssh\/ssh_known_hosts<\/em> :: Systemwide lista de chaves host conhecidas. Este arquivo deve ser preparado pelo administrador do sistema para conter as chaves host p\u00fablicas de todas as m\u00e1quinas da organiza\u00e7\u00e3o. Deve ser lido\/vis\u00edvel por todos. Veja sshd (8) para mais detalhes sobre o formato deste arquivo.<\/li>\n
    • \/etc\/ssh\/sshrc<\/em> :: Comandos deste arquivo s\u00e3o executados por ssh quando o usu\u00e1rio faz login, pouco antes que o shell do usu\u00e1rio (ou comando) \u00e9 iniciado. Veja a p\u00e1gina de manual do sshd (8) para mais informa\u00e7\u00f5es.<\/li>\n<\/ul>\n

      Veja tamb\u00e9m<\/h1>\n
        \n
      • scp(1),sftp(1),ssh-add(1),ssh-agent(1),ssh-argv0(1),ssh-keygen(1), ssh-keyscan(1),ssh-vulnkey(1),tun(4),hosts.equiv(5),ssh_config(5), ssh-keysign(8),sshd(8)<\/li>\n
      • The Secure Shell (SSH) Protocol Assigned Numbers, RFC 4250, 2006.<\/li>\n
      • The Secure Shell (SSH) Protocol Architecture, RFC 4251, 2006.<\/li>\n
      • The Secure Shell (SSH) Authentication Protocol, RFC 4252, 2006.<\/li>\n
      • The Secure Shell (SSH) Transport Layer Protocol, RFC 4253, 2006.<\/li>\n
      • The Secure Shell (SSH) Connection Protocol, RFC 4254, 2006.<\/li>\n
      • Using DNS to Securely Publish Secure Shell (SSH) Key Fingerprints, RFC 4255, 2006.<\/li>\n
      • Generic Message Exchange Authentication for the Secure Shell Protocol (SSH), RFC 4256, 2006.<\/li>\n
      • The Secure Shell (SSH) Session Channel Break Extension, RFC 4335, 2006.<\/li>\n
      • The Secure Shell (SSH) Transport Layer Encryption Modes, RFC 4344, 2006.<\/li>\n
      • Improved Arcfour Modes for the Secure Shell (SSH) Transport Layer Protocol, RFC 4345, 2006.<\/li>\n
      • Diffie-Hellman Group Exchange for the Secure Shell (SSH) Transport Layer Protocol, RFC 4419, 2006.<\/li>\n
      • The Secure Shell (SSH) Public Key File Format, RFC 4716, 2006.<\/li>\n
      • A. Perrig and D. Song, Hash Visualization: a New Technique to improve Real-World Security, 1999, International Workshop on Cryptographic Techniques and E-Commerce (CrypTEC ’99).<\/li>\n<\/ul>\n<\/div>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n","protected":false},"excerpt":{"rendered":"

        Sinopse \/ Descri\u00e7\u00e3o Nome: SSH – Cliente OpenSSH SSH (programa de login remoto) Sinopse: ssh [ -1246AaCfgKkMNnqsTtVvXxYy ] [ -b bind_address ][ -c cipher_spec ] [ -D [bind_address:]port][ -e escape_char ][ -F configfile ][ -i identity_file ] [ -L [bind_address:]port:host:hostport][ -l login_name ][ -m mac_spec ] [ -O ctl_cmd ][ -o option ][ -p port […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"site-sidebar-layout":"default","site-content-layout":"","ast-site-content-layout":"default","site-content-style":"default","site-sidebar-style":"default","ast-global-header-display":"","ast-banner-title-visibility":"","ast-main-header-display":"","ast-hfb-above-header-display":"","ast-hfb-below-header-display":"","ast-hfb-mobile-header-display":"","site-post-title":"","ast-breadcrumbs-content":"","ast-featured-img":"","footer-sml-layout":"","ast-disable-related-posts":"","theme-transparent-header-meta":"","adv-header-id-meta":"","stick-header-meta":"","header-above-stick-meta":"","header-main-stick-meta":"","header-below-stick-meta":"","astra-migrate-meta-layouts":"default","ast-page-background-enabled":"default","ast-page-background-meta":{"desktop":{"background-color":"var(--ast-global-color-4)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"tablet":{"background-color":"","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"mobile":{"background-color":"","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""}},"ast-content-background-meta":{"desktop":{"background-color":"var(--ast-global-color-5)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"tablet":{"background-color":"var(--ast-global-color-5)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"mobile":{"background-color":"var(--ast-global-color-5)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""}},"footnotes":""},"categories":[1,42,51],"tags":[60,234,64,204],"class_list":["post-421","post","type-post","status-publish","format-standard","hentry","category-viazap","category-leitura-recomendada","category-linux-linuxrs","tag-comandos","tag-man","tag-shell","tag-ssh"],"_links":{"self":[{"href":"https:\/\/blog.clusterweb.com.br\/index.php?rest_route=\/wp\/v2\/posts\/421","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/blog.clusterweb.com.br\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blog.clusterweb.com.br\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blog.clusterweb.com.br\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/blog.clusterweb.com.br\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=421"}],"version-history":[{"count":1,"href":"https:\/\/blog.clusterweb.com.br\/index.php?rest_route=\/wp\/v2\/posts\/421\/revisions"}],"predecessor-version":[{"id":422,"href":"https:\/\/blog.clusterweb.com.br\/index.php?rest_route=\/wp\/v2\/posts\/421\/revisions\/422"}],"wp:attachment":[{"href":"https:\/\/blog.clusterweb.com.br\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=421"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blog.clusterweb.com.br\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=421"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blog.clusterweb.com.br\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=421"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}