Mostrando postagens com marcador SSH. Mostrar todas as postagens
Mostrando postagens com marcador SSH. Mostrar todas as postagens

quinta-feira, 22 de dezembro de 2011

Script para Automatizar Conexões SSH

Se você é um solicitado administrador de redes, um responsável por uma lan house ou um laboratório Linux ou mesmo um usuário avançado, certamente já se viu na situação de ter de abrir várias sessões de SSH para máquinas diferentes com grande freqüência. Normalmente, isto não é problema algum, mas muitas vezes é chato e cansativo se digitar tantos parâmetros para abrir a conexão.
Se este é o seu problema, o script abaixo poderá lhe ajudar muito!!



  • Mas, o que ele faz??
Ele automatiza o comando do SSH retirando alguns dos indicadores de parâmetros, como o "-p".


  • Como Devo Usá-lo??
Primeiramente, grave o script com um nome sugestivo, como "fastssh.sh", colocando-o em um diretório dentro de seu PATH (por exemplo, o /usr/bin), para que possa ser executado de qualquer diretório.
Não se esqueça de determinar a permissão de execução para todos os usuários, com o comando:

chmod +x fastssh.sh


Agora, imagine que você tem dois servidores que precisam ser acessados rotineiramente, com as seguintes configurações:

nomes: "server1.dominio.com" e "server2.dominio.com".
porta do SSH: 1000.
usuário: "pele".

OBS1: é sempre recomendável, para garantir maior segurança, que o SSH utilize uma porta fora do padrão!!
OBS2: Cuidado!! Normalmente, não é recomendável se conectar em servidor diretamente como "root".

Você deverá criar então 2 arquivos bem simples:

server1.sh:
fastssh.sh server1.dominio.com 1000 pele

server2.sh:
fastssh.sh server2.dominio.com 1000 pele

Faça os dois arquivos se tornarem executáveis (utilizando o mesmo comando "chmod", conforme mostrado acima) e coloque-os igualmente em uma pasta como o /usr/bin (ou qualquer outra que esteja no seu PATH).
Pronto!! Parabéns, agora, para se conectar a qualquer um dos servidores, basta somente se chamar o script correspondente, digitando-se "server1.sh" ou "server2.sh".


  • Conclusões
Este artigo foi bem simples e mostrou uma técnica de automatização extremamente útil e a que, muitas vezes, na pressa do dia-a-dia nós não atentamos e não utilizamos. Muitas vezes, são nas tarefas mais banais onde se perde mais tempo... Assim, fica aqui a dica e o script, testado e pronto para entrar em funcionamento na sua rede!!

terça-feira, 26 de janeiro de 2010

Os Modos de Configuração do SVN (Server Configuration)

O SVN (ou Subversion) é um controlador de versões dentre os mais populares, que pode ser usado não só por desenvolvedores, mas por qualquer um que queira fazer cópias de segurança versionadas de seus arquivos de trabalho, quaisquer que sejam estes.
Este artigo explana sobre os 3 modos de configuração do servidor. Note que nossa intenção não é ensinar como se configura cada modo detalhadamente, mas apenas descrever e caracterizar o seu uso, para contribuir na escolher mais apropriada. Há um outro artigo contendo um tutorial de configuração mais avançado, que pode ser acessado aqui.

  • Modo Serviço
Este é o modo mais simples e fácil de configurar. Muito possivelmente deve ser o primeiro a ser testado, para quem está configurando o subversion pela primeira vez. Neste modo, o SVN entra em cena como um serviço (deamon) e fica rodando ininterruptamente, esperando por requisições.

Suas principais características: fácil e rápido de configurar, funciona mais rápido, não usa senhas nem configuração de contas no SVN.

Como funciona?
O administrador inicia o SVN no boot do linux, como um serviço, ou digitando o comando:

svnserve -d

(-d de deamon, para iniciar o serviço). Lembre-se de liberar no firewall a porta padrão: 3690, ou especifique outra porta, com as opções --listen-port= e --listen-host= no servidor e no cliente svn.
O usuário deve ter uma conta no sistema linux e vai usar a sua conta para acessar o serviço. O acesso deve usar o protocolo svn://, como no exemplo:

svn checkout svn://maquina/opt/svn/projeto

Desvantagens: todo mundo que vai usar precisa ter uma conta no sistema!! Além disso, este modo expõe o caminho do repositório, não tem encriptação ou qualquer forma de segurança, não exige senhas e está sujeito a problemas de permissão de arquivos e diretórios (que vira rapidamente um verdadeiro inferno, mesmo para poucos usuários!!).

Recomendamos para situações muito simples, como:
- Um usuário que quer manter um backup mais ou menos constante de algumas pastas de seu diretório de trabalho (em outra partição do HD ou outro local externo qualquer, como um HD externo ou um super pendrive) .
- Pode ser usado por grupos muito pequenos de desenvolvedores, como um grupo da faculdade, um grupo de colegas, etc., que resolveram montar um servidor a partir de uma máquina antiga para desenvolver um projeto único e específico, num prazo pequeno e temporário.

