sexta-feira, 2 de outubro de 2015

Gerenciando Senhas com o TeamPass

Introdução

O TeamPasss é um gerenciador corporativo e colaborativo de senhas e informações sensíveis. Ele foi especialmente desenvolvido para gerenciar, armazenar, prover senhas e oferecer meios de acesso a informação sensível de forma controlada, centralizada e dinâmica.
Eu descobri esse cara garimpando no blog do meu amigo Guto Carvalho, leiam o post dele antes de prosseguir ;-)

Ponto de partida

Eu parto do princípio que você já possui um Servidor CentOS 7 Básico.

Pré-Requisitos

Antes de começarmos a instalação precisamos suprir alguns pré-requisitos, depois será Next, Next, Finish.

Banco de Dados

A primeira coisa que precisamos fazer é criar a base de dados, que posteriormente será populada durante a instalação. Essa base pode ser local ou remota, a decisão é sua.

No exemplo abaixo vamos criar uma base de dados chamada teampass_db e um usuario chamado teampass com senha TeAmPaSs.
mysql> CREATE DATABASE teampass_db CHARACTER SET utf8 COLLATE utf8_general_ci;

mysql> GRANT ALL PRIVILEGES ON teampass_db.* TO teampass@localhost IDENTIFIED BY '
TeAmPaSs';

mysql> flush privileges;

Dependências de pacotes

Essa versão precisa do PHP 5.5, apesar de exibir que o pré-requisito é o PHP 5.3 ou superior, eu não consegui fazer funcionar com o PHP 5.4. 
# yum -y install php55-php php55-php-mcrypt php55-php-ldap php55-php-common unzip php55-php-mbstring php55-php-bcmath php55-php-xml

Ajustes no PHP

# cd /etc
# ln -s /opt/remi/php55/root/etc/php.ini php.ini 

# vi /etc/php.ini
date.timezone = America/Sao_Paulo
max_execution_time = 60


# systemctl restart httpd

Dado tipo Sal

É preciso criar um diretório que é dependência da instalação, esse diretório irá armazenar um dado do tipo Sal (Salt) que será utilizado juntamente com a senha.
# cd /var/www/
# mkdir saltkey
# chown -R apache:apache saltkey

Download dos arquivos

Precisamos realizar o download dos arquivos e copiar os arquivos php para o diretório web.
# mkdir /install
# cd /install
# wget https://github.com/nilsteampassnet/TeamPass/archive/master.zip
# unzip master
# cd /var/www/html/
# mv /install/TeamPass-master/ teampass
# chown -R apache:apache teampass

Instalaçao

basta acessar o endereço do seu servidor:
http://ip_servidor/teampass/install/install.php


Na tela inicial clique em NEXT
Clique em LAUNCH, para que a instalação cheque os pré-requisitos
Os pré-requisitos estando OK, o botão NEXT é liberado, pode pressioná-lo
Preencha as informações de conexão com a base de dados e pressione o botão LAUNCH para que a conexão seja testada
Após a conexão ser estabelecida com sucesso o botão NEXT é liberado, basta pressioná-lo
Nessa tela temos que observar vários detalhes:
  • Gerar o arquivo salt e informar o caminho onde o mesmo será armazenado;
  • Configurar a seção de SMTP (Opcional);
  • Inserir a senha do Administrador;
Por último clique no no botão LAUNCH para que os dados sejam checados.
 Após a validação das informações clique no botão NEXT
A base de dados é populada, clique em NEXT
Ajustes finais são realizados, clique em NEXT
A própria instalação já remove o diretório de instalação, clique em NEXT
Apenas um resumo informando que a instalação está concluída e que o usuário de login é admin, clique em Start
Faça o login com o usuário admin e a senha que foi cadastrada e, observe que o modo de manutenção está habilitado.

Configurações

Configurações Iniciais

Clique em Settings para alterarmos as configurações iniciais
Na aba TeamPass Settings vamos remover o modo de manutenção, alterar as opções de timezone e o idioma. Após realizar as alterações clique em Save

Integração com Active Directory

Esse passo é opcional,  mas se você tem um AD na rede, é uma boa pedida configurar a autenticação por ele, ao invés de ter que decorar mais uma senha. Apenas a autenticação será feita pelo AD, você precisa criar o usuário no TeamPass de qualquer forma, afinal de contas não queremos qualquer usuário do AD autenticando no TeamPass. Além do AD ele suporta também Posix / OpenLDAP (RFC2307).

Clique na aba Opções LDAP, marque a opção Sim em "Ativa autenticação LDAP para os usuários", selecione o "LDAP server type" como Windows / Active Directory e clique em Salvar
Clique novamente na aba Opções LDAP e preencha as opções da seção Configuração LDAP e clique em Salvar

Liberar acesso à aplicação apenas de determinados endereços IPs

Se você quiser incrementar a segurança um pouco mais, e aconselho a fazer, você pode liberar o acesso para o site apenas para as máquinas do setor de informática. Para isso edite o arquivo de configuração do apache:
# vi /etc/httpd/conf/httpd.conf
<Directory "/var/www/html/teampass">
   Order deny,allow
   Deny from all
   Allow from 192.168.100.15/255.255.255.0
   Allow from 192.168.100.16/255.255.255.0
   Allow from 192.168.100.17/255.255.255.0
</Directory>


Após isso reinicie o apache
# systemctl restart httpd

Gerenciamento de Usuários

O TeamPass possui 3 tipos de usuários:
  • Admin (Administrador): Esse tipo de usuário consegue criar e gerenciar outros usuários, criar e gerenciar regras, associar usuários a regras e, administar configurações internas do TeamPass, porém ele não consegue ver as pastas, consequentemente ele não conseguirá criar e gerenciar senhas em tais pastas.
  • Manager (Gerenciador): Esse tipo de usuário conseguirá administrar uma ou mais regras - e suas pastas - e os usuários associados a esta regra, ele também conseguirá criar e gerenciar senhas dentro das pastas pertencentes as regras que ele estiver associado. O manager até consegue criar pastas em suas regras, mas será preciso o Admin para liberar o uso da pasta naquela regra. Ele também consegue criar usuários de nível inferior ao dele.
  • Read Only (Somente Leitura): Este tipo de usuário só consegue utilizar as pastas associadas à regra que ele faz parte, ele não cria pastas, e nem pode criar, modificar e apagar senhas dentro das pastas que tem acesso.

Referencias

Infraestrutura Ágil
Teampass and authentication Ldap/Active directory

quinta-feira, 1 de outubro de 2015

phpMyAdmin Acessando Multiplos Servidores Remotos

