A ideia é, tendo contratado um servidor virtual privado, qual o caminho mais rápido para começar a desenvolver?
Neste primeiro post, vamos instalar o Apache 2 e ajustar as configurações necessárias para acessar seu servidor através de um domínio registrado e com um firewall para filtrar as portas.
O serviço que eu contratei foi com a Locaweb coff o mais barato que eu achei coff, e eles entregam o servidor com o sistema operacional já instalado, que foi o Debian 9 (stretch).
Após logar como root, o primeiro objetivo é criar um usuário com permissões normais, mas que possa agir como super quando necessário. Isso cria uma barreira para que você não faça nenhuma cagada.
$ adduser nome-do-usuario
Agora, adicionamos ele ao grupo sudo
$ usermod -aG sudo nome-do-usuario
Precisamos também permitir que o novo usuário consiga acessar o servidor. A forma como isso vai ser feito depende de como você configurou o login do usuário root.
Se você configurou o usuário root com acesso SSH, pode criar uma nova chave, ou utilizar a mesma do root.
Para criar uma nova chave, no seu computador:
$ ssh-keygen –t rsa
Se você possui chaves ligadas a outros serviços (github por exemplo), evite sobrescrevê-las, respondendo a pergunta Enter file in which to save the key (/home/nome-do-usuario/.ssh/id_rsa) com
$ /home/nome-do-usuario/.ssh/id_rsa_meuserver
ou algo do tipo.
Agora, copie a chave que você gerou, pois vai precisar adicioná-la no servidor.
Agora você já pode acessar com ssh usando seu novo usuário.
Em um novo terminal, faça login utilizando seu novo usuario:
$ ssh seu_usuario@seu_servidor
Verifique que você está no grupo sudo:
$ groups
Deve listar algo do tipo:
seu_usuario root
Verifique que você consegue rodar programas como super:
$ sudo ls -la /root
Caso você receba o erro "sudo command not found", no servidor, como root, rode:
$ apt-get install sudo
Caso a instalação peça para substituir o arquivo /etc/sudoers, mantenha o original. Você pode também precisar adicionar o usuário manualmente pelo arquivo:
$ vim /etc/sudoers
e adicione as seguintes linhas ao final do arquivo:
# permite acesso completo aos usuários do grupo sudo
%sudo ALL=(ALL:ALL) ALL
# especifica os privilégios do usuário root
root ALL=(ALL:ALL) ALL
Rode o comando anterior com o prefixo sudo. Se tudo ocorrer bem, pode fechar a conexão com o usuário root e seguir com seu novo user.
Instalando o Apache 2 e restrições básicas de acesso
Para direcionar a um domínio, comece criando um diretório para o projeto:
Com a instalação do apache, esperam-se acessos na porta 80 (http) ou 443 (https) o que pode trazer riscos de segurança se os outros acessos do servidor não forem filtrados.
Isso pode ser feito, no Debian, através do iptables, que regula as permissões de acesso ao servidor, ou utilizando o programa ufw (Uncomplicated Firewall) que serve como um front-end para o iptables, visando simplicidade no uso.
$ apt-get install ufw $ apt update
Vamos nos certificar, antes de ativar o firewall, de manter o acesso ssh aberto, para que não fiquemos trancados pra fora do servidor.
O comando abaixo nos mostra as aplicações que podem ser liberadas usando o ufw
$ ufw app list
Liberaremos, então, conexões SSH através do OpenSSH.
$ ufw allow OpenSSH
Podemos ver as conexões permitidas com:
$ ufw status
Verifique na listagem se você possui a ação ALLOW para OpenSSH
To Action From
-- ------ ----
OpenSSH ALLOW Anywhere
OpenSSH (v6) ALLOW Anywhere (v6)
Agora o firewall pode ser ativado com:
$ ufw enable
A instalação do Apache 2 é feita com o comando:
$ sudo apt install apache2
Um erro comum é que alguns programas podem aparecer como não instalados:
dpkg: warning: 'ldconfig' not found in PATH or not executable.
dpkg: warning: 'ufw' not found in PATH or not executable.
Verifique como está configurado seu $PATH:
$ echo $PATH
Um erro comum é que alguns diretórios não tem seus arquivos verificados por padrão. Caso o seu retorno for parecido com:
E então reiniciar o Apache para implementar as mudanças:
sudo systemctl restart apache2
Falta apenas criar um apontamento, no seu domínio, para o servidor. O processo pode mudar dependendo de onde foi comprado o domínio, mas a ideia é criar um record A apontando para o IP do servidor
No registro.br o processo ocorre da seguinte forma: Dentro da sua conta, entre nas configurações do domínio, e vá até a aba DNS.
Clique em EDITAR ZONA. Caso for sua primeira alteração no domínio, vai ser emitido um alerta quanto à demora de propagação das alterações, segurança, etc.
Talvez você tenha que esperar até meio hora para cadastrar os records.
Crie um registro A apontando para o IP do seu servidor.
Você pode conseguir o IP com o código:
$ hostname -I
Opcional: criação de registro A em www. para o IP do servidor.
Após os registro, seus apontamentos devem estar no seguinte formato:
Apontamentos finalizados no REGISTRO BR.
Instalando seu próprio servidor Git.
Um uso digno de um servidor privado é como remote para versionamento através do Git.
Para isso, é preciso ter o git instalado.
$ sudo apt install git
Faça também as configurações básicas para os commits
Agora devemos adicionar no authorized_keys do usuário git chaves de quem desejamos permitir acesso. É o mesmo processo descrito aqui.
O próximo passo é criar um diretório para gerenciamento dos projetos. Optei por criar em /var/www/, assim posso alocar um subdomínio (git.meusite.com.br) e criar uma página para visualizar os projetos. Logado com o usuário git:
$ mkdir /var/www/git.meusite.com.br
Para que você possa acessar o subdomínio pelo navegador, primeiro deve ser feito um apontamento CNAME no seu domínio. Usando o registro.br (veja como chegar nessa tela):
Opcional: crie também um apontamento CNAME www.git para o seu domínio.
Após fazer os apontamentos, seus registros devem estar parecidos com:
Agora, temos que configurar um arquivo .conf para O Apache redirecionar as requisições git. e www.git. para a pasta que criamos anteriormente.
$ vim /etc/apache2/sites-available/git.meusite.com.br.conf
Coloque a configuração abaixo:
<VirtualHost *:80>
ServerAlias www.git.meusite.com.br
DocumentRoot /var/www/git.meusite.com.br/
ErrorLog ${APACHE_LOG_DIR}/git.meusite.com.br.error.log
LogLevel warn
CustomLog ${APACHE_LOG_DIR}/git.meusite.com.br.access.log combined
<Directory />
Options FollowSymlinks
AllowOverride None
</Directory>
<Directory /var/www/git.meusite.com.br/>
Options Indexes FollowSymLinks MultiViews
AllowOverride All
Order allow,deny
allow from all
</Directory>
</VirtualHost>
Habilite e verifique as configurações e depois reinicie o Apache.
Espere a propagação dos DNS registrados. Você pode verificar o status com:
$ dig +short CNAME git.meusite.com.br
Para cada projeto que você for versionar, é preciso criar um diretório .git, e utilizar o comando git init --bare
$ mkdir /var/www/git.meusite.com.br/primeiro_projeto.git && cd var/www/git.meusite.com.br/primeiro_projeto.git && git init --bare
Agora, os usuários que tiveram suas chaves adicionadas já podem utilizar o repositório.
# no seu computador
$ mkdir primeiro_projeto && cd primeiro_projeto
$ git init
$ echo "Olá Mundo" > index.html # caso seja um novo projeto
$ git add .
$ git remote add origin git@git.meusite.com.br:/var/www/git.meusite.com.br/primeiro_projeto.git
$ git commit -m "Primeiro commit"
$ git push origin master
Agora você já pode utilizar esse repo no computador de outro usuário:
$ git clone git@git.meusite.com.br:/var/www/git.meusite.com.br/primeiro_projeto.git && cd primeiro_projeto
Verifique os commits realizados, no servidor:
$ cd /var/www/git.meusite.com.br/primeiro_projeto.git && git log
Pronto! Você tem um repositório particular funcional. Agora precisamos realizar algumas restrições de segurança.
No formato atual, qualquer usuário pode acessar o servidor com o usuário git, através de ssh. Podemos restringir isso utilizando o git shell, ferramenta que vem em conjunto com a instalação do git.
Verifique se o git-shell está na lista de shells disponíveis no sistema
$ cat /etc/shells | grep git
Caso o resultado for vazio, verifique o caminho do programa git shell e adicione-o ao arquivo /etc/shells
$ sudo echo $(which git-shell) >> /etc/shells
Agora defina o git-shell como padrão para o usuário git
sudo chsh git -s $(which git-shell)
Isso previne acesso via shell ao servidor com o usuário git, mas ainda permite que os usuários usem funcionalidades ssh, como por ex.
# na maquina do usuário $ ssh -D 8080 git@meusite.com.br
E outros usos do ssh como port-forwarding. Podemos restringir este acesso editando o arquivo authorized_keys do usuário git e adicionando a seguinte linha antes da chave de cada usuário que deve ter o acesso restrito:
Lembre-se de adicionar um arquivo index pros seus arquivos não ficarem à mostra!
Vamos adicionar um front-end simples para vizualiação dos repositórios, utilizando o programa gitweb
Comece clonando o repositório do git, que trás consigo o gitweb, para que instalemos a partir do código fonte.
$ git clone git://git.kernel.org/pub/scm/git/git.git && cd git/ $ make GITWEB_PROJECTROOT="/var/www/git.seusite.com.br" prefix=/usr gitweb
Atente para a diretiva GITWEB_PROJECTROOT, que deve apontar para o diretório onde estão seus repositórios. Talvez o make não esteja instalado no seu sistema. Nesse caso:
Rodando novamente o comando make serão gerados vários arquivos, dentre eles o diretório gitweb que deve ser movido para a raíz do subdomínio git.
$ sudo cp -rf gitweb /var/www/git.meusite.com.br/ $ cd /var/www/git.meusite.com.br && sudo rm -rf git # remove os arquivos após ter compilado
Precisamos agora ter certeza de que nosso servidor Apache tem permissão para rodar scripts perl/cgi na pasta gitweb, além de termos as bibliotecas necessárias instaladas.
Se tudo der certo, você deve ter acesso, em git.meusite.com.br, a um front end neste estilo:
Old school!
Sincronizando um repositório git a um servidor
Se você possui um servidor com git configurado, e os seus repositórios são referentes a projetos em outro servidor (ou em outro subdomínio do mesmo) uma boa ideia é sincronizar os repositórios aos diretórios que servem seus arquivos para a web.
Para isso, vamos usar uma combinação de git hooks, rsync e, claro, acesso aos servidores via chave ssh.
O fluxo é o seguinte: sempre que um usuário enviar arquivos pro repositório remoto (via git push), o próprio git chama uma ação (hook, ou gancho) e executa uma série de comandos arbitrária.
Existem diversos hooks, mas vamos focar no post-update, que roda no servidor após os novos arquivos terem sido recebidos pelo push.
Esse hook vai atualizar um repositório intermediário, através de um git pull e, depois, enviar as novas alterações pro nosso destino (pasta que serve os arquivos pra web) através do rsync.
Fluxo simplificado:
Usuário: alterações no projeto -> git add -> git commit -> git push Servidor: git pull (atualiza um diretório com uma cópia do projeto) ~> rsync projeto/ seu_user@servidor_com_o_projeto:/var/www/meu_projeto.com.br/
Criando a rotina post-update
$ sudo chsh git -s $(which bash) $ su git
No servidor, vá até o repositório (diretório .git) que você deseja sincronizar.
$ cd /var/www/git.meusite.com.br/projeto.git
Procure pelo diretório hooks e crie um arquivo post-update (sem extensão)
$ vim hooks/post-update
Coloque o seguinte código, que irá realizar o fluxo do servidor descrito anteriormente.
# no arquivo hooks/post-update
#!/bin/bash
$ cd ~/repositorio_intermediario || exit #vai para o diretório onde temos a cópia do repositório
$ GIT_DIR=.git/ # define o diretorio .git/ para ser utilizado no git pull abaixo
$ git pull origin master # pega as alterações que foram feitas no ultimo git push
$ rsync -avz . seu_usuario@servidor_com_o_projeto:/var/www/seu_site.com.br/ # envias os arquivos desse repositorio, agora com as ultimas alterações, pro projeto que você quer manter atualizado
Torne o script executável:
$ chmod a+x hooks/post-update
Vamos agora escolher um diretório para mantermos um repositório intermediário, que vai realizar a sincronização entre o que temos no local (nosso computador), e o que temos no servidor onde está nosso projeto.
Eu optei por uma pasta na home.
$ mkdir ~/repositorio_intermediario
Vamos manter ali uma cópia atualizada do repositório
Agora precisamos ajustar os acessos ssh para que possamos realizar as operações de git pull e rsync sem digitar senha.
Primeiro o git pull: você precisa ter permissão para dar git pull de um repositório que está no seu próprio servidor. Comece criando uma chave, se ainda não tiver, para o usuário git.
$ ssh-keygen
Depois, adicione essa chave (que fica salva em ~/.ssh/id_rsa_nomedachave.pub)
Agora, dê um git pull para salvar o host como confiável. Assim, você não vai precisar confirmar nas próximas vezes.
$ git pull origin master # Você vai se deparar com uma mensagem do tipo:
The authenticity of host 'git.seusite.com.br (123.123.123.123)' can't be established.
ECDSA key fingerprint is SHA256:ssdf98a7sdf9d8sfy8PxHEqmXH64lCxuwzmk.
Are you sure you want to continue connecting (yes/no)?
$ yes
Warning: Permanently added 'git.seusite.com.br' (ECDSA) to the list of known hosts.
O próximo passo é adicionar sua chave recém gerada também no servidor destino.
Restaurando uma instalação Ubuntu após deletar arquivos do sistema
Digamos que você tenha deletado o diretório /etc da sua instalação Ubuntu. oque fazer?
De acordo com as primeiras páginas em qualquer mecanismo de busca, restaurar um backup.
Felizmente o wizard de instalação do Ubuntu consegue identificar uma instalação corrompida e agir de forma a restaurar os arquivos necessários.
Os passos abaixo funcionam para uma instalação com um único usuário.
Com exceção de alguns programas que não foram recuperados, consegui todos os arquivos do diretório /home de volta!
Prepare um pendrive usando um ISO da versão do Ubuntu corrompida, utilizando Rufus ou outro software ISO to USB stick.
O processo é bem tranquilo e existe um passo a passo no site do Ubuntu. Eu usei a versão em windows pois é o OS da outra máquina que tenho disponível. Existem também versões para Ubuntu e macOS.
Certifique-se de que o instalador está rodando em modo UEFI
Com o pendrive conectado, reinicie o computador e entre no modo BIOS. No meu samsung, basta apertar F2 enquanto o computador liga.
Precisei fazer duas alterações aqui para que o computador reconhecesse o instalador:
Na ordem das prioridades, colocar o pendrive em primeiro:
BIOS samsung: colocando USB modo UEFI como primeira prioridade no boot.
Desativar o secure boot, colocando OS MODE como UEFI. Isso evita o erro de SECURITY VIOLATION, devido a configurações UEFI que impedem sistemas operacionais de iniciar a partir de dispositivos externos.
BIOS samsung: desativando o secure boot e colocando OS MODE como UEFI.
Salve as configurações e reinicie o computador.
Instale na mesma partição da versão corrompida.
Siga os passos da instalação, escolhendo a versão que você deseja (instalação mínima ou com softwares adicionais). Na tela Installation Type, se a opção Reinstall Ubuntu estiver disponível, você pode utilizá-la e seguir os passos normalmente. Isto indica que os arquivos deletados não impediram o wizzard de detectar o OS instalado.
Caso ela não esteja disponível, escolha Something else.
Escolhendo opção something else no wizard.
Na próxima tela, certifique-se de escolher a mesma partição utilizada na instalação anterior (a que foi corrompida).
Na opção Use as: coloque Ext4 journaling file system.
Não marque o checkbox Format the partition.
O seu mount point deve ser a raiz da partição (diretório /).
Escolhendo a mesma partição da instalação antiga.
Prossiga com a instalação e certifique-se de ler as informações apresentadas.
Defina o mesmo usuário e senha utilizado anteriormente.
Você será apresentado com uma tela para definir o novo usuário do sistema. Coloque o mesmo usuário, nome de máquina e senha utilizados na instalação corrompida.
Verifique que seus arquivos ainda existem.
Após a conclusão, verifique se seus arquivos estão no estado anterior. Boa sorte!
Alterando a porta padrão do ssh.
BOTSBOTSBOTS. A internet é dos bots. E eles estão sodomizando sua porta 22.
Para ter noção da quantidade de acessos que um servidor recebe, use o comando lastb
Esse código faz uma leitura do arquivo (no debian) /var/log/btemp, onde são salvos os logins falhos no sistema.
A forma padrão de reduzir o número de tentativas é alterando a porta utilizada no ssh. Você pode, em teoria, utilizar qualquer porta, mas algumas são reservadas pelo sistema, então o ideal é chutar um número acima de 1024.
Primeiro, verifique se a porta que você escolheu está em uso:
$ ss -an | grep 66622
Um resultado vazio indica que a porta não está em uso. Compare, por exemplo, com as portas 22, 80, 3306 ...
Estando livre, vamos liberar o acesso a porta pelo firewall com o ufw.
$ sudo ufw allow 66622/tcp
Agora, vamos ajustar as configurações do OpenSSH.
$ sudo vim /etc/ssh/sshd_config
Procure pela linha que referencia a porta 22, que deve estar comentada
# Port 22
Remova o comentário e adicione a porta em questão
Port 66622
Reinicie o ssh:
$ sudo systemctl restart ssh
Eu recomendo verificar pela sua máquina antes de encerrar a conexão atual:
# no seu computador
$ nmap -p 66622 seusite.com.br
# output deve incluir
PORT STATE SERVICE
66622/tcp open unknown
$ ssh seuuser@seusite.com.br -p 66622 # verifique que você consegue realizar o login normalmente
Pronto! Os acessos pela porta 22 devem receber um aviso de conexão recusada. Você pode testar:
#no seu computador
$ ssh t22@seusite.com.br
# output do tipo
ssh: connect to host seusite.com.br port 22: Connection refused
$ ssh t66622@seusite.com.br -p 66622 # entre com uma senha errada propositalmente
Permission denied, please try again.
Quem tem mais de um computador em casa vai se deparar com várias situações onde se faz necessário compartilhar arquivos e acessar programas ou serviços de uma máquina quando estiver usando a outra.
Ao invés de usar pendrive ou enviar os dados pela internet, isso pode ser feito de forma rápida pela rede do roteador.
No Windows
Comece iniciando o PowerShell com WINDOWS + X e depois Windows PowerShell (Admin).
Start-Service : O serviço 'OpenSSH Authentication Agent (ssh-agent)' não pode ser iniciado devido ao seguinte erro:
Não é possível iniciar o serviço ssh-agent no computador '.'.