Nestes casos, não se perde tempo com configurações sofisticadas e não se deixa de aproveitar as incríveis vantagens de se ter o trabalho todo versionado. Não esqueça de fazer backups constantes e de procurar manter o repositório em um local diferente, como outra partição ou outro HD.


  • SVN sobre SSH

Esta é uma opção semelhante à anterior, porém com a segurança dos dados transmitidos e recebidos sempre sobre um túnel de SSH. Ela é possível porque o SSH permite que seja passado, via linha de comando, um argumento contendo o comando a ser chamado após aberta a conexão. Isto provoca um tunelamento: o SSH abre a conexão, roda imediatamente o comando (o svnserve -t) e fecha automaticamente a conexão, depois que o comando terminou de executar.
Nesta opção, o SVN não precisa ser carregado na memória como serviço. Na verdade, ele é carregado com a opção "-t" (de tunnel) e encerrado a cada requisição. Todo o tráfego de dados ocorre pela entrada e saída padrão, via SSH.
O servidor pode ser acessado pelo protocolo svn+ssh://, como no exemplo:

svn checkout svn+ssh://usuario@maquina/opt/svn/projeto
usuario@maquina's password: ******

Importante:
- É preciso liberar a porta do firewall para o SSH tornar-se acessível.
- O segredo deste modo está na configuração correta do SSH, que não poderá enviar mensagens de boas-vindas, pois, como o tráfego é via entrada e saída padrão, estas mensagens vão gerar erros de interpretação no SVN. Um artigo que escrevi ensinando a configurar o SSH para o SVN funcionar corretamente pode ser encontrado aqui.
- Todos os usuários precisam ter contas no sistema linux do servidor e, portanto, é preciso que se tome muito cuidado com as permissões do usuário para acessar o repositório.

Recomendamos para:
- Grupos de desenvolvedores, em locais diferentes, que acessam o servidor pela internet ou intranet.


  • Modo WebDAV: Usando o Serviço HTTP ou HTTPS do Apache
Este é o modo mais sofisticado, mais flexível e seguro, sendo largamente utilizado, especialmente para grandes projetos com inúmeros desenvolvedores.
Funciona da seguinte maneira: apenas um usuário vai realmente acessar o subversion. Este usuário será utilizado pelo servidor HTTP Apache, pois este servidor pode incluir um módulo que suporta o protocolo WebDAV/DeltaV, uma extensão do HTTP que permite a usuários autenticar-se e autorizar-se para manipular arquivos remotamente, de forma colaborativa. O usuário remoto apenas faz as chamadas HTTP para o Apache, que as traduz para o SVN. Este protocolo pode, obviamente, ser encriptado via SSL, tornando o tráfego mais seguro.

Vantagens:
- Não é preciso criar contas locais para os desenvolvedores;
- É possível se obter todas as vantagens do servidor HTTP Apache, como a encriptação via SSL, uso do Apache Logging e uma navegação gráfica pelo repositório na tela do navegador;
- O repositório pode ser montado como um dispositivo (drive) de rede;
- Pode ser integrado com LDAP, Active Directory, NTLM e congêneros.

Desvantagens:
- Certamente, é muito mais lento, devido à complexidade e à multiplicidade de camadas;
- É muito mais complexo de se configurar;
- Necessita de um servidor mais poderoso, para rodar o SVN e o Apache com todos os requisitos do WebDAV e suportando múltiplas Threads sem perda de desempenho (o módulo mod_dav_svn do Apache necessita do Apache 2).


  • Finalizando...

Uma excelente tabela comparativa entre os 3 modos pode ser encontrada aqui.

- Os seus dados estão sempre no repositório, e não no SVN. O repositório pode sofrer Dumps e backups, podendo ser acessado de diferentes formas e modos. Seus dados podem ser exportados e importados para outros repositórios. Portanto, começar usando um modo mais simples não o impede de, mais tarde, reconfigurar o SVN e migrar para o Apache com WebDAV.

- Preocupe-se em escolher o modo que mais se encaixa no seu contexto de trabalho: não vale a pena perder horas instalando e configurando corretamente o Apache 2, o módulo DAV e o SVN para um projeto muito pequeno e de poucos desenvolvedores. Por outro lado, um projeto grande e importante não pode ficar sujeito a criação de muitas contas no servidor, problemas de permissão e acessos sem segurança...

- O que quer que você faça: sempre mantenha rotina de backup e, se possível, use o repositório em outro local diferente da partição ou disco onde está instalado seu sistema. Se algo der errado e seu sistema de arquivos se corromper, os dados estarão sempre seguros...