Introdução

A maioria das pessoa utiliza o phpMyAdmin para acessar bases de dados que estão no mesmo servidor (localhost), mas é possível configurá-lo para acessar mais de um servidor ao mesmo tempo e também para acessar servidores remotos, ou seja, se você possui na sua estrutura vários servidores MySQL você pode utilizar um único phpMyAdmin, centralizando assim seu acesso.

Ponto de partida

Eu parto do princípio que você já possui um Servidor CentOS 7 Básico.

Instalação

A instalação será feita através do yum:

# yum install -y phpMyAdmin

Depois de instalado vamos criar um link na raíz do nosso diretório web, nesse caso eu chamei de mysql:
# cd /var/www/html/
# ln -s /usr/share/phpMyAdmin mysql
# ls -l
total 0
lrwxrwxrwx 1 root root 21 Set 18 17:29 mysql -> /usr/share/phpMyAdmin

Acessar a interface do phpMyAdmin

Acesse o endereço http://ip_servidor/mysql

Configurar o acesso para vários servidores

Edite o arquivo config.inc.php
# vi /etc/phpMyAdmin/config.inc.php
Logo no início do arquivo temos a seção Servers Configuration, com as informações referentes ao localhost
/*
 * Servers configuration
 */
$i = 0;

/*
 * First server
 */
$i++;
/* Authentication type */
$cfg['Servers'][$i]['auth_type'] = 'cookie';
/* Server parameters */
$cfg['Servers'][$i]['host'] = 'localhost';
$cfg['Servers'][$i]['connect_type'] = 'tcp';
$cfg['Servers'][$i]['compress'] = false;
$cfg['Servers'][$i]['AllowNoPassword'] = false;


Podemos acrescentar logo abaixo o bloco de comandos para os demais servidores:
/*
* Server Remoto 1
*/
//$i++;
/* Authentication type */
$cfg['Servers'][$i]['verbose'] = 'Server Remoto 1';
$cfg['Servers'][$i]['auth_type'] = 'cookie';
/* Server parameters */
$cfg['Servers'][$i]['host'] = '192.168.100. 1';
$cfg['Servers'][$i]['connect_type'] = 'tcp';
$cfg['Servers'][$i]['compress'] = false;
$cfg['Servers'][$i]['AllowNoPassword'] = false;

/*
* Server Remoto 2
*/
$i++;
/* Authentication type */
$cfg['Servers'][$i]['verbose'] = 'Server Remoto 2';
$cfg['Servers'][$i]['auth_type'] = 'cookie';
/* Server parameters */
$cfg['Servers'][$i]['host'] = '192.168.100.2';
$cfg['Servers'][$i]['connect_type'] = 'tcp';
$cfg['Servers'][$i]['compress'] = false;
$cfg['Servers'][$i]['AllowNoPassword'] = false;

Remover o acesso ao localhost

E por último podemos remover a opção de acesso ao localhost, deixando assim o phpMyAdmin em um servidor exclusivo para páginas Web, e os bancos de dados em servidores exclusivos para essa função. Basta comentar as linhas.
/*
 * First server
 */
//$i++;
/* Authentication type */
//$cfg['Servers'][$i]['auth_type'] = 'cookie';
/* Server parameters */
//$cfg['Servers'][$i]['host'] = 'localhost';
//$cfg['Servers'][$i]['connect_type'] = 'tcp';
//$cfg['Servers'][$i]['compress'] = false;
//$cfg['Servers'][$i]['AllowNoPassword'] = false;

Referências

Configurando o phpMyAdmin para acessar o MySQL remotamente

sexta-feira, 31 de julho de 2015

Script de Backup das Configurações de Ativos de Rede para Servidor TFTP

Introdução

É possível realizar o exporte das configurações de ativos de redes (como switches, roteadores, controladoras de rede sem fio, etc) para um Servidor TFTP, como o arquivo gerado é irrelevante em termos de tamanho, criei um script que se conecta via telnet em cada um dos ativos, realiza o exporte para um Servidor TFTP e renomeia o arquivo para o dia da semana. Com isso temos uma cópia das configurações dos últimos sete dias de cada ativo. Como medida adicional de segurança o servidor de backup coleta esses dados, para preserva-los mesmo que algo aconteça com o Servidor TFTP, como um crash de disco, por exemplo.

Estrutura

  • /Scripts: Diretório que abriga o script;
  • /Backup/Logs: Diretório que abriga o log do processo, Log_Switches-DIA_DA_SEMANA.log, se esse arquivo não for vazio, ou seja, acontecer algum erro, esse log será enviado por e-mail;
  •  /Backup/Switches: Diretório que abriga o export das configurações, existe um diretório para cada switch (switch1, switch2, etc), e dentro de cada diretório o arquivo de configuração, SwitchX-DIA_DA_SEMANA.cfg.

Ponto de partida

Eu parto do princípio que você já possui um Servidor TFTP em execução.

Pré-Requisitos

O único pré-requisito é o servidor ter um cliente de telnet.
# yum install telnet

Criar a estrutura de diretórios

# mkdir -p /Backup/{Logs,Switches}

Nesse exemplo estou partindo do princípio que você possui 10 Switches, altere de acordo com sua necessidade.
# for ((i=1; i<=10; i++))
do
mkdir /Backup/Switches/switch$i
done

Verificando a sintaxe do ativo

Antes de partirmos para o script em si, é preciso alguns passos:
  • Verificar se seu ativo possui suporte a telnet e, se está habilitado;
  • Ler o manual para encontrar qual é a sintaxe de comando de backup das configurações e como exportá-las para um servidor TFTP;
  • Rodar o comando de forma manual e ter certeza de que tudo funcionou como deveria;
  • Verificar quanto tempo demora o upload da configuração para o Servidor TFTP.

Sintaxe de alguns equipamentos

Switch 3COM 4200G
tftp IP_TFTP put 3com4200g.cfg Switch.cfg

Switch 3COM 4800G
tftp IP_TFTP put 3comoscfg.cfg Switch.cfg

Switch D-Link DGS-3100 / DES-3226S
upload configuration IP_TFTP Switch.cfg

Switch D-Link DGS-3120
upload cfg_toTFTP IP_TFTP dest_file Switch.cfg

Switch D-Link DGS-3526
upload cfg_toTFTP IP_TFTP Switch.cfg

Automatizando o processo

A primeira dificuldade que encontramos é que ao realizar uma conexão telnet, estamos em outro equipamento, e por isso não podemos usar o Here Document como faríamos com um banco de dados, por exemplo, mas esse problema foi solucionado pelo Mago do Shell Script Julio César Neves:

#(echo 'admin'; sleep 2; echo 'senha_ativo'; sleep 2; echo 'comando_ativo'; sleep 2; echo 'quit') | telnet IP_ATIVO

Por exemplo para o Switch 3COM 4800G:
# (echo 'admin'; sleep 2; echo 'S3NhAd0sW1TcH3'; sleep 2; echo 'pwd'; sleep 2; echo 'quit') | telnet 192.168.100.2

O Script

O Script pode ser baixado aqui e está todo comentado para melhor compreensão.

Referências

Lista Shell Script Yahoo

sexta-feira, 24 de julho de 2015

Instalação de Servidor TFTP em Ambiente CentOS

Introdução

Um servidor TFTP é útil em pelo menos duas situações:
  • Manipulação de arquivos em ativos de rede, como por exemplo, atualização de firmware, backup e restore de configuração;
  • Manter um backup de seus ativos de rede centralizados em um único diretório, que posteriormente vai para a unidade de fita, claro.
A primeira situação é bem comum, mas poucos se preocupam com a segunda situação, então fique com ela na mente, pense sobre isso enquanto toma banho (já resolvi tantos problemas pensando durante o banho),  eu voltarei nesse ponto em outro post.

Ponto de partida

Eu parto do princípio que você já possui um Servidor CentOS 7 Básico.

Instalação dos pacotes

# yum  -y install  tftp-server xinetd

Ativar o serviço

# systemctl enable tftp.socket

Configuração das permissões

# chown -R nobody:nobody /var/lib/tftpboot/
# chmod 777 /var/lib/tftpboot/

Personalização do arquivo de configuração

# vi /etc/xinetd.d/tftp

service tftp
{
        disable
                 = no 
        socket_type             = dgram
        protocol                = udp
        wait                    = yes
        user                    = root
        server                  = /usr/sbin/in.tftpd
        server_args             = -s -c /var/lib/tftpboot 

        per_source              = 11
        cps                     = 100 2
        flags                   = IPv4
}


Observação: Sem o parâmetro -c você não será capaz de criar novos arquivos, apenas de atualizar os já existentes.

Iniciar o serviço

# systemctl start xinetd
# netstat -ntulp | grep 69
udp        0      0 0.0.0.0:69                  0.0.0.0:*                               1329/xinetd

Testar a comunicação com o serviço

Cliente TFTP para Linux

De preferência teste o envio a partir de outro servidor para ter certeza que tudo está funcionando.
# yum install -y tftp

# cd /etc/
# tftp -v 192.168.0.181 -c put passwd
Connected to 192.168.0.181 (192.168.0.181), port 69
putting passwd to IP:passwd [netascii]
Sent 28437 bytes in 0.2 seconds [1228778 bit/s]


Observação: 192.168.0.181 é o IP do meu servidor de TFTP, não esqueça de alterar o endereço.

De volta ao servidor de TFTP:
# ls -l /var/lib/tftpboot/
total 28
-rw-rw-rw- 1 nobody nobody 28111 Jul 23 16:41 passwd


De volta ao servidor Cliente:
# cd ~
# tftp -v IP -c get passwd
Connected to 192.168.0.181 (192.168.0.181), port 69
getting from 192.168.0.181:passwd to passwd [netascii]
Received 28437 bytes in 0.0 seconds [82130090 bit/s]

# ls -l passwd
-rw-r--r-- 1 root root 28111 Jul 23 16:50 passwd


Observe que o arquivo tem exatamente o mesmo tamanho.

Cliente TFTP para Windows

Podemos baixar um cliente linha de comando para Windows em TFTP Client for Windows

Download de um arquivo do TFTP Server
C:\>tftp.exe -i IP GET nome_arquivo_remoto nome_arquivo_local

Upload de um arquivo para o TFTP Server:
C:\>tftp.exe -i IP PUT nome_arquivo_local nome_arquivo_remoto

Download do arquivo passwd
C:\>tftp.exe -i 192.168.0.181 GET passwd passwd.txt
WinAgents TFTP Client version 2.0b Copyright (c) 2004-2011 by Tandem Systems, Ltd.
http://www.winagents.com - Software for network administrators

Transfering file passwd from server in octet mode...
Transferring data from 192.168.0.181...
Using blocksize = 512
Using TFTP timeout = 10s
Transfer size = 28111 bytes
File passwd was transferred successfully.
28111 bytes transfered for 1 seconds, 0 bytes/second

Referências

www.question-defense.com
Knowledge Addict
Fórum CentOS.org
Tournas Dimitrios
TFTP Server for Windows

quarta-feira, 22 de julho de 2015

Servidor CentOS 7 Básico

Introdução

Com o advento do Systemd e a mudança de MySQL para MariaDB, algumas pessoas se assustam ao migrar de CentOS 6.X para 7.X, o objetivo desse post é prover uma instalação básica, mostrar alguns comandos para que você se sinta mais confortável e sugerir algumas boas práticas.

Antes de continuarmos

Eu sou da época em que a ajuda e incentivo que a gente recebia era RTFM, fui criado no Slackware, então apesar de gostar de ensinar, algumas coisas permanecem, pois fazem parte da minha formação. Só para citar as principais:
Servidor não tem interface gráfica, a menos que seja uma necessidade da aplicação;
Instalações são feitas sempre partindo-se do Minimal;
Só instale o que for necessário;
Servidor é 64 bits;
Cada aplicação precisa pacotes e ajustes específicos, esse post trata do que você deve fazer em todos os seus servidores.

Ajustes Pós Instalação

Partindo do princípio que você fez uma instalação Minimal do CentOS 7, logou pela primeira vez como root, vamos fazer alguns ajustes.

Parar a execução do firewall:

# systemctl stop firewalld

Desabilitá-lo permanentemente:

# systemctl disable firewalld
rm '/etc/systemd/system/dbus-org.fedoraproject.FirewallD1.service'
rm '/etc/systemd/system/basic.target.wants/firewalld.service'

Conferir se o mesmo está desabilitado:

# systemctl is-enabled firewalld
disabled


DICA: Você pode ver o status de todos os serviços com o comando abaixo:
# systemctl list-unit-files

Checar o estado do SELinux:

# getenforce
Enforcing

Torna-lo permissivo:

# setenforce 0

Checar o estado do SELinux:

# getenforce
Permissive


DICA: Para desabilitar definitivamente o SELinux edite o arquivo /etc/selinux/config e altere a opção "SELINUX=enforcing" para "SELINUX=disabled". Isso pode ser feito por meio do comando:
# sed -i 's/enforcing/disabled/g' /etc/selinux/config

