mar 222018
 

Olá!

Aqui, você verá uma forma simples de “criptografar” um Shell Script que você quer passar a alguém, mas não quer liberar o fonte ou que seja editável por qualquer um.

BÁSICO DE CRIPTOGRAFIA

Bom, um conceito básico sobre criptografia:

Criptografia (do Grego kryptós, “escondido”, e gráphein, “escrita”) é o estudo dos princípios e técnicas pelas quais a informação pode ser transformada da sua forma original para outra ilegível.

Mais sobre isso: Criptografia – Wikipédia, a enciclopédia livre
Continue reading »

set 042017
 

Uma das minhas paixões por Linux surgiu justamente quando eu comecei a criar os meus primeiros scripts utilizando shell. Quando eu percebi a quantidade de coisas que era possível fazer com scripts, minha mente fervilhou e eu passei a fazer dezenas de scripts para automatizar tudo que eu fazia manualmente até então.

Ao final deste artigo você saberá:

  • O que é shell script;
  • Boas práticas de programação utilizando shell script;
  • Erros de iniciantes em shell script;

É claro que meus primeiros scripts eram bem toscos, mas isso eu só notei quando os revisitei depois de um certo tempo, como eu não tinha referência de comparação, para mim estava maravilhoso.
E é justamente sobre isso que pretendo compartilhar com você neste artigo, dicas para você iniciar a criação dos seus scripts de forma mais inteligente e eficaz.

Continue reading »

set 042017
 

Neste texto, vou ensinar a baixar, instalar e usar SHC, um programa que encripta o código do seus shell scritps.
Antes de mais nada, eu gostaria de dizer que encriptar seus códigos não é uma prática recomendável. O ideal é documentar todo o script, de forma que qualquer pessoa o possa entender facilmente. Códigos fonte devem ser o mais acessíveis possível – já a informação com a qual eles lidam, é que deve ser restringida.
Se você precisa usar informações, usualmente confidenciais, como senhas, de forma automática, então deve procurar outra solução.
Hmmmm… você ainda está aqui?
Tenha em mente, contudo, que um script codificado através do SHC pode não ser legível para usuários comuns (creio que este seja o seu objetivo) — Contudo, uma pessoa que tenha conhecimento do seu funcionamento pode extrair o código criado pelo software.
Em tempo, SHC quer dizer SHell script Compiler.

Continue reading »

Shell Script para WEB

 Clusterweb, Leitura Recomendada, Shell Script  Comentários desativados em Shell Script para WEB
abr 102014
 

 

Iniciando / Variáveis de ambiente

Iniciando

Nas configurações padrões do Apache, existe um diretório já pré-definido para scripts CGI rodarem. É o /usr/lib/cgi-bin/.

Irei criar um arquivo com o nome tutorial.sh. Nos scripts CGI, a saída dos scripts (/dev/stdout e /dev/stderr), são enviadas para o cliente, as primeiras linhas do script serão o cabeçalho de resposta da requisição HTTP.

Desse modo, podemos forçar o download de arquivos, fazer redirecionamentos, etc, a quebra de linha é que separa o que será o cabeçalho e o que será o resto da resposta.

Voltando ao arquivo tutorial.sh, dentro do arquivo, coloque as seguintes linhas:

#!/bin/bash
echo -e “Content-Type: text/plain\n”    # É o Cabeçalho, e a quebra de linha
echo “Hello World”    # Agora é o resto do request, o conteúdo que é exibido pelos navegadores.

Salve o arquivo e deixe as permissões como 775 (lembrando: r = 4, w = 2, x = 1).

Acesse o link: http://localhost/cgi-bin/tutorial.sh E verá a mensagem: Hello World

Por padrão, o Apache já configura o cabeçalho de resposta.

Se não quiser, você pode pôr no começo do script: echo -e “\n” ou printf “\n\n”, e deixar que o Apache configure o cabeçalho, que normalmente, será algo parecido com isso:  Continue reading »

Introdução ao Shell Script – Baseado no livro de Ken O. Burtch

 Clusterweb, Leitura Recomendada  Comentários desativados em Introdução ao Shell Script – Baseado no livro de Ken O. Burtch
dez 222013
 
Introdução

Este artigo foi elaborado tendo como base, o livro Scripts de Shell Linux com Bash, do autor Ken O. Burtch, livro no qual eu estudei Shell Script e fiz um resumo pessoal. Deste resumo, resolvi redigir um texto ensinando como trabalhar com essa linguagem.

Esse artigo contém os seguintes tópicos:

  • Conceitos Iniciais,
  • Comando printf,
  • Códigos de Formatação,
  • Declaração de Variáveis,
  • Atributos de Variáveis,
  • Como Ler do Teclado,
  • Expressões aritméticas,
  • Comando if, Comando test,
  • Comparar Inteiro,
  • Laço for,
  • Funções de Shell,
  • Script Bem Comportado,
  • Declarações Globais,
  • Verificação de Sanidade,
  • Limpeza.

E, também, contém exercícios com respostas que eu elaborei para fixar melhor o conteúdo, já que o livro não traz exercícios. Com esse artigo, pretendo ajudar aqueles que desejam começar os estudos dessa linguagem e também, iniciando minhas contribuições com a comunidade.

Quando iniciei os estudos, percebi que havia muitas dúvidas referentes ao fato da linguagem Shell Script ser uma linguagem de programação ou, simplesmente, ser uma linguagem de comando.

Então, a primeira questão a ser pensada, é: o que caracteriza uma linguagem de programação?