Configurando o SVN com Tunelamento por SSH

O SVN, ou subversion, é um dos mais utilizados controladores de versão da atualidade. Muito estável, leve e seguro, (além de gratuito!) está presente nas redes de inúmeras importantes empresas e máquinas pessoais. É também um sistema flexível que permite diversos modos de operação; a saber: diretamente, via conta linux; acesso via túnel de SSH; acesso via HTTP e porta 80. Este artigo trata de todos os passos necessários para configurar seu SVN para ser acessado via tunelamente por SSH. Uma análise detalhada sobre as características, vantagens e desvantagens de cada um dos três modo pode ser encontrada no artigo anterior desta série, clicando-se aqui. Importa que leia um artigo nosso que trata da configuração do SSH para usar o SVN: Alterando ou Desabilitando as Mensagens do SSH.

  • Criando um Repositório do SVN

Os dados versionados, no SVN, ficam em repositórios. Você pode ter quantos repositórios quiser, e cada repositório pode ter vários diretórios (projetos) com arquivos e subdiretórios dentro. Cada repositório tem uma variável chamada revision, que é um inteiro, iniciado em 0 (zero) com a criação do repositório, e que sofre incremento a cada vez que uma nova revisão de um ou mais arquivos é adicionada ao repositório.
Para criar o repositório, basta digitar:

svnadmin create --fs-type bdb [nome_do_repositorio]

o argumento --fs-type indica qual tipo de sistema de arquivos vai ser utilizado. Existem dois tipos: o bdb e o fsfs. Os dois funcionam muito bem, mas têm pequenas diferenças. Sugiro o bdb (Berkeley DB). Você pode achar mais informações sobre este detalhe aqui.

Note que o seu repositório é um diretório com uma determinada estrutura:

$ ls
conf db format hooks locks README.txt

Não precisamos mudar quase nada aqui, apenas um diretório: o diretório "db".

  • Tornando o Repositório SVN Acessível

Agora que já temos o repositório, vamos seguir os seguintes passos para terminar a configuração:

1- É preciso que todos os usuários que vão usar o SVN estejam no mesmo grupo do sistema (UNIX Group). Vamos supor que nós criamos uma conta de usuário para cada usuário e um grupo chamado "svnusers", e adicionamos todos os usuários a este grupo. Foge ao escopo deste artigo ensinar como manipular contas no Linux, mas você pode achar (de forma bem detalhada!) tudo o que precisa bem aqui.

2- Agora vamos dizer para o sistema que o diretório "db" do nosso repositório e todos os seus arquivos devem estar liberados para leitura e escrita por todos os usuário do grupo "svnusers". Este passo é importantíssimo, pois evitará os famosos problemas de permissão de leitura e escrita... note que é importante fazer o procedimento não só para o conteúdo do diretório "db", mas também para o próprio diretório, pois, durante o uso, o svn tenta criar alguns arquivos novos no diretório "db".

Mudando o grupo dono do diretório "db" e seus arquivos:

cd [diretório_do_repositório]
chgrp svnusers db
cd db/
chgrp svnusers *

Adicionando-lhes permissão de leitura e escrita para o grupo "svnusers":

cd [diretório_do_repositório]
chmod g+rw db
cd db/
chmod g+rw *

Beleza, você venceu os passos principais!!!

  • Testando o Acesso ao Repositório SVN

1- Se você vai acessar o SVN pelo SSH, então é preciso que o SSH esteja instalado, rodando e configurado para receber conexões. É preciso também que ele não emita mensagens de boas-vindas, pois isto irá confundir o cliente do SVN, que vai interpretar o texto como erro de leitura de dados e vai interromper a conexão. Sobre como fazer isto tudo, já deixei um artigo prontinho e bem detalhado aqui.
2- Verifique o firewall de sua máquina para não bloquear nem a porta do SVN (a porta padrão é 3690, mas pode estar configurada qualquer outra porta) nem a porta do SSH (a padrão é a 22, mas igualmente pode estar configurada para qualquer outra).
3- Configure seu cliente SVN para acessar o repositório pelo seguinte endereço:

svn+ssh://[nome_ou_ip_da_máquina]/[caminho_completo_do_repositório]

Exemplos:

svn+ssh://192.168.0.1/opt/repositorio
svn+ssh://server01/var/bin/svnrepos/repositorio32
svn+ssh://maquina.dominio/opt/repositorionovo


Bom, encontrei muitos tutoriais incompletos sobre o assunto, e alguns que, embora completos, não detalhavam o porquê das coisas, dificultando a vida do administrador... assim, espero ter ajudado com este humilde tutorial!! Por isso... COMENTEM!!!!

domingo, 25 de outubro de 2009

Alterando ou Desabilitando as Mensagens do SSH