Observação: Estou desabilitando o Firewall e o SELinux porque cada servidor tem uma finalidade específica e, exige ajustes específicos para essa finalidade, então por padrão desabilito os dois, e se houver necessidade, reabilito e faço os ajustes específicos.

O EPEL - Extra Packages for Enterprise Linux é um repositório oficial com pacotes extras e as últimas versões dos pacotes. Podemos instalá-lo através do comando abaixo:
# rpm -Uvh http://download.fedoraproject.org/pub/epel/7/x86_64/e/epel-release-7-5.noarch.rpm

O REMI é um repositório com pacotes adicionais aos do EPEL e/ou versões mais atualizadas do mesmo, dependendo do caso. Ele não funciona se o EPEL não estiver instalado, é um pré-requisito. Para instalar o remi, use o comando abaixo:
# rpm -Uvh http://rpms.famillecollet.com/enterprise/remi-release-7.rpm

Além disso ele vem desabilitado, é preciso habilitá-lo:
# vi /etc/yum.repos.d/remi.repo
[remi]
name=Les RPM de remi pour Enterprise Linux 7 - $basearch
#baseurl=http://rpms.famillecollet.com/enterprise/7/remi/$basearch/
mirrorlist=http://rpms.famillecollet.com/enterprise/7/remi/mirror
#enabled=0
enabled=1

gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-remi


Feito isso atualize seu sistema:
# yum update -y

Este último comando vai atualizar todos os pacotes do seu sistema para as versões disponíveis no EPEL e REMI.

Dependencias Básicas

Esses são pacotes que precisamos para o dia-a-dia, independente da aplicação desse servidor. Lembre-se um Servidor Web tem necessidades diferentes de um Servidor de FTP.
# yum -y install rsync  bind-utils mlocate mailx wget net-tools make cmake automake man net-tools

Clamav

Todo servidor tem que ter antivírus? Mas não é Linux? Eu disse que ia lhe sugerir algumas boas práticas, mas são apenas sugestões, este é o meu setup de Servidor CentOS 7.
# yum -y install clamav-server clamav-data clamav-update clamav-filesystem clamav clamav-scanner-systemd clamav-devel clamav-lib clamav-server-systemd

Precisamos comentar as linhas de exemplo:
# sed -i -e "s/^Example/#Example/" /etc/freshclam.conf
# sed -i -e "s/^Example/#Example/" /etc/clamd.d/scan.conf


E atualizar o clamav:
# freshclam

Precisamos comentar a linha abaixo:
# sed -i -e "s/^FRESHCLAM_DELAY/#FRESHCLAM_DELAY/" /etc/sysconfig/freshclam

Editar o arquivo scan.conf:
# vi /etc/clamd.d/scan.conf

E descomentar a linha:
#LocalSocket /var/run/clamd.scan/clamd.sock

Habilitar o Clamav, Inicia-lo e Checar se o processo está ativo:
# systemctl  enable clamd@scan
# systemctl  start clamd@scan
# systemctl  status clamd@scan


Testar a verificação de um arquivo:
# clamdscan -c /etc/clamd.d/scan.conf /etc/hosts

Cron

Deixar um cron padrão para que qualquer um possa editá-lo:
# crontab -e

# Exemplo de uso
# 0     4       *       *       *       <usuario>       who

# Campo         Funcao
# 1o.           Minuto
# 2o.           Hora
# 3o.           Dia do mes
# 4o.           Mes
# 5o.           Dia da semana

# 6o.           Usuario com o qual o comando sera executado <opcional>
# 7o.           Programa para execucao

# Campo                 Valores
# Minuto                 0-59
# Hora                     0-23
# Dia do mes           1-31
# Mes                      1-12
# Dia da semana      0-6 (o "0" eh o domingo), 1 eh a segunda, etc.

# -----------------------------------------------------------------------------------------------
# Roda o update do antivirus todos os dias as 23:00
0 23 * * * /usr/bin/freshclam


Reiniciar o servidor:
#reboot

Referências

ISMAILYENIGUL

sexta-feira, 17 de julho de 2015

Como recuperei meus dados de um Volume LVM

Introdução

Resumindo em poucas palavras perdi meu volume LVM, fiz várias besteiras na tentativa de recuperá-lo e quando achei que estava tudo perdido, meu amigo Ariel me deu as ferramentas necessárias para resolver a questão.

As soluções apresentadas aqui não vão se aplicar a qualquer situação de perdas de dados de LVM, mas podem ser a solução se o seu cenário for próximo do meu.

Cenário

Dois discos instalados no notebook

/dev/sda:
/boot - Partição padrão ext4
swap - Partição padrão swap
/ - Partição LVM VG1
/home - Partição LVM VG1

/dev/sdb:
/Dados - Partição LVM VG1

O meu cenário era relativamente simples, um VG compreendendo ambos os discos, sendo que o LV que eu queria recuperar estava isolado no /dev/sdb, aliás, fica a dica: evite quebrar seus LVs em mais de um disco, caso seja possível. Eu acredito que as soluções apresentadas podem funcionar para outros cenários, mas não testei isso! O objetivo aqui é apenas relatar como recuperei o meu cenário.

Criar uma imagem do disco

Esse passo é fundamental, independente de qual solução você escolher, a primeira coisa que você deve fazer é gerar um clone do seu disco.
dd if=/dev/sdX of=/mnt/sdX.img bs=512 conv=noerror,sync

No meu caso:
# dd if=/dev/sdb of=/mnt/sdb.img bs=512 conv=noerror,sync

Onde /mnt é um HD externo, outro disco, uma unidade de rede, enfim, um lugar com espaço suficiente para armazenar uma cópia completa (mesmo tamanho) do seu disco.

Esse processo vai demorar, vai demorar muito... Meu HD de míseros 320 GB demorou mais de 10 horas. Não pule esse passo, se nada funcionar você ainda pode voltar essa cópia para o mesmo disco (ou outro) e envia-lo para uma empresa especializada em recuperação de dados.

Primeira Solução - Montar a imagem do disco de forma direta

Na ordem cronológica do meu caso, essa foi a segunda solução encontrada, mas ela é mais simples, então aconselho você a começar por ela.

Basicamente o que vamos fazer é montar a imagem que temos do disco no sistema e restaurar nossos dados para outro disco.

Essa solução também é um pouco mais limitada: só dá para usá-la caso seu LV esteja alocado em uma faixa contínua no disco, ou seja, se ele tiver apenas um segmento, e estiver situado em apenas um dos discos. Para saber se o seu LV tem apenas um segmento contínuo, veja mais abaixo o dump do metadado feito a partir do início da partição LVM.