Ela é caracterizada por ter estruturas condicionais, laços de repetição, a possibilidade de modularização, entre outras. Como a linguagem Shell Script tem essas características, ela pode ser considerada uma linguagem de programação.

Essa linguagem é utilizada para a construção de pequenas rotinas, como o seu próprio nome já diz, pois, apesar de não ter uma definição precisa do que seja Script, pode-se dizer que é um pequeno programa. É uma linguagem interpretada.

Para fins didáticos, é interessante o leitor ir testando os comandos à medida em que lê o texto, e os exercícios auxiliarão na fixação do conteúdo. Você pode testar os códigos direto do terminal, ou pode utilizar sites que tem o interpretador de shell.

Eu testei dois, que foram:

Os dois são muito bons.  Continue reading »

Como gerenciar usuários e grupos

 Clusterweb, Leitura Recomendada, Linux, Segurança  Comentários desativados em Como gerenciar usuários e grupos
set 232013
 
Gerenciamento

Como qualquer sistema operacional multitarefa e multiusuário, o administrador do sistema tem como grande desafio o gerenciamento de usuários e grupos. Por este motivo é importante estarmos preparados para administrá-los diretamente sem a utilização de ferramentas que facilitem isso (ex.: webmin), usando apenas os comandos básicos do sistema operacional, isso irá proporcionar a administração em qualquer distribuição.Comandos:

  • useradd: Comando utilizado para criação de um usuário.
  • userdel: Comando utilizado para remoção de um usuário.
  • usermod: Comando usado para modificar os dados de um usuário.
  • passwd: Comando usado para definir e ou modificar a senha de um usuário.
  • groupadd: Comando usado para criar um grupo.
  • groupdel: Comando usado para remover um grupo.
  • groupmod: Comando usado para modificar os dados de um grupo.

Criando um usuário

Para que seja possível logar no sistema o usuário deverá ter um username (login) e uma senha (password). Para que isso seja possível usaremos os comandos “useradd” e “passwd”. Abaixo explicarei como é a sintaxe dos comandos e suas opções: Continue reading »

SSH – Tradução da man page

 Clusterweb, Leitura Recomendada, Linux  Comentários desativados em SSH – Tradução da man page
mar 082013
 
Sinopse / Descrição

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 ][ -R [bind_address:]port:host:hostport]
[ -S ctl_path ][ -w local_tun [:remote_tun]] [user@]hostname [ command ]

Descrição:

O SSH (cliente SSH) é um programa para conectar-se e executar comandos em máquina remota. É proposital substituir o “rlogin” e o “rsh” e prover comunicações criptografadas de forma segura entre dois hosts não confiáveis sobre uma rede não segura. As conexões X11 e portas TCP arbitrárias, também podem ser encaminhadas através do canal seguro.

O SSH conecta-se e faz o login em um hostname específico (com nome de usuário opcional). O usuário deve provar sua identidade à máquina remota usando um dos vários métodos, dependendo da versão usada do protocolo (veja abaixo).

Se o comando é especificado, ele é executado em um host remoto ao invés de um acesso shell.

As opções estão a seguir:

-1 :: Obriga o SSH a tentar somente a versão 1 do protocolo;

-2 :: Obriga o SSH a tentar somente a versão 2 do protocolo;

-4 :: Obriga o SSH a usar somente endereços IPv4;

-6 :: Obriga o SSH a usar somente endereços IPv6;

-A :: Ativa o encaminhamento de uma conexão de autenticação de agente. Isto também pode ser especificado numa base por host em um arquivo de configuração.

O agente encaminhado deve ser ativado com cuidado. Usuários com a habilidade de ignorar arquivos de permissões em um host remoto (para o socket Unix-domain do agente) podem acessar o agente local pela conexão encaminhada.

Um atacante não pode obter material chave de um agente, porém, ele pode executar operações nas chaves que permite sua autenticação usando identidades carregadas no agente.

-a :: Desativa o encaminhamento da conexão da autenticação do agente;

-b bind_address :: Usa bind_address na máquina local como o endereço origem da conexão. É útil somente em sistemas com mais de um endereço.

-C :: Requer compressão de todos os dados (incluindo stdin, stdout, stderr, e dados encaminhados via X11 e conexões TCP). O algoritmo de compressão é o mesmo usado pelo gzip(1), e o “nível” pode ser controlado pela opção “CompressionLevel” da versão 1 do protocolo.

A compressão é desejada em linhas de modem e outras conexões mais lentas, mas irá somente diminuir as coisas em conexões rápidas. O valor padrão pode ser definido em uma base host-para-host nos arquivos de configuração.

Veja a opção compressão:

-c cipher_spec :: Seleciona a especificação de cifra para criptografar a sessão. A versão 1 do protocolo permite a especificação de uma cifra única.

Os valores suportados são “3des”, “blowfish”, e “des”:

  • O “3des” (triplo-des) é uma tripla (encripta-decripta-encripta) com três diferentes chaves. Acredita-se que seja seguro.
  • O “blowfish” é uma cifra de bloco rápida, parece ser muito seguro e bem mais rápido que o 3des.
  • O “des” é suportado somente no cliente ssh para interoperabilidade com a implementação do protocolo 1 que não suporta a cifra 3des. Seu uso é fortemente desencorajado devido às deficiências criptográficas. O padrão é o “3des”.

Para a versão 2 do protocolo, cipher_spec é uma lista de cifras separadas por vírgula listadas em ordem de preferência. Veja a palavra-chave “Ciphers” para mais informações.

