abr 192020
 

Esta dica irá mostrar um exemplo de configuração do lshell, em um sistema Debian Squeeze, para limitar a execução de comandos previamente liberados para um determinado usuário ou grupo, bem como os diretórios aos quais o usuário poderá ter acesso, dentre outras opções relacionadas ao seu ambiente shell.

Instalação do lshell:

# aptitude install lshell

Configuração do lshell – /etc/lshell.conf:

# gedit /etc/lshell.conf

[global]

## Diretório de logs.
## Usuário deve ser membro do grupo lshell.

logpath     : /var/log/lshell/

## Nível de log: 0, 1, 2 ou 3.
loglevel      : 3

## Nome do arquivo de log. (Padrão %u.log. Ex: usuario.log)
logfilename   : %y%m%d-%u

## Configuração padrão. Poderão ser criadas configurações
## separadas para cada usuário ou grupo.
## Ex: [usuariox], [grp:users]

[default]

## Lista de comandos permitidos ao usuário. Use ‘all’ para permitir
## todos os comandos na variável PATH do usuário.

allowed     : [‘ls’,’echo’,’cd’,’ll’,’date’,’hora’,’vim’,’vi’,’cat’]

## Lista de comandos ou caracteres proibidos.
forbidden     : [‘;’, ‘&’, ‘|’,’`’,’>’,'<‘, ‘$(‘, ‘${‘, ‘cat’]

## Lista de comandos permitidos quando usados com sudo.
## Devem estar previamente configurados em /etc/sudoers.

sudo_commands    : [‘modprobe’, ‘iptables’]

## Número de avisos que o usuário terá antes de ser desconectado
## após tentar entrar em um diretório não permitido ou executar
## um comando da lista ‘forbidden’.

warning_counter : 5

## Aliases para comandos. (alias e comando devem estar na lista ‘allowed’)
aliases     : {‘ll’:’ls -l’, ‘vi’:’vim’, ‘hora’:’date +%H:%M’}

## Texto a ser exibido ao iniciar o lshell.
intro      : “== Ambiente restrito ==\nDigite ‘?’ ou ‘help’ para ver a lista de comandos permitidos.”

## Tempo máximo de inatividade em segundos antes
## do usuário ser automaticamente desconectado.

timer      : 300

## Lista de pastas as quais poderão ser acessadas pelo usuário.
path      : [‘/tmp/’,’/var’]

## Define o diretório home do usuário. Se não especificado,
## sera utilizado o valor da variável de ambiente $HOME.
#home_path    : ‘/home/usuario/’

## Altera a variável de ambiente PATH do usuário.
#env_path    : ‘:/usr/local/bin:/usr/sbin’

## Permite ou proíbe o uso de SCP pelo usuário. ( 1 permitir – 0 negar)
scp      : 1

## Permite ou proíbe uploads com SCP ( 1 permitir – 0 negar).
## Parâmetro ‘scp’ deve possuir valor 1.

scp_upload    : 1

## Permite ou proíbe downloads com SCP ( 1 permitir – 0 negar).
## Parâmetro ‘scp’ deve possuir valor 1.

scp_download    : 0

## Permite ou proíbe o uso de SFTP ( 1 permitir – 0 negar).
sftp      : 1

## Lista de comandos permitidos através de SSH.
## Ex: ssh [email protected] ‘ls ~’

overssh      : [‘ls’,’rsync’]

## Considerar ou não comandos inválidos como ação proibida, se 1,
## comandos inválidos irão gerar avisos que poderão desconectar
## o usuário, conforme parâmetro ‘warning_counter’.

strict      : 0

## Forçar pasta de destino para arquivos enviados por SCP.
scpforce      : “/tmp”

## tamanho máximo do arquivo history.
history_size    : 100

## Nome do arquivo contendo o hipótrico de comandos.
history_file    : “/home/%u/.lshell_history”

Continue reading »

Comandos do MS-DOS

 Clusterweb, Desktop, Leitura Recomendada, Profissional de TI, Windows  Comentários desativados em Comandos do MS-DOS
jul 182014
 

DIFERENÇAS ENTRE COMANDOS INTERNOS E EXTERNOS

Os comandos internos podem ser executados em qualquer pasta no PC e a qualquer momento pois estão embutidos no DOS. Os comandos externos são programas utilitários que acompanham o sistema operacional e que só podem ser executados onde estão localizados, ou seja,no drive onde foram gravados.

Este tutorial está dividido em 2 partes: comandos internos e comandos externos.

Os comandos internos
Nos comandos internos pode-se saber mais informações acerca do mesmo,digitando /? após o comando, ex.: dir/?, você irá receber informações sobre o comando dir, os comandos internos são os mais úteis em emergências já que podem ser executados em qualquer lugar; agora, vamos aos comandos. 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]] [[email protected]]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).

Resumo LPI 102: Tópico 107 – Tarefas Administrativas

 Clusterweb, Leitura Recomendada  Comentários desativados em Resumo LPI 102: Tópico 107 – Tarefas Administrativas
mar 082013
 
107.1 – Administrar contas de usuários e grupos

Em mais um resumo de tópico para a prova LPI 102, venho percebendo a facilidade em estudar usando associação. Com comandos de modo geral, procure saber para que ele serve e o que significa.

Alguns são bem intuitivos, por exemplo, o passwd (password), lsusb (list usb), nc (netcat), chfn (change information). Outros, são mais complicados. Geralmente comandos com ch, tem algo a ver com change (alteração, mudança), ls com list (listar).

Estar atento e disposto a associar os nomes dos comandos facilitará e MUITO seu estudo. O mesmo vale para parâmetros. Leia, ao menos, a descrição nas páginas de manual e faça testes, simule situações, se você ainda não passa boa parte do dia de frente pra tela preta.

Contas de usuários

O comando adduser só pode executado pelo root. Cria usuários automaticamente, com parâmetros definidos no arquivo: /etc/adduser.conf

O comando useradd só pode ser executado como root. Cria usuário setando manualmente os parâmetros desejados. Indicado para uso em scripts. Principais parâmetros:

  • -c (comment) :: Adiciona descrição à conta, geralmente nome completo do usuário;
  • -d (home dir) :: Define o caminho para o diretório pessoal do usuário;
  • -g (Group ID) :: Define o grupo principal – GID;
  • -G (groups) :: Define grupos secundários;
  • -u (User ID) :: Define o ID – UID;
  • -s (shell) :: Define o shell padrão;
  • -p (passaword) :: Define a senha;
  • -e (expire date) :: Define a data de expiração da conta;
  • -k (skel dir) :: Define se a conta do usuário usará a estrutura com base no /etc/skel;
  • -m (create home) :: Cria o diretório pessoal, se não existir.

O diretório /etc/skel/ serve como modelo na criação dos diretórios pessoais. Skel = Skeleton (esqueleto).

O comando passwd altera a senha de usuários. Sintaxe:

# passwd <usuário>
$ passwd

Ou seja, como root, é possível alterar a senha de qualquer usuário. Como usuário comum, somente é possível alterar a própria senha.

O comando chfn (change information) altera o campo descrição da conta de um usuário. Não precisa ser root.

O comando chsh (change shell) altera o shell padrão do usuário. Não precisa ser root.

O comando userdel exclui uma conta de usuário. Parâmetro principal: “-r” (remove) – remove o diretório pessoal.

O arquivo /etc/passwd armazena informações de contas de usuários e pode ser lido por qualquer usuário (permissão: rw-r–r–). Utiliza como separador de campos o “:” (2 pontos).

Observe a estrutura:

root:x:0:0::/root:/bin/bash

Enumerando os campos:

  1. Login do usuário;
  2. Senha. Se for “x”, a senha encontra-se criptografada no arquivo /etc/shadow;
  3. UID – ID do usuário;
  4. GID – ID do grupo principal do usuário;
  5. Descrição do usuário;
  6. Caminho do diretório pessoal;
  7. Shell padrão do usuário.

O comando vipw usa o editor padrão do sistema (Vi) para alterar o arquivo /etc/passwd, bloqueando-o contra edições concorrentes.

Parâmetro principal: -s (shadow) – edita o arquivo /etc/shadow, usando o modelo de bloqueio.

No arquivo /etc/shadow estão as senhas criptografadas dos usuários e mais algumas configurações. Não está visível para todos usuários, por medida de segurança (permissão: rw-r—–). Seu separador de campos também é o “:”.

Estrutura:

root:<senha>:15516:0:99999:7:::

Enumerando os campos:

  1. Login do usuário, que deve corresponder ao do /etc/passwd;
  2. Guarda a senha criptografada do usuário;
  3. Número de dias desde que a senha foi alterada pela última vez. Contando desde 01/01/1970.
  4. Número mínimo de dias que o usuário pode permanecer sem alterar a senha. Zero significa que não tem este prazo mínimo;
  5. Número máximo de dias que o usuário tem para trocar a senha;
  6. Número de dias que o usuário será avisado até que a senha expire;
  7. Número de dias a partir da expiração da senha até que a conta seja bloqueada;
  8. Mostra o número de dias que a conta encontra-se bloqueada. Contando desde 01/01/1970;
  9. Campo reservado.

O comando pwconv altera o armazenamento das senhas do arquivo /etc/passwd para o /etc/shadow.

O comando pwunconv altera o armazenamento das senhas do arquivo /etc/shadow para o /etc/passwd.

O comando chage altera informações referentes à validade de senhas de usuário. Parâmetros principais:

  • -m (minimum days) :: Número de dias mínimos para o usuário poder alterar sua senha;
  • -M (max days) :: Número máximo de dias para troca da senha;
  • -d (last days) :: Número de dias desde que a senha foi alterada, contando desde 01/01/1970;
  • -E (expire date) :: Data de expiração da conta do usuário;
  • -I (inactive) :: Número de dias a partir da expiração da senha até que a senha seja bloqueada;
  • -W (warn days) :: Número de dias para avisar o usuário que a senha deve ser trocada.

O comando usermod modifica contas de usuários. Parâmetros principais:

  • -c (comment) :: Altera o comentário da conta;
  • -d (diretory) :: Altera o caminho do diretório pessoal;
  • -m (move) :: Move o diretório pessoal do usuário para um novo local;
  • -g (group) :: Altera o grupo principal;
  • -G (groups) :: Adiciona o usuário a outros grupos;
  • -l (login) :: Altera o nome de login;
  • -p (password) :: Altera a senha;
  • -u (UID) :: Altera o ID do usuário;
  • -s (shell) :: Altera o shell padrão;
  • -e (expire date) :: Altera a data de expiração da conta do usuário. dd/mm/aaaa;
  • -f (??) :: Dias depois da expiração da senha que a conta será bloqueada. O -1 cancela essa função;
  • -L (lock) :: Bloqueia o usuário. Insere o “!” no campo da senha criptografada;
  • -U (unlock) :: Desbloqueia o usuário. Retira o “!”.

Administrando grupos de usuários

O comando groupadd cria um grupo de usuário.

Principal parâmetro: -g (GID) – Especifica um ID para o grupo.

O comando groupdel exclui um grupo de usuário.

O comando gpasswd insere e exclui usuários de grupos e realiza algumas modificações relacionadas às senhas. Este comando usado sem parâmetro cria uma senha para um grupo.

Principais parâmetros:

  • -r (remove) :: Remove a senha do grupo;
  • -a (add) :: Adiciona usuário ao grupo;
  • -d (delete) :: Deleta usuário do grupo;
  • -A (admin) :: Torna usuário administrador do grupo.

O comando groups mostra o grupo que o usuário pertence. Usado sem argumentos, mostra os grupos do usuário atual.

O comando id mostra os grupos do usuário e informações de UID e GID.

O comando newgrp altera o grupo principal do usuário. Caso ele não pertença, é adicionado automaticamente.

O arquivo /etc/group armazena informações dos grupos. Possui permissão: rw-r–r–

Estrutura:

adm:x:5012:pedro,joao

Enumerando os campos:

  1. Nome do grupo;
  2. Senha criptografada do grupo. O “x” significa que a senha está no arquivo /etc/gshadow;
  3. ID do grupo. GID;
  4. Usuários pertencentes ao grupo, separados por “,”.

O comando vigr edita o arquivo /etc/group, evitando gravações concorrentes.

Principal parâmetro: -s (shadow) – Edita o arquivo /etc/gshadow.

O arquivo /etc/gshadow armazena informações de senhas com criptografia. Possui permissão: rw–r—-

Estrutura:

adm:*::pedro

Enumerando:

  1. Nome do grupo, correspondente ao /etc/group;
  2. Senha criptografada. O “*” significa que o grupo não tem senha;
  3. Usuário administrador do grupo;
  4. Usuário pertencentes ao grupo, como no /etc/group.

O comando grpconv converte o armazenamento das senhas dos grupos, do arquivo /etc/group para o /etc/gshadow.

O comando grpunconv faz o inverso do comando grpconv.

O comando groupmod realiza algumas modificações nos grupos. Principais parâmetros:

  • -g (GID) :: Altera o GID;
  • -n (name) :: Altera o nome do grupo.
107.2 – Automatizar e agendar tarefas administrativas

O comando at é usado para agendar a execução de um comando/script apenas uma vez.

Sintaxe:

# at <quando> <comando>

O argumento “<quando>” pode ser:

  • now :: Execução instantânea;
  • midnight :: Executa à meia noite;
  • Mais opções podem ser vistas no arquivo: /usr/share//doc/at/timespec

Usuários comuns podem usar o “at”, se constarem no arquivo /etc/at.allow. Se este arquivo não existir, o arquivo /etc/at.deny será lido e só não poderá usar o “at” quem constar nele. Se nenhum dos arquivo existirem, só o root poderá usar o “at”.

Parâmetros e variações:

  • -l (parâmetro – list) :: Este parâmetro lista os agendamentos em espera;
  • atq (comando) :: Também lista agendamentos em espera;
  • atrm (comando) :: Exclui agendamentos em espera.

O cron é um daemon para agendamento de tarefas em determinados intervalos de tempo. A cada minuto este daemon verifica as tabelas de agendamento, chamadas crontabs, e executa as tarefas que estiverem configuradas.

Principal crontab (ou tabela de agendamento):

/etc/crontab :: Este é o crontab do sistema. Existem também um crontab para cada usuário.

O comando crontab é para usuários específicos, ao invés do arquivo geral do sistema. Usamos o comando comando crontab, que editará a tabela de agendamento do respectivo usuário.

Principais parâmetros:

  • -l (list) :: Lista as tarefas agendadas;
  • -e (edit) :: Edita o crontab do usuário;
  • -r (remove) :: Remove o crontab do usuário.

Sintaxe:

# crontab <parâmetro> <usuário>

Configurando uma tabela de agendamento (ou crontab). O separador pode ser:

0-59 0-23 0-31 1-12 0-6 <comando>

Enumerando:

  1. Variação dos minutos;
  2. Das horas;
  3. Dos dias;
  4. Dos meses;
  5. Dos dias da semana (0 é domingo e 6 é sábado);
  6. Comando a ser executado.

Exemplo real de utilização:

* */4 * 5,6 1-5   /root/script.sh

Nesta linha, que poderia estar no arquivo /etc/crontab, por exemplo, executaria o arquivo “script.sh” a cada quatro horas, nos meses de maio e junho de segunda à quinta-feira.

Explicando os caracteres utilizados no exemplo:

  • * → Nada a fazer;
  • → Determina um período;
  • / → Determina um espaço de tempo. Um marcapasso;
  • , → Determina tempos específicos. Serve para intercalar o tempo, quebrar uma sequência.

Diretórios auxiliares:

  • /etc/cron.hourly/ → Executa os arquivos dentro dele de a cada hora;
  • /etc/cron.daily/ → Executa os arquivos todos os dias;
  • /etc/cron.monthly/ → Executa todos os meses;
  • /etc/cron.weekly/ → Executa toda semana.

Estes diretórios são usados quando não é necessário especificar a hora para execução de uma tarefa.

Arquivos para controle de utilização do contrab:

  • /etc/cron.allow → Se existir, só os usuário especificados nele poderão agendar tarefas;
  • /etc/cron.deny → Se existir, os usuários que forem especificados nele não poderão agendar tarefas.

Obs.: Se os dois não existirem, todos os usuários poderão agendar tarefas.

107.3 – Localização e internacionalização

Fuso horário:

O comando tzselect ajusta o fuso horário do sistema. Após configurado, é criado o arquivo /etc/timezone.

O arquivo /etc/localtime guarda informações sobre o horário de verão. As opções de configuração estão no diretório /usr/share/zoneinfo.

O comando locale exibe as variáveis de ambiente que contém informações de idioma e padrão de codificação do sistema.

A variável LANG é uma variável global usada pela maioria dos programas, como referência para definição do idioma padrão. O conteúdo dessa variável obedece o formato idioma_PAIS.CODIFICAÇÃO.

Exemplo:

$ echo $LANG
pt_BR.UTF-8

Neste caso, significa:

  • pt :: Idioma português;
  • BR :: País, Brasil;
  • UTF-8 :: Codificação Unicode, padrão do GNU/Linux.

Obs.: Em scripts é recomendável setar a variável LANG dessa forma: LANG=C. Evitando assim resultados diferentes quando o script é executado em sistemas diferentes, com configurações diferentes.

Outras variáveis de ambiente são importantes para a correta configuração de programas. São elas:

  • LC_COLLATE :: Define ordenação alfabética;
  • LC_CTYPE :: Define o tratamento de caracteres;
  • LC_MESSAGES :: Definição do idioma em avisos emitidos por programas;
  • LC_MONETARY :: Define unidade monetária e formato da moeda;
  • LC_NUMERIC :: Define o formato numérico de valores não monetários;
  • LC_TIME ::- Define o formato de data e hora;
  • LC_PAPER :: Define o tamanho padrão do papel;
  • LC_ALL :: Sobrepõe todas as demais variáveis;

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