O SSH é um excelente mecanismo para acessar remotamente uma máquina. Seguro, rápido, eficiente. Tão eficiente que pode ser utilizado para outros fins, como o tunelamento via SSH para o SVN, um sistema de controle de versão, ou mesmo para tunelar o protocolo do X11 e exportar o modo gráfico da máquina remota para a máquina cliente.
Por padrão, o SSH normalmente imprime uma série de mensagens no momento do acesso. Estas mensagens variam de máquina para máquina e de distribuição para distribuição, mas podem ser todas removidas ou alteradas. Em alguns casos, é imperativo a sua remoção, como quando se utiliza o SSH para tunelar o SVN, com o esquema "svn+ssh". A não remoção destas mensagens causa erros no protocolo do SVN, que não consegue "entender" os dados da mensagem, (que, obviamente, não fazem sentido para ele), e normalmente imprime uma mensagem de erro como "svn: Malformed network data".
Então, como mudo ou removo as mensagens do SVN?? Muito simples, basta seguir os passos:

1- Logue-se como root e edite o arquivo abaixo:

vi /etc/ssh/sshd_config


A primeira coisa que se pode editar é a mensagem de "Banner". Procure a linha:

Banner etc/issue.net


Para eliminar a mensagem, basta comentar esta linha (colocando a tralha - "#" - na frente). Outra opção é editar o arquivo de mensagem que a linha referencia (no exemplo acima, o arquivo /etc/issue.net) e modificá-lo, alterando a mensagem ou deixando-o vazio.

Mas não é só isso!!
Muitas vezes, o ssh imprime a informação de data e hora do último login. Esta informação é particularmente útil e importante para controle e segurança do acesso. No entanto, pode ser um pé-no-saco para tunelamento de SVN pelo esquema svn+ssh. Para removê-la, ainda no mesmo arquivo, procure a opção "PrintLastLog yes" e modifique-a para:

PrintLastLog no


Apenas isto elimina todas as mensagens em algumas distribuições. Porém, outras distros têm mensagens de sistema que costumam aparecer em ocasiões como o login do ssh. Estas mensagens podem ser encontradas no arquivo:

/etc/motd


Se este arquivinho existir, ele deve conter apenas texto estático que é copiado para o stout no momento do login (na verdade, ele pode ser um link simbólico para /var/run/motd); para eliminar o texto, basta editar o arquivo e apagar todas as linhas, ou apagar o arquivo de link simbólico.

Importante: não esqueça de reiniciar o sshd para que as mudanças tenham efeito:

/etc/init.d/ssh restart


Outra coisa importante é sempre fazer backup dos arquivos de configuração que você modificar, caso precise retroceder as alterações!!


  • Aprimorando a Segurança do SSH

Independente do que foi comentado acima, você pode - e muitas vezes deve!! - adotar algumas medidas de segurança que vão garantir a sua paz e tranquilidade, ainda que seu SSH não tenha mensagens de Last Log, etc.
A primeira coisa a fazer é abrir o arquivo "/etc/ssh/sshd_config" e adicionar (ou configurar) as seguintes linhas:

Port 10000 - Esta linha identifica a porta que vai ser usada tanto para o ssh quanto para o sftp. A porta padrão é "22", então não preciso nem dizer que 99,9% dos ataques vão direto para esta porta. Troque a porta para qualquer outra. No exemplo, coloquei a porta 10000. Portas altas tendem a ser mais seguras.

PermitRootLogin no - Este é o essencial do essencial... nunca permita o login do root. Você pode administrar o que quiser remotamente se você logar como um usuário comum e se tornar root posteriormente, com o comando "su". Não permita que o root fique propenso a ataques!!

AllowUsers beltrano cicrano - Este é um comando de white list (lista branca). Permite que você configure exatamente e exclusivamente quem pode conectar. Se esta linha estiver presente, um usuário que não contiver seu nome ali jamais será autorizado a conectar. É uma técnica muito restritiva, mas útil em muitos casos.

PermitEmptyPasswords no - Este é outro comando essencial do essencial... nunca permita que um usuário maluco defina sua senha como vazia e deixe sua conta exposta ao acesso remoto... virtualmente qualquer um poderá conectar como este usuário e ele poderá ser usado para ataques contra o root ou para derrubar a máquina!!

X11Forwarding no - A menos que você tenha a intenção (e necessidade!!!) de rodar o modo gráfico remotamente, defina este comando como "no". Se for "yes", você poderá tunelar via ssh o modo X, rodando remotamente qualquer programa com interface gráfica, que será exportada para a sua máquina local. Isso é uma ótima idéia dentro de uma intranet, mas pela internet é péssimo. O protocolo X não é comprimido nem foi desenvolvido para acesso remoto e, por isso, é lento e complicado... liberar o X para os usuários implica em correr sério risco de engarrafar a sua rede por excesso de carga!!

Bom, espero ter ajudado!! E, claro, COMENTE!!!