-D [bind_address:]porta :: Especifica um encaminhamento de uma porta de nível de aplicação local “dinâmica”. Funciona alocando um socket para escutar a porta no lado local, opcionalmente limitado pelo específico “bind_address”.

Quando uma conexão é feita nessa porta ela é encaminhada sobre o canal seguro, e o protocolo da aplicação é depois usado para determinar onde se conectar na máquina remota.

Atualmente os protocolos SOCKS4 e SOCKS5 são suportados, e o SSH irá atuar como um servidor SOCKS. Somente o usuário root pode encaminhar portas privilegiadas. Encaminhamentos dinâmicos de portas podem ser especificados no arquivo de configuração.

Endereços IPv6 podem ser especificados com uma sintaxe alternativa:

[ bind_address/]porta

Ou colocando o endereço entre chaves. Somente o superusuário pode encaminhar portas privilegiadas. Por padrão a porta local é limitada de acordo com a configuração do GatewayPorts. Porém um “bind_address” explícito pode ser usado para ligar a conexão com o endereço específico.

O “bin_address” de “localhost” indica que a porta escutada pode ser limitada somente para o usuário local, enquanto um endereço vazio, ou ‘*’, indica que a porta deve estar disponível para todas as interfaces.

-e escape_char :: Define o caractere de escape para sessões com tty (default: “~”). O caractere de escape é somente reorganizado no começo de uma linha. Se o caractere de escape for seguido por um ponto (‘.’) fecha a conexão; seguido por Ctrl-Z suspende a conexão; 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ão completamente transparente.

-F configfile :: Especifica um arquivo de configuração alternativo por usuário. Se um arquivo de configuração é passado por linha de comando, o arquivo de configuração de todo o sistema (/etc/ssh/ssh_config) será ignorado. O padrão para um arquivo de configuração por usuário é: ~/.ssh/config.

-f :: Pede para o SSH ir para background antes da execução do comando. É útil se o SSH vai perguntar por senhas ou frases secretas, mas o usuário o quer em background. Isto implica em “-n”. O modo recomendado para iniciar programas X11 em um site remoto é com alguma coisa do tipo: ssh -f host xterm.

Se a opção de configuração “ExitOnForwardFailure” for definida como “yes”, logo, um cliente iniciado com “-f” irá esperar por todos os encaminhamentos das portas remotas serem estabelecidas com sucesso antes de colocarem a si mesmos em background.

-g :: Permite hosts remotos conectarem-se à portas de encaminhamento locais.

-I smartcard_device :: Especifica o dispositivo que SSH deve usar para se comunicar com um smartcard usado para guardar a chave privada RSA dos usuários. Esta opção está disponível apenas se o suporte para dispositivos smartcards forem compilados (padrão não é suportado).

-i identity_file :: Seleciona um arquivo de onde cada identidade (chave privada) para autenticações RSA ou DAS são lidas. O padrão é ~/.ssh/identity para a versão 1 do protocolo, e ~/.ssh/id_rsa e ~/.ssh/id_dsa para a versão 2 do protocolo.

Arquivos de identidade devem ser especificados em uma base por host em um arquivo de configuração. É possível ter múltiplas opções “-i” (e múltiplas identidades especificadas em um arquivo de configuração).

-K :: Ativa a autenticação GSSAPI e encaminha (delegação) das credenciais GSSAPI para o servidor.

-k :: Desativa o encaminhamento (delegação) das credenciais GSSAPI para o servidor.

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

Isso funciona basicamente alocando-se um socket para escutar uma porta no lado local, opcionalmente ligada ao “bind_address”. Sempre que uma conexão é feita nessa porta, a conexão é encaminhada sobre o canal seguro, e a conexão é feita na porta do host (host port) da máquina remota.

Encaminhamentos de portas podem ser especificados em um arquivo de configuração. Endereços IPv6 podem ser especificados com uma sintaxe alternativa:

[ bind_address/]port/host/hostport

Ou, colocando o endereço entre chaves. Somente o superusuário pode encaminhar portas privilegiadas. Por padrão, a porta local é ligada de acordo com a configuração GatewayPorts. Porém, um “bind_address” explícito pode se usado para ligar a conexão a um endereço específico.

O “bind_address” de um “localhost” indica que a porta que escuta seja ligada somente para o usuário local, enquanto um endereço vazio, ou ‘*’, indica que a porta deve estar disponível para todas as interfaces.

-l login_name :: Especifica o usuário a logar na máquina remota. Isto também pode ser especificado em uma base por host em um arquivo de configuração.

-M :: Coloca o cliente SSH no modo “master” para compartilhamento de conexão. Múltiplas opções “-M” coloca o SSH no modo “master” com confirmação necessária antes que conexões escravas sejam aceitas. Veja a descrição do ControlMaster em “ssh_config(5)” para mais detalhes.

-m mac_spec :: Adicionalmente, para o protocolo versão 2, uma lista de algoritmos MAC (código de autenticação de mensagem) separada por vírgulas pode ser especificada em ordem de preferência. Veja a palavra chave MAC para mais informações.

-N :: Não executa um comando remoto. Pode ser útil apenas para portas de encaminhamento (apenas protocolo versão 2).

-n :: Redireciona a saída “stdin” para /dev/null (na verdade, previne a leitura do “stdin”). Deve ser usado quando o SSH roda em background. Um truque comum é usar isso para executar programas X11 em uma máquina remota. Por exemplo:

$ ssh -n shadows.cs.hut.fi emacs &