# mkdir /Dados2
# mount -o loop,ro,offset=$((2*1024*1024)) /run/media/deo/IMG/Déo/sdb.img /Dados2


O comando mount acima abre um sistema de arquivos contido em uma imagem (arquivo sdb.img), fazendo sua associação a um ponto de montagem. O detalhe importante é a opção offset que ignora os primeiros n bytes do arquivo de imagem. Neste caso foi tentado o valor de 2MB, afim de ignorar o primeiro MB entre o início do disco e a primeira partição e também 1 MB referente ao metadado da partição LVM. Caso você tente usar esse comando, se o mount pedir para você informar o sistema de arquivos, é porque não funcionou, não perca tempo tentando especificá-lo. Dá para tentar também variações como 3*... 4*..., em fim, pode ser que o seu metadado seja maior.

É possivel também que você precise aumentar o offset, caso o LV em questão não esteja no início da partição. Nesse caso some ao valor acima o valor do start_extent multiplicado pelo extent_size, que podem ser encontrados no metadado, discutido mais abaixo.

# ls -las /Dados2
total 23927780
      4 drwxr-xr-x. 10 deo  deo        4096 Jun 14 17:44 .
      4 dr-xr-xr-x. 20 root root       4096 Jun 23 15:29 ..
      4 drwx------.  2 deo  deo        4096 Mar 24 08:47 centos-6.5-pe-3.7.0-ptb2.13-vbox
8388648 -rw-------.  1 deo  deo  8592031744 Jan  4 00:57 CentOS 7 - Zabbix Server.vdi
8388648 -rw-------.  1 deo  deo  8592031744 Jan 28 00:13 CentOS Scripts.vdi

# df -kh
Sist. Arq.                Tam. Usado Disp. Uso% Montado em
/dev/loop0                294G   93G  186G  34% /Dados2

Segunda Solução - Extrair as informações referentes ao LVM do disco

É isso mesmo que você leu, o LVM guarda uma cópia das configurações dele no início de cada partição integrante do VG, aquele 1MB de metadado do LVM da primeira solução ;-), foi essa solução que salvou a minha pele.

Vamos extrair as primeiras 500 linhas do disco, você pode fazer isso com um live cd por exemplo. Esse arquivo possui os dados que serão a base para recriarmos o nosso volume.
strings -t x /dev/sdX | head -500 > string_dev_sdX.txt

No meu caso:
# strings -t x /dev/sdb | head -500 > string_dev_sdb.txt

Agora você precisa criar um volume LVM na sua máquina, ou instalar o HD que você quer recuperar em uma máquina com LVM funcional. No meu caso eu reinstalei o sistema no /dev/sda criando a mesma estrutura: /boot, swap, / e /home. Como a partição /Dados estava em outro disco, e em somente em um disco, eu não precisei me preocupar muito.

Recapitulando o que temos até agora:
  • Sistema funcional com LVM;
  • Disco que desejo recuperar instalado na máquina;
  • Arquivo que vamos utilizar para recriar os apontamentos.

Carregar o módulo
# modprobe dm-mod

Exibir os volumes físicos:
# pvs -v
    Scanning for physical volume names
  PV         VG     Fmt  Attr PSize   PFree   DevSize PV UUID
  /dev/sda2  fedora lvm2 a--  111,59g      0  111,59g 1r10wL-sh0C-KcAF-K9XB-ji2L-hzbM-UBhEDL
  /dev/sdb1         lvm2 a--  298,09g 298,09g 298,09g uYRucm-f2aK-Ye0q-C2Db-QYpg-aw2z-9sBGV3


O que nos interessa é o PV UUID, nesse caso "uYRucm-f2aK-Ye0q-C2Db-QYpg-aw2z-9sBGV3". E o nome do VG funcional, no meu caso "fedora".

Agora é a etapa final, mas antes de mais nada BACKUP:
# cp /etc/lvm/backup/fedora /etc/lvm/backup/fedora_02
# cp /etc/lvm/archive/fedora_00000-427671572.vg /etc/lvm/archive/fedora_2_00000-427671572.vg


Esses arquivos, são os arquivos que o LVM utiliza para controlar quais são os volumes, partições, pontos de montagem e etc.