Irá iniciar um Emacs em shadows.cs.hut.fi, e a conexão X11 será automaticamente encaminhada sobre um canal criptografado. O programa SSH irá ser colocado em background (isso não funciona se o SSH precisar perguntar por uma senha ou frase secreta. Veja também a opção: -f).

-O ctl_cmd :: Controla uma conexão ativa multiplexando processos mestre. Quando a opção “-O” é especificada, o argumento “ctl_cmd” é interpretado e passado para o processo mestre. Os comandos válidos são:

  • check :: Checa se o processo mestre está executando;
  • exit :: Solicita o mestre para sair.

-o option :: Pode ser usado para fornecer opções no formato usado no arquivo de configuração. Isto é útil para especificar opções que não são separadas por uma flag de linha de comando.

Para detalhes completos das opções listadas abaixo, e seus possíveis valores, veja o “ssh_config(5)”:

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

-p porta :: Porta para conectar no host remoto. Isto pode ser especificado em uma base por host no arquivo de configuração.

-q :: Modo quieto. Faz com que a maioria das mensagens de aviso e diagnóstico sejam suprimidas. Apenas erros fatais são exibidos. Se um segundo “-q” é dado, então, mesmo erros fatais são suprimidos, exceto aqueles produzidos por argumentos errados.

-R [endereço_de_ligação:]porta:host:porta_do_host :: Especifica que a dada porta no host (servidor) remoto será direcionada para o host e porta dados no lado no local.

Isto funciona por meio de uma alocação de socket para escutar a porta no lado remoto, e quando a conexão é feita nesta porta, a conexão é direcionada sobre um canal seguro, e uma conexão é feita para host na porta “porta_do_host” da máquina local.

Direcionamento de portas pode também ser especificado no arquivo de configuração. Portas privilegiadas só podem ser direcionadas quando estiver logado como root na máquina remota. Endereços IPv6 podem ser especificados por meio de uma inclusão do endereço entre colchetes ou usando uma sintaxe alternativa:

[bind_address/]host/port/hostport

Por padrão o socket que está escutando no servidor será ligado para a interface de loopback somente. Isto pode ser sobrescrito especificando um endereço_de_ligação. Um endereço_de_ligação vazio, ou o endereço ‘*’, indica que o socket remoto deve escutar em todas as interfaces. Especificando um endereço_de_ligação remoto só irá ter sucesso se a opção GatewayPorts do servidor estiver habilitada (veja: ssh_config(5) ).

Se o argumento porta for ‘0’, a porta de escuta será dinamicamente alocada no servidor e reportada para o cliente em tempo de execução. Quando usado junto com “-O forward”, a porta alocada será impressa na saída padrão.

-S caminho_ctl :: Especifica a localização de um socket de controle para compartilhamento de conexão, ou a cadeia “none” para desabilitar o compartilhamento de conexão. Consulte a descrição de ControlPath e ControlMaster em ssh_config(5) para mais detalhes.

-s :: Pode ser usado para requisitar uma invocação de um subsistema no sistema remoto. Subsistemas são uma característica do protocolo SSH2 o qual facilita o uso do SSH como um transporte seguro para outras aplicações (ex.: sftp(1)). O subsistema é especificado como o comando remoto.

-T :: Desativa a alocação de pseudo-tty.

-t :: Força a alocação pseudo-tty. Isto pode ser usado para executar programas arbitrários baseados em tela em uma máquina remota, o qual pode ser muito útil, por exemplo, quando estiver implementando serviços de menu. Múltiplas opções “-t” forçam a alocação tty, mesmo se o SSH não tem um tty local.

-V :: Mostra o número da versão e sai.

-v :: Modo de detalhe. Faz o SSH imprimir mensagens de depuração sobre o seu progresso. Isto é útil para depurar problemas de conexão, autenticação e configuração. Múltiplas opções “-v” aumentam o detalhamento. O máximo é 3.

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

Os dispositivos podem ser especificados por ID numérico ou pela palavra-chave “any” (qualquer), que faz utilizar o próximo dispositivo de encapsulamento disponível.

Se “remote_tun” não for especificado, “any” é utilizado por padrão. Veja também as diretivas Tunnel e TunnelDevice em ssh_config(5). Se a diretiva Tunnel estiver indefinida, será definido o modo de encapsulamento padrão, que é “point-to-point” (ponto-a-ponto).

-X :: Habilita o encaminhamento de X11. Isto pode ser especificado por host no arquivo de configuração.

O encaminhamento de X11 deve ser habilitado com cuidado. Usuários com a habilidade de contornar permissões de arquivos no host remoto (para o banco de dados de autorização X do usuário) podem acessar o display X11 local através da conexão encaminhada.

Uma pessoa pode atacar e conseguir fazer atividades como monitoramento de teclas pressionadas. Por esta razão, o encaminhamento X11 está sujeito, por padrão, à extensão de restrições X11 SECURITY (segurança).

Por favor, refira-se à opção “-Y” do SSH e a diretiva ForwardX11Trusted no “ssh_config(5)” para mais informações.

-x :: Desativa o encaminho de X11.

-Y :: Habilita o encaminhamento confiável de X11. O encaminhamento confiável de X11 não está sujeito aos controles de extensão X11 SECURITY.

-y :: Envia informações do log utilizando o módulo de sistema syslog(3). Por padrão, esta informação é enviada para stderr.

O SSH, adicionalmente, poderá obter dados de configuração de um arquivo de configuração por usuário e um arquivo abrangente do sistema. O formato do arquivo e as opções de configuração, são descritos em “ssh_config(5)”.

O SSH sai com o status de saída do comando remoto, ou com 255, se um erro ocorrer.

Autenticação

O cliente SSH do OpenSSH suporta os protocolos SSH 1 e 2. O protocolo 2 é o padrão, com SSH voltando para o protocolo 1 se detectar que o protocolo 2 não é suportado. Estas configurações podem ser alteradas usando a opção Protocol em “ssh_config(5)”, ou impostas usando as opções “-1” e “-2” (veja acima).

Ambos os protocolos suportam métodos semelhantes de autenticação, mas o protocolo 2 é preferível, pois proporciona mecanismos adicionais de confidencialidade (o tráfego é 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ão.

Os métodos disponíveis para autenticação são:

  • Autenticação baseada em GSSAPI;
  • Autenticação baseada em host;
  • Autenticação por chave pública;
  • Autenticação desafio-resposta;
  • Autenticação por password.

Métodos de autenticação são tentados na ordem especificada acima, embora o protocolo 2 tenha uma opção de configuração para mudar a ordem padrão: “PreferredAuthentications”.

A autenticação baseada em host funciona da seguinte maneira. Se a máquina que o usuário logar estiver listada em /etc/hosts.equiv ou /etc/ssh/shosts.equiv na máquina remota, e o nome dos usuários é o mesmo em ambos os lados, ou, se os arquivos ~/.rhosts ou ~/.shosts existirem no diretório HOME do usuário na máquina remota e conter uma linha contendo o nome da máquina cliente e o nome do usuário naquela máquina, o usuário é considerado para logar.

Adicionalmente o servidor precisa ser capaz de verificar a chave de host do cliente (veja a descrição de /etc/ssh/ssh_known_hosts e ~/.ssh/known_hosts, abaixo) para o login ser permitido.

Este método de autenticação fecha buracos na segurança devido ao IP spoofing, DNS spoofing, e spoofing de roteamento.

** Nota para o administrador: /etc/hosts.equiv, ~/.rhosts e o protocolo rlogin/rsh, em geral, são inerentemente inseguros e devem ser desativados se a segurança é desejada.

A autenticação por chave pública funciona da seguinte maneira: O esquema é baseado na criptografia de chave-pública, usando criptosistemas onde a encriptação e decriptação são feitas usando chaves separadas, e é inviável derivar a chave de decriptação através da chave de encriptação.

A ideia é que cada usuário crie um par de chaves pública/privada para o propósito de autenticação. O servidor conhece a chave pública, e somente o usuário conhece a chave privada. O SSH implementa o protocolo de autenticação por chave pública automaticamente, usando o algoritmo RSA ou DAS.

O protocolo 1 é restringido a usar somente chaves RSA, mas o protocol 2 pode usar qualquer um. A seção HISTORY de “ssl(8)” (em sistemas não-OpenBSD, veja em HISTORY) contém uma breve discussão dos dois algoritmos.

O arquivo ~/.ssh/authorized_keys lista as chaves públicas que são permitidas para efetuar logon. Quando o usuário loga, o programa SSH diz ao servidor qual par de chaves gostaria de usar para a autenticação. O cliente prova que tem acesso à chave privada e o servidor checa que a chave pública correspondente está autorizada a aceitar a conta.

O usuário cria seu par de chaves executando ssh-keygen(1). Isto armazena a chave privada em ~/.ssh/identity (protocolo 1), ~/.ssh/id_dsa (protocolo 2 DSA), ou ~/.ssh/id_rsa (protocolo 2 RSA) e armazena a chave pública em ~/.ssh/identity.pub (protocolo 1), ~/.ssh/id_dsa.pub (protocolo 2 DSA), ou ~/.ssh/id_rsa.pub (protocolo 2 RSA) no diretório HOME do usuário.

O usuário deve, então, copiar a chave pública para ~/.ssh/authorized_keys em seu diretório HOME na máquina remota. O arquivo “authorized_keys” corresponde ao arquivo ~/.rhosts convencional, e tem uma chave por linha, embora as linhas podem ser muito longas. Depois disto, o usuário pode efetuar logon sem dar o password.

A maneira mais conveniente de usar autenticação por chave pública pode ser com um agente de autenticação. Veja “ssh-agent(1)” para mais informações.

A autenticação desafio-resposta funciona da seguinte maneira. O servidor envia um “desafio” arbitrário em texto, e espera por uma resposta. O protocolo 2 permite múltiplos desafios e respostas; o protocolo 1 é restrito a apenas um desafio/resposta. Exemplos de autenticação desafio-resposta incluem autenticação BSD (veja login.conf(5)) e PAM (para alguns sistemas não-OpenBSD).

Finalmente, se outros métodos de autenticação falharem, o SSH pede uma senha para o usuário. A senha é enviada para o host remoto para ser checada; entretanto, já que todas as comunicações são encriptadas, a senha não pode ser vista por alguém que esteja escutando a rede.

O SSH, automaticamente, mantém e checa um banco de dados contendo uma identificação de todos os hosts com que ele já foi usado. As chaves do host são armazenadas em ~/.ssh/known_hosts no diretório HOME do usuário.

Adicionalmente, o arquivo /etc/ssh/ssh_known_hosts é automaticamente checado para hosts conhecidos. Quaisquer novos hosts são automaticamente adicionados ao arquivo do usuário. Se a identificação de um host mudar, o SSH alerta sobre isto e desativa a autenticação por senha para prevenir ataques de spoof de servidor ou man-in-the-middle, que poderiam caso contrário ser usados para circundar a encriptação.

A opção StrictHostKeyChecking pode ser usada para controlar logins em máquinas cuja chave hospedeira não é conhecida ou tenha mudado.

Quando a identidade do usuário for aceita pelo servidor, ou o servidor executa o comando dado, ou loga na máquina e dá ao usuário um shell normal na máquina remota, todas as comunicações com o comando remoto ou shell vão ser automaticamente encriptados.

Se um pseudo-terminal foi alocado (sessão normal de login), o usuário poderá usar os caracteres de escape escritos abaixo.

Se nenhum pseudo-tty foi alocado, a sessão é transparente e pode ser usada para transferir dados binários confiavelmente. Na maioria dos sistemas, definindo o caractere de escape para “none”, também fará a sessão ser transparente mesmo se um tty for utilizado.

A sessão finaliza quando o comando, ou shell na máquina remota, sai e todas conexões X11 e TCP são fechadas.

Caracteres / Encaminhamento / Chaves de host

Caracteres de escape

Quando um pseudo-terminal for requisitado, o SSH suporta um número de funções através do uso de um caractere de escape.

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

O caractere de escape pode ser trocado nos arquivos de configuração usando a diretiva de configuração EscapeChar ou na linha de comando pela opção “-e”.

Os escapes suportados (assumindo o padrão ‘-‘) são:

  • -. :: Desconectar.
  • -^Z :: SSH em background.
  • -# :: Listar as conexões encaminhadas.
  • -& :: Coloca o SSH em background no logout quando estiver esperando conexões encaminhadas/ sessões X11 terminarem.
  • -? :: Mostra uma lista de caracteres de escape.
  • -B :: Envia um BREAK para o sistema remoto (só é útil para o procotolo SSH versão 2 e se o par suportar).
  • -C :: Abre a linha de comando. Atualmente, isto permite a adição de encaminhamento de portas usando as opções “-L”, “-R” e “-D” (veja acima). Também permite o cancelamento de encaminhamentos de porta remotos existentes usando “-KR[endereço_de_ligação:]porta”.
  • !command :: Permite o usuário executar um comando local se a opção PermitLocalCommand estiver habilitada em “ssh_config(5)”. Uma ajuda básica está disponível, usando a opção “-h”.
  • -R :: Requisita o rechaveamento da conexão (só é útil para o protocolo SSH versão 2 e se o par suportar).

Encaminhamento TCP

O encaminhamento de conexões TCP arbitrárias, sobre o canal seguro, podem ser especificadas ou na linha de comando ou no arquivo de configuração. Uma possível aplicação para o encaminhamento TCP é uma conexão segura para um servidor de correio eletrônico; outra é ir através de firewalls.

No exemplo abaixo deparamos com a encriptação da comunicação entre um cliente e servidor IRC, mesmo que o servidor IRC não suporte comunicações encriptadas diretamente.

Isto funciona da seguinte maneira. O usuário conecta no host remoto usando SSH, especificando uma porta para ser usada para encaminhar conexões para o servidor remoto. Depois disso pode-se iniciar o serviço o qual será encriptado na máquina cliente, conectando na mesma porta local, e o SSH irá encriptar e encaminhar a conexão.

O exemplo a seguir encapsula uma sessão IRC da máquina cliente “127.0.0.1” (localhost) para o servidor remoto “server.example.com”:

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

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

A opção “-f” faz o SSH ficar em background e o comando remoto “sleep 10” é especificado para permitir uma quantidade de tempo (10 segundos, no exemplo) para iniciar o serviço que irá ser encapsulado. Se nenhuma conexão for feita no tempo especificado, o SSH sairá.

Encaminhamento X11

Se a variável ForwardX11 estiver definida como “yes” (ou veja acima a descrição das opções “-X”, “-x”, e “-Y”) e o usuário estiver usando X11 (a variável de ambiente DISPLAY está definida), a conexão para o display X11 é automaticamente encaminhada para o lado remoto, de tal maneira que, quaisquer programas X11 iniciados pelo shell (ou comando) irão através do canal encriptado, e a conexão para o verdadeiro servidor X será feita a partir da máquina local.

O usuário não deve definir DISPLAY manualmente. Encaminhamento de conexões X11 podem ser configuradas pela linha de comando ou nos arquivos de configuração.

O valor definido para DISPLAY pelo SSH irá apontar para a máquina servidor, mas com um número de display maior que zero. Isto é normal, e acontece porque o SSH cria um servidor X “proxy” na máquina servidor para encaminhar conexões sobre o canal encriptado.

O SSH também irá definir dados Xauthority automaticamente na máquina servidor. Para este fim, ele criará um cookie de autorização aleatória, armazená-lo em Xauthority no servidor, e verificar que as conexões encaminhadas que carregam esse cookie e substituí-lo pelo cookie real quando a conexão é aberta. O cookie de autenticação real nunca é enviado para a máquina servidor (e nenhum cookie é enviado na íntegra).

Se a variável ForwardAgent é definida como “yes” (ou veja a descrição das opções “-A” e “-a”, acima) e o usuário está usando um agente de autenticação, a conexão com o agente é automaticamente encaminhada para o lado remoto.

Verificando chaves de host

Ao se conectar a um servidor pela primeira vez, um fingerprint (impressão digital) da chave pública do servidor é apresentado ao usuário (a menos que a opção foi StrictHostKeyChecking desativada). Fingerprints podem ser determinados usando “ssh-keygen(1)”:

$ ssh-keygen -l -f /etc/ssh/ssh_host_rsa_key

Se o fingerprint já é conhecido, ele pode ser comparado e a chave pode ser aceita ou rejeitada. Por causa da dificuldade de comparar chaves de host só de olhar para cadeias hexadecimais, também há suporte para comparar chaves de host visualmente, usando arte aleatória.

Ao definir a opção VisualHostKey para “yes”, um pequeno gráfico ASCII é exibido em cada login para um servidor, não importando se a sessão em si é interativa ou não.

Ao aprender o padrão que um servidor conhecido produz, um usuário pode facilmente descobrir que a chave de host mudou quando um padrão completamente diferente é exibido. Por causa que estes padrões não são ambíguos no entanto, um padrão que se parece com o padrão lembrado apenas dá uma boa probabilidade de que a chave de host é a mesma, e não uma prova garantida.

Para obter uma lista dos fingerprints, juntamente com sua arte aleatória para todos os hosts conhecidos, a seguinte linha de comando pode ser usada:

$ ssh-keygen -lv -f -/.ssh/known_hosts

Se o fingerprint é desconhecido, um método alternativo está disponível: “fingerprints de SSH verificados por DNS”. Um registro de recurso (RR) adicional, SSHFP, é adicionado a um zonefile (arquivo de zonas) e o cliente que está conectando poderá comparar o fingerprint com aquele da chave apresentada.

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”:

$ ssh-keygen -r host.example.com

As linhas de saída terão de ser adicionadas ao zonefile. Para verificar que a zona está respondendo consultas de impressões digitais:

$ dig -t SSHFP host.example.com

Finalmente, o cliente conecta:

$ ssh -o “VerifyHostKeyDNS ask” host.example.com
[…]
Matching host key fingerprint found in DNS.

Are you sure you want to continue connecting (yes/no)?

Para mais informações, veja o VerifyHostKeyDNS, opção em “ssh_config(5)”.

Base Virtual / Ambiente / Files

SSH – Base Virtual de Redes Privadas

SSH contém suporte para Virtual Private Network (VPN) tunnelling usando tun(4) rede pseudo-device permitindo que duas redes se juntem de forma segura. O “sshd_config(5)”, opção de configuração PermitTunnel, controla se o servidor suporta isso, e em que nível (camada 2 ou 3 de tráfego).

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ão 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.

No cliente:

# ssh -f -w 0:1 192.168.1.15 true
# ifconfig tun0 10.1.1.1 10.1.1.2 netmask 255.255.255.252
# route add 10.0.99.0/24 10.1.1.2

No servidor:

# ifconfig tun1 10.1.1.2 10.1.1.1 netmask 255.255.255.252
# route add 10.0.50.0/24 10.1.1.1

O acesso do cliente pode ser mais afinado através do arquivo /root/.ssh/authorized_keys (veja abaixo) e a opção do servidor PermitRootLogin. A entrada a seguir, permitirá conexões em tun(4) dispositivo 1 para o usuário “Jane” e em tun dispositivo 2 para o usuário “john”, se PermitRootLogin é definido para “forced-commands-only”:

tunnel=”1″,command=”sh /etc/netstart tun1″ ssh-rsa … jane
tunnel=”2″,command=”sh /etc/netstart tun2″ ssh-rsa … John

Desde que uma instalação SSH-based implica em certa quantidade de sobrecarga, pode ser mais adequado para instalações temporárias, como para VPNs sem fio. VPNs mais permanentes são melhores fornecidas por ferramentas, como “ipsecctl(8)” e “isakmpd(8)”.

Ambiente

SSH normalmente define as seguintes variáveis de ambiente:

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

Além disso, o SSH lê ~/.ssh/environment, e adiciona linhas do formato “VARNAME = value” para o ambiente, se o arquivo existe, e os usuários têm permissão para mudar seu ambiente. Para mais informações, consulte o PermitUserEnvironment opção em “sshd_config(5)”.

Files

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

Veja também

  • 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)
  • The Secure Shell (SSH) Protocol Assigned Numbers, RFC 4250, 2006.
  • The Secure Shell (SSH) Protocol Architecture, RFC 4251, 2006.
  • The Secure Shell (SSH) Authentication Protocol, RFC 4252, 2006.
  • The Secure Shell (SSH) Transport Layer Protocol, RFC 4253, 2006.
  • The Secure Shell (SSH) Connection Protocol, RFC 4254, 2006.
  • Using DNS to Securely Publish Secure Shell (SSH) Key Fingerprints, RFC 4255, 2006.
  • Generic Message Exchange Authentication for the Secure Shell Protocol (SSH), RFC 4256, 2006.
  • The Secure Shell (SSH) Session Channel Break Extension, RFC 4335, 2006.
  • The Secure Shell (SSH) Transport Layer Encryption Modes, RFC 4344, 2006.
  • Improved Arcfour Modes for the Secure Shell (SSH) Transport Layer Protocol, RFC 4345, 2006.
  • Diffie-Hellman Group Exchange for the Secure Shell (SSH) Transport Layer Protocol, RFC 4419, 2006.
  • The Secure Shell (SSH) Public Key File Format, RFC 4716, 2006.
  • 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).