Ao abrir o arquivo string_dev_sdb.txt, encontramos as informações referentes ao pv1:
 102594 pv1 {
 10259a id = "uYRucm-f2aK-Ye0q-C2Db-QYpg-aw2z-9sBGV3"
 1025c8 device = "/dev/sdb1"
 1025de status = ["ALLOCATABLE"]
 1025f7 flags = []
 102602 dev_size = 625140400
 102617 pe_start = 2048
 102627 pe_count = 76310

Remova todo esse código hexadecimal, faça as devidas indentações, feche as chaves que estão faltando e, transforme os dados nisso:
                pv1 {
                        id = "uYRucm-f2aK-Ye0q-C2Db-QYpg-aw2z-9sBGV3"
                        device = "/dev/sdb1"

                        status = ["ALLOCATABLE"]
                        flags = []
                        dev_size = 625140400
                        pe_start = 2048
                        pe_count = 76310
                }

Agora procure no arquivo string_dev_sdb.txt, as informações referentes ao ponto de montagem dados:
 1029b1 dados {
 1029b9 id = "SdiIbs-5dcB-hZkU-ykcW-cXy0-EIdr-5DNBwZ"
 1029e7 status = ["READ", "WRITE", "VISIBLE"]
 102a0d flags = []
 102a18 creation_host = "deonote"
 102a32 creation_time = 1411552196
 102a4d segment_count = 1
 102a60 segment1 {
 102a6b start_extent = 0
 102a7c extent_count = 76310
 102a92 type = "striped"
 102aa3 stripe_count = 1
 102ab5 stripes = [
 102ac1 "pv1", 0

Remova todo esse código hexadecimal, faça as devidas indentações, feche as chaves que estão faltando e, transforme os dados nisso:
                dados {
                        id = "SdiIbs-5dcB-hZkU-ykcW-cXy0-EIdr-5DNBwZ"
                        status = ["READ", "WRITE", "VISIBLE"]
                        flags = []
                        creation_host = "localhost"
                        creation_time = 1411552196
                        segment_count = 1

                        segment1 {
                                start_extent = 0
                                extent_count = 76310

                                type = "striped"
                                stripe_count = 1

                                stripes = [
                                        "pv1", 0
                                ]
                        }
                }

Essas entradas devem ser inseridas nos dois arquivos:
/etc/lvm/backup/fedora
/etc/lvm/archive/fedora_00000-427671572.vg

MUITA, mas muita atenção na posição em que as informações devem ser inseridas.

Testando a recuperação do volume:
# vgcfgrestore fedora --test -f /etc/lvm/archive/fedora_00000-427671572.vg
  TEST MODE: Metadata will NOT be updated and volumes will not be (de)activated.
  Restored volume group fedora


Observação:
O meu VG se chama fedora, você deve alterar o comando de acordo com o nome do seu VG. Nenhuma mensagem de erro? Então você fez tudo certinho, caso contrário, reveja suas configurações.

Recuperando o volume:
# vgcfgrestore fedora -f /etc/lvm/archive/fedora_00000-427671572.vg
  Restored volume group fedora


Verificando o status do volume:
# lvscan
  ACTIVE            '/dev/fedora/root' [9,77 GiB] inherit
  ACTIVE            '/dev/fedora/swap' [512,00 MiB] inherit
  ACTIVE            '/dev/fedora/home' [101,32 GiB] inherit
  inactive          '/dev/fedora/dados' [298,09 GiB] inherit


Ativando o volume:
#  vgchange -ay
  4 logical volume(s) in volume group "fedora" now active


Verificando o status do volume:

# lvscan
  ACTIVE            '/dev/fedora/root' [9,77 GiB] inherit
  ACTIVE            '/dev/fedora/swap' [512,00 MiB] inherit
  ACTIVE            '/dev/fedora/home' [101,32 GiB] inherit
  ACTIVE            '/dev/fedora/dados' [298,09 GiB] inherit


Montando o volume:

# mkdir /Dados
# mount /dev/fedora/dados /Dados/


Verificando os dados:
# ls -l /Dados/
total 23927780
      4 drwxr-xr-x. 10 deo  deo        4096 Jun 14 17:44 .
      4 dr-xr-xr-x. 20 root root       4096 Jun 23 15:29 ..
      4 drwx------.  2 deo  deo        4096 Mar 24 08:47 centos-6.5-pe-3.7.0-ptb2.13-vbox
8388648 -rw-------.  1 deo  deo  8592031744 Jan  4 00:57 CentOS 7 - Zabbix Server.vdi
8388648 -rw-------.  1 deo  deo  8592031744 Jan 28 00:13 CentOS Scripts.vdi

# df -kh
Sist. Arq.                Tam. Usado Disp. Uso% Montado em
/dev/mapper/fedora-dados  294G   93G  186G  34% /Dados

Outros cenários

Caso seu problema seja mais complexo, talvez por ter dividido o LV entre os discos, ou então tenha um LV com vários segmentos, decorrente de expansões alternadas de diferentes volumes lógicos, creio que ainda assim seja possível fazer algum procedimento para sua recuperação. Se conseguir fazer o dump do metadado e tiver o conteúdo do disco razoavelmente preservado, o pior que pode acontecer é você ter que calcular o início e final de cada segmento, recortá-los, possívelmente com um dd, especificando valores para skip e count, e juntá-los na ordem correta.

Escrito a 4 mãos pelo mestre Ariel e por esse humilde ser, dono do blog ;-)

Referencias

PissedOffAdmins
ADAMS BROS BLOG
serverfault.com

terça-feira, 26 de maio de 2015

Manipulação de arquivos via SCP, Rsync e Scripts por Chave Pública

Introdução

Nos posts anteriores [1, 2] eu ensinei a criar um par de chaves publica/privada através de utilitários no Windows e no Linux, e como acessar os servidores utilizando essas chaves.

Nesse post eu vou demonstrar como criar chaves sem senha que serão utilizadas para realizar cópias de arquivos via scp e rsync, e em servidores onde existe a necessidade de realizar cópias automatizadas (via scripts), dispensando assim a necessidade de digitação e/ou armazenamento de senhas.

O servidor que recebe o arquivo será tratado neste documento como Servidor Destino e o servidor que envia o arquivo como Servidor Origem.
Lembrando que se existir a necessidade dos servidores trocarem arquivos entre si, será necessário realizar os dois procedimentos (origem e destino) em ambos os servidores.

Procedimentos Servidor Origem

Gerar o par de chaves Pública/Privada

# ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/home/teste/.ssh/id_rsa): <ENTER>
Created directory '/home/teste/.ssh'.
Enter passphrase (empty for no passphrase): <ENTER>
Enter same passphrase again: <ENTER>
Your identification has been saved in /home/teste/.ssh/id_rsa.
Your public key has been saved in /home/teste/.ssh/id_rsa.pub.
The key fingerprint is:
79:2d:88:c4:35:1e:be:8f:f2:c1:df:dc:ae:27:b0:39 teste@private.localhost
The key's randomart image is:
+--[ RSA 2048]----+
|        +        |
|     . + o       |
|      o o        |
|     . . + .     |
|      . S o .    |
|       . +..     |
|      . + .+     |
|       o oEo...  |
|        . ..+=o  |
+-----------------+


Observações
Created directory '/home/teste/.ssh'. - Aparece apenas na primeira vez que a chave é criada;
Enter passphrase (empty for no passphrase): - É a senha para sua chave privada, nesse caso vamos criar uma chave sem senha, portanto basta pressionar Enter.

Copiar a Chave Pública

# cat /home/teste/.ssh/id_rsa.pub
ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAxka6+ntfEcwUMCXYRpCS9im8yJrlyp/+LhFh3K/X0Ad5QPUlUTTklZ2bDps4CdKNbQf/6T4j1nu/ylJwUHBBJyK6y8uZDXCjCtjCcZfLsO8pSLjsmYJfKqXeD50y+zSYqC9GB+HeQf+It09unQt5gTvGtfgWdKzq2hchfpkEEgWQD0mKyQZAl5cU2SbmLMJV8YxfBpwAONyj7ARKtUrkW3XcVa+QKFdYFTfHshMdcBCAsGuO6tDFmWSRjcEkYHgyNaaeIufOwHPvLzs4TVk3/NmOC1Pd1bYUcmEQslL0U6UPun9X8A6aNs3eu6JgOWWifze6bxgshp9dKVJHlgAxbQ== teste@private.localhost


Copie esta chave para um txt temporário, pois ela será necessária no Procedimento Servidor Destino. Obs.: As informações da chave acima estão em uma única linha.

Procedimentos Servidor Destino

Criar o usuário e configurar o acesso via chave

Crie o usuário no Linux
# adduser teste

Entre no diretório do usuário
# cd /home/teste/

Crie o diretório.ssh
# mkdir .ssh

Acesse o diretório
# cd .ssh/

Crie o arquivo authorized_keys
# vi authorized_keys

Dentro desse arquivo você vai colocar o conteúdo da chave pública, aquela que você colou em um arquivo temporário. Tenha certeza de que não houve quebra de linha.

Uma boa prática é colocar uma linha com a identificação do servidor:
# Servidor 01
<CHAVE>

# Servidor 02
<CHAVE>

Dica do grande amigo Andreyev

Altere as permissões do diretório
# chmod 700 .

E do arquivo
# chmod 600 authorized_keys

E por último de todo o diretório .ssh
# chown -R teste:teste /home/teste/.ssh

Testar a conexão - Partindo do Servidor Origem

# ssh teste@servidor_destino

The authenticity of host '[servidor_destino]:1922 ([192.168.100.2]:22)' can't be established.
RSA key fingerprint is 3e:99:b4:aa:c6:8a:e2:e0:e0:55:d4:f8:01:76:2a:8b.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '[servidor_destino]:22,[192.168.100.2]:22' (RSA) to the list of known hosts.
[teste@servidor_destino ~]$
[teste@servidor_destino ~]$ logout
Connection to servidor_destino closed.


Observações:
Essas mensagens informando que a conexão não foi possível e que vai adicionar o host ao arquivo know hosts só aparece na primeira conexão.

Copiar um arquivo do Servidor Origem para o Servidor de Destino usando scp

# scp teste.txt teste@servidor_destino:/home/teste
teste.txt                                     100%    0     0.0KB/s   00:00


Copiar um arquivo do Servidor Origem para o Servidor de Destino usando rsync

# rsync -Cravzp teste teste@servidor_destino:/home/teste/
sending incremental file list
teste/
teste/teste.txt
teste/teste01.txt
teste/teste02.txt
teste/teste03.txt

sent 270 bytes  received 92 bytes  724.00 bytes/sec
total size is 0  speedup is 0.00


Observações:
Se você mudar a porta do SSH nos Servidores a sintaxe dos comandos passam a ser:
# scp -P 2891 teste.txt teste@servidor_destino:/home/teste

# rsync -Cravzp --rsh='ssh -p
2891' teste teste@servidor_destino:/home/teste/

Os mesmos procedimentos podem ser usados em scripts, sem a necessidade de senhas.

Observação:
Todas as recomendações de segurança dos posts anteriores devem ser implementadas.

terça-feira, 19 de maio de 2015

Acesso via SSH por Chave Pública entre Servidores Linux

Introdução

No post anterior ensinei a criar um par de chaves publica/privada através de utilitários no Windows, e acessar um servidor Linux.
Agora vou demonstrar como gerar o seu par de chaves em um servidor Linux, tratado neste post como Servidor Origem, como disponibiliza-la em outros servidores que você deseja acessar, tratados neste post como Servidor Destino. E por último, mas não menos importante, como importar essa chave para ser utilizada nos utilitários no Windows.

Gerar o par de chaves Pública/Privada no Servidor Origem

# ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/home/teste/.ssh/id_rsa): <ENTER>
Enter passphrase (empty for no passphrase):
<SENHA DA CHAVE PRIVADA>
Enter same passphrase again:

<SENHA DA CHAVE PRIVADA> 
Your identification has been saved in /home/teste/.ssh/id_rsa.
Your public key has been saved in /home/teste/.ssh/id_rsa.pub.
The key fingerprint is:
fc:21:f9:9f:1e:45:9d:3f:fa:40:45:70:d6:bb:7f:b1 teste@private.localhost
The key's randomart image is:
+--[ RSA 2048]----+
|             ..+.|
|              +.o|
|              .oo|
|       . .   ....|
|        S .  ...o|
|         + ....o.|
|          o .o  +|
|           . ooEo|
|           .+  ..|
+-----------------+


Observações:
Created directory '/home/teste/.ssh'. - Aparece apenas na primeira vez que a chave é criada;
Enter passphrase (empty for no passphrase): - É a senha para sua chave privada, quanto maior a frase maior a segurança da chave. Quando fornecendo uma frase-chave, ela não é exibida na tela (nem mesmo *s aparecerão).

Copiar a Chave Pública

# cat /home/teste/.ssh/id_rsa.pub
ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEA1iQX//ED02Ranp2M4GD4uQCVtDjMg5nArtUDz0Voblvz02fcnmUePu36TU85q6eHf4RlR3z/w0wNmz4b4haQRoMmIMZSi4TxYZKtyUIHipiQkCt+TpLNZm9chekLCn5pMGB4DSpL2XJC5N2Yw12w5HNKvAXZOUqUnKK+lX5G/YYM+Td0p/t+PG3E3ZjSy9kMDDpc61uGz/BjnIvrSFj+rot5l5tn2mynmfb4lhTkLE+0Ot30+q+s9IkK7J33+Y4cpEX+jMb4MvfdEyUUnjjZPgGlaXggsaKrE5ZMUhGvmIX0t/b81DRxtpI+1iu01/GHOUZ5EoSTo/EsUAViXrPV6w== teste@private.localhost


Copie esta chave para um txt temporário, pois ela será necessária no Procedimento Servidor Destino. Obs.: As informações da chave acima estão em uma única linha.

Procedimentos Servidor Destino

Criar o usuário e configurar o acesso via chave

Crie o usuário no Linux
# adduser teste

Entre no diretório do usuário
# cd /home/teste/

Crie o diretório.ssh
# mkdir .ssh

Acesse o diretório
# cd .ssh/

Crie o arquivo authorized_keys
# vi authorized_keys

Dentro desse arquivo você vai colocar o conteúdo da chave pública, aquela que você colou em um arquivo temporário. Tenha certeza de que não houve quebra de linha.

Altere as permissões do diretório
# chmod 700 .

E do arquivo
# chmod 600 authorized_keys

E por último de todo o diretório .ssh
# chown -R teste:teste /home/teste/.ssh

Testar a conexão - Partindo do Servidor Origem

$ ssh teste@servidor_destino
The authenticity of host '[servidor_destino]:22 ([192.168.100.2]:22)' can't be established.
RSA key fingerprint is 3e:99:b4:aa:c6:8a:e2:e0:e0:55:d4:f8:01:76:2a:8b.
Are you sure you want to continue connecting (yes/no)? <yes>
Warning: Permanently added '[servidor_destino]:22,[192.168.100.2]:22' (RSA) to the list of known hosts.
Enter passphrase for key '/home/teste/.ssh/id_rsa': <SENHA DA CHAVE>
Last login: Wed May 13 17:43:38 2015 from servidor_origem
 

[teste@servicor_destino ~]$ logout
Connection to servidor_destino closed.


Observações:
Essas mensagens informando que a conexão não foi possível e que vai adicionar o host ao arquivo know hosts só aparece na primeira conexão.

Converter a chave gerada no Linux para ser usada no Putty

Pode ser necessário em algum momento utilizar essa chave gerada no Linux, para acessar o Servidor Destino a partir de uma máquina Windows, para isso será necessário converter a chave, mas o processo é bem simples.
Copie a chave para o Windows e abra o Puttygen

Na tela principal clique em Load

Mude o tipo de arquivo para All Files e selecione a chave privada gerada no Linux

Digite a senha da sua chave privada

Será exibida a mensagem que a chave foi importada com sucesso clique em OK


Agora você pode visualizar a sua chave pública e salvar a chave privada


De posse das chaves devidamente importadas pelo Puttygen, basta seguir o post anterior.Você pode realizar o acesso pelo Windows normalmente, a chave importada contém o mesmo hash da chave original.

Observação:
Todas as recomendações de segurança do post anterior devem ser implementadas. 

terça-feira, 12 de maio de 2015

Acesso via SSH por Chave Pública

 Introdução

A maioria dos administradores de rede toma alguma ação com relação ao serviço de ssh, como, por exemplo, não permitir login como root, alterar a porta default do serviço, tudo isso pode e deve ser feito, mas o objetivo dessa documentação é implementar uma camada a mais de segurança, o uso de chaves.

Isso deve ser implementado em todos os seus servidores, pois mesmo sendo um servidor interno da sua rede, ele ainda está exposto aos atacantes internos e aos ataques automatizados através de botnet. Algum usuário da sua rede pode estar atacando seu servidor sem nem suspeitar disso.

Gerar a chave no Windows

Para gerar a chave no Windows vamos utilizar um utilitário chamado Puttygen. Baixe o executável e inicie o mesmo

A tela inicial já nos vem configurada para chave SSH-2 RSA de 2048 bits, clique no botão Generate.


Movimente o mouse na área sem dados para gerar a senha.


Na parte superior temos a chave pública que será colocada no servidor, selecione o seu conteudo e copie para um txt temporário.

A segunda seleção é onde você deve cadastrar uma senha para sua chave privada, crie a maior senha que você consiga lembrar, se alguém quebrar essa senha você perdeu sua chave privada.

E na última seleção temos a opção de salvar a chave pública e privada. Salve apenas a chave privada.

Configurações no Servidor Linux

Criar o usuário e configurar o acesso via chave

Crie o usuário no Linux
# adduser teste

Entre no diretório do usuário
# cd /home/teste/

Crie o diretório.ssh
# mkdir .ssh

Acesse o diretório
# cd .ssh/

Crie o arquivo.
# vi authorized_keys

Dentro desse arquivo você vai colocar o conteúdo da chave pública, aquela que você colou em um arquivo temporário. Tenha certeza de que não houve quebra de linha (Se você colar no Word já era) - Dica do meu amigo Gesiel.

Altere as permissões do diretório
# chmod 700 .

E do arquivo
# chmod 600 authorized_keys

E por último de todo o diretório .ssh
# chown -R teste:teste /home/teste/.ssh

Testar a conexão

Para se conectar ao servidor Linux vamos utilizar outro utilitário o Putty. Baixe o executável e inicie o mesmo

Em Session informe o IP e Porta do Servidor


Em Connection // Data informe o nome do usuário


Em Connection // SSH // Auth informe o caminho da sua chave privada e clique em Open.

Observe que ele não pede a senha do meu usuário, mas sim a senha da minha chave privada. Aquela que nós definimos no momento da criação da chave.


E agora estamos logados.


Incrementar a segurança do SSH

Uma vez logados com sucesso, chegou a hora de incrementarmos a segurança do SSH no servidor Linux. Para isso execute o login como root e edite o arquivo sshd_config

# vi /etc/ssh/sshd_config
# Alterar a porta padrao
#Port 22
Port 2891

# Proibir login como root, os usuarios devem usar o su -
#PermitRootLogin yes
PermitRootLogin no

# Liberar acesso via chave
#RSAAuthentication yes
#PubkeyAuthentication yes
#AuthorizedKeysFile     .ssh/authorized_keys
RSAAuthentication yes
PubkeyAuthentication yes
AuthorizedKeysFile      .ssh/authorized_keys

# Proibir o acesso via senha
#PasswordAuthentication yes
PasswordAuthentication no


Se o servidor em questão for um FreeBSD altere também a diretiva abaixo:
ChallengeResponseAuthentication no

# service sshd restart

Testar acesso com usuário e senha

Ao tentar se logar passando um nome de usuário a mensagem abaixo é exibida


Pronto! Basta acessar passando a sua chave privada e a porta correta ;-)

Referências

Locaweb
Man sshd_config
Fórum FreeBSD

sexta-feira, 13 de fevereiro de 2015

O livro já está sendo vendido no site da Novatec!

Bom dia, pessoal!

Há poucas horas, o livro começou a ser vendido na Novatec com 25% de desconto até o dia 28/02/2015.

Acesse o link abaixo para saber como comprar o livro com o desconto.
http://zabbixone.com/?p=151

Boa leitura!

quarta-feira, 21 de janeiro de 2015

Livro “De A a Zabbix” será publicado pela Novatec


Desde 2011 Eu, Adail Spínola e Aécio Pires estávamos escrevendo um livro sobre Zabbix. Graças a Deus, já temos uma previsão de que ele seja publicado no mês que vem. :-)

Saibam mais sobre o livro aqui: http://zabbixone.com/?p=68

O site da Novatec já está divulgando o livro no final da página inicial, na seção de próximos lançamentos. http://www.novatec.com.br/


O livro tem o apoio de Alexei Vladishev, criador do Zabbix, e Luciano Alves, proprietário e fundador da UNIREDE, empresa representante do Zabbix na América Latina e que aplica a certificação Zabbix no Brasil.

Ainda não é possível comprar o livro através da pré-venda e também não sei a estimativa de preço, mas logo logo você saberá. Aguarde e acompanhe as novidades no site do livro http://zabbixone.com.
 
Se você é aluno ou professor na área de Redes de Computadores, saiba que o livro pode ser utilizado na disciplina de gerenciamento e monitoramento de redes de computadores. O conteúdo do livro também vai de encontro ao assunto ensinado na certificação Zabbix.