Prevenindo acidentes com o comando RM.

 Linux  Comentários desativados em Prevenindo acidentes com o comando RM.
jan 122012
 

Soluções sugeridas

RM – Prevenindo Acidentes

Tópicos:

  • Comando ‘rm’ não tem ‘trash’ (lixeira)
  • Solução nº 1 – interactive mode
  • Solução nº 2 – um alias para o interactive mode
  • Solução nº 3 – trash-cli – lixeira na linha de comando

 

Comando rm não tem trash

Cuidado!!! No terminal, na linha de comando, quando se digita:

# rm segredo_mundial.txt

O arquivo “segredo_mundial.txt” já era. Não tem mais o que fazer.

Solução nº 1 – Interactive Mode

Sempre use a opção ‘-i’, ou ‘–interactive’ com o comando ‘rm’ e torne isto um hábito. Esta opção se prontifica a nos perguntar se realmente desejamos deletar o arquivo:

$ rm -i segredo_mundial.txt
$ rm –interactive segredo_mundial.txt

Cuidado com a flag ‘-f’ ou ‘–force’. Com ela, as opções ‘-‘ ou ‘–interactive’ se tornam inúteis, ou seja, eles são completamente ignorados.

Há um truque que pode ser aplicado, digamos que temos um diretório contendo arquivos muito importantes. Podemos criar um arquivo chamado ‘-i’ dentro deste diretório.

Como o arquivo contém ‘-‘ no nome, não podemos simplesmente fazer ‘touch -i’, pois o comando ‘touch’ vai pensar que estamos passando a opção ‘-i’ como argumento, e o comando ‘touch’ nem tem uma opção chamada ‘-i’.

As duas possíveis maneiras de criar o tal arquivo estão exemplificadas abaixo:

$ touch — -i

Ou:

$ touch ./-i

A partir de agora, se você fizer:

$ rm -Rf *

O shell vai expandir o ‘-i’ na linha de comando, de tal forma que seu comando na verdade se transforma em:

$ rm -Rf -i

Note que isto só funciona se você usar o ‘glob’ (*). Se tentar deletar um arquivo por vez, o arquivo ‘-i’ não vai te ajudar.

Vamos aprender outro truque quando falarmos do programa ‘trash-cli’.

Se quiser remover o arquivo ‘-i’, não basta fazer ‘rm -i’ porque o ‘rm’ tem de fato a opção ‘-i’. Então ‘rm -i’ é o comando ‘rm’, seguido da opção ‘-i’; mas ainda falta dizer ao ‘rm’ qual arquivo ou arquivos deletar, por que ele não sabe que ‘-i’ é um arquivo e não uma opção.

Usamos uma técnica similar à que usamos para criar o arquivo. As duas soluções possíveis são:

$ rm — -i

Ou:

$ rm ./-i

Solução nº 2 – um alias para o Interactive Mode

A solução nº 2 consiste em colocar o que aprendemos acima em um ‘alias’ (um apelido em Inglês).

Vamos criar um alias que faz com que o comando ‘rm’ sempre seja executado com ‘rm –interactive’:

$ alias rm=’rm –interactive’

Digite o comando acima em um terminal e tente remover um arquivo (não teste com nada que seja importante). Para testar, rode apenas ‘rm arquivo.txt’ e você vai notar que ele pergunta se temos mesmo certeza de que queremos deletar o arquivo em questão.

Se você gostou da ideia, coloque o comando que cria o ‘alias’ no “~/.bashrc”. Para que o ‘alias’ entre em vigor, feche e abra o terminal novamente ou rode o comando:

$ source ~/.bashrc

A partir de agora, toda vez que você digitar ‘rm’, o Bash interpreta o ‘alias’ e na verdade vai executar ‘rm –interactive’.

Solução nº 3 – trash-cli – lixeira na linha de comando

Instale o programa ‘trash-cli’. Enquanto escrevo este documento, ‘trash-cli’ está disponível pelo AUR para o Arch Linux, mas pesquisas pela WEB fazem acreditar de que já está nos repositórios oficiais de muitas distribuições.

O programa ‘trash-cli’ vem com três comandos principais:

1. trash-empty: esvazia a lixeira;
2. trash-list: lista os arquivos da lixeira;
3. trash-put: manda arquivos para a lixeira.

Para mais informações, leia o Help de cada uma das variações do ‘trash-cli’:

$ trash-empty –help
$ trash-list –help
$ trash-put –help

O problema agora é criar o hábito de usar o ‘trash-cli’ em vez do bom e velho ‘rm’. Sim, porque nós instalamos o programa, mas por força do hábito é bem provável que continuemos usando o ‘rm’ sem nem notar.

Vamos então usar um truque para, digamos, desabilitar o comando ‘rm’. O truque consiste em, novamente, criar um ‘alias’. Mas antes disso vamos falar de comentários no Bash (com poucos ajustes todas essas dicas funcionam em outros shells).

Um comentário no Bash inicia com ‘#’. Rode o seguinte comando direto do terminal:

$ # echo ‘Hello, world.’

Essa linha não vai executar nada. É um comentário apenas. Tente esta outra:

$ echo ‘Hello, ‘ # world’

O ‘echo’ acima só vai mostrar ‘Hello, ‘. O resto da linha é comentário.

Então, a ideia é criar um ‘alias’ que comente o ‘rm’. É fácil:

$ alias rm=’# rm’

Pode colocar o ‘alias’ no “~/.bashrc” e rodar ‘source ~/.bashrc’. A partir de agora, toda vez que você digitar ‘rm’, ele simplesmente nem sequer será executado, pois agora ele foi ‘comentado’.

No então, há alguns pontos a serem considerados:

1. Se você executar outro Shell a partir do shell que contém o ‘alias’, o outro shell não vai herdar o ‘alias’, portanto, ‘rm’ desse outro shell vai funcionar normalmente.

2. Importante: você executou essas operações no terminal como usuário, e configurou o “~/.bashrc” em nível de usuário. A conta do Root continua com as configurações default. Como o Root é um usuário ainda mais crítico no sistema, considere colocar essas configurações no “/root/.bashrc”.