Adriano Rosa

Setup Virtual Server com NGINX

Sun, 14 Aug 2016 00:00:00 -0300

Para quem esta acostumado com Apache, já deve ter configurado ou ouvido falar sobre Virtual Host, eu cheguei a explicar a diferença entre Server Block/Virtual Server(Nginx) e Virtual Host(Apache). Bem, isso também é possível no Nginx, mas aqui chamamos de Server Block ou Virtual Server.

A configuração no Nginx é feita dentro de blocks {}, logo existem diversas diretivas. E para configurar um Virtual Server usamos a diretiva server. Dentro dessa diretiva fazemos o setup de um Virtual Server.

Como o Nginx permite vários block no mesmo arquivo de configuração, nesse exemplo vou criar 3 Virtual Servers dentro do block http.

http {
  # Virtual Server 1 (Site principal)
  server {
    listen      80;
    server_name example.com www.example.com;
    root /var/www/www.example.org
    location / {
        try_files $uri $uri/ =404;
    }    
  }
  # Virtual Server 2 (CMS site)
  server {
    listen      80;
    server_name admin.example.com;
    root /var/www/admin.example.com
    location / {
        try_files $uri $uri/ =404;
    }
  }
  # Virtual Server 3 (API site)
  server {
    listen      80;
    server_name api.example.com;
    root /var/www/api.example.com
    location / {
        try_files $uri $uri/ =404;
    }
  }
}

Virtual Host no ambiente de desenvolvimento local

No ambiente de desenvolvimento local também é necessário configurar o arquivo de hosts, localizado em /etc/hosts em sistemas Unix ou em %SystemRoot%\System32\drivers\etc\hosts no Windows.

No arquivo de hosts é necessário adicionar um roteamento para que o domínio que estamos testando seja apontado para o nosso servidor local.

127.0.0.1 example.com www.example.com
127.0.0.1 admin.example.com
127.0.0.1 api.example.com

Concluído todas as configurações no webserver e arquivo de hosts, agora é necessário reiniciar o nginx para alterações terem efeito.

Linux

sudo service nginx reload

OSX

sudo nginx -s reload

Conclusão

Com o Nginx percebemos como é fácil o setup de um Virtual Server, o modo de configuração em block permite maior flexibilidade no setup de um ou vários webserver, talvez por isso que eu prefiro Nginx ao invés do Apache, não só por essa questão mais também por outras questão de performance.

O que é um Virtual Host, Server Block ou Virtual Server?

Sun, 14 Aug 2016 00:00:00 -0300

Virtual Host (Apache) ou Server Block / Virtual Server (Nginx), em configurações de um webserver, refere-se a uma prática de servir mais de um site no mesmo servidor. Um Virtual Host pode ser baseado em IP, ou seja, diferentes IPs servindo vários sites no mesmo server, ou ainda baseado em nome de domínio, ou seja, vários domínios servindo no mesmo server.

O termo Virtual Host é normalmente conhecido no Apache, no Nginx a mesma prática é chamada de Server Block ou Virtual Server, pois um Virtual Server é configurado dentro da diretiva server block.

Apache Virtual Host

A configuração de um Virtual Host no Apache é relativamente simples:

Name-based

Virtual Host baseado em nome é mais simples pois o server vai servir diferentes sites usando o mesmo endereço IP.

<VirtualHost *:80>
    ServerName www.example.com
    ServerAlias example.com 
    DocumentRoot "/www/domain"
</VirtualHost>
<VirtualHost *:80>
    ServerName other.example.com
    DocumentRoot "/www/otherdomain"
</VirtualHost>

Ip-based

Virtual Host baseado em IPs requer setup extra de DNS para que funcione corretamente, geralmente configurar name-based é mais simples por conta disso, e a configuração no Apache é assim:

<VirtualHost 172.20.30.40:80>
  DocumentRoot "/www/vhosts/www1"
  ServerName www1.example.com
</VirtualHost>
<VirtualHost 172.20.30.50:80>
  DocumentRoot "/www/vhosts/www2"
  ServerName www2.example.org
</VirtualHost>

Nginx Virtual Host (Server Block / Virtual Server)

No nginx configurar um Virtual Host é muito mais simples, é possível definir um Virtual Host ip-based ou name-based ou ambos no mesmo server block, veja como fica a configuração:

Name-based

server {
  listen      80;
   server_name example.net www.example.net;
   root /var/www/site1
   ...
}
server {
  listen      80;
  server_name example.com www.example.com;
  root /var/www/site2
  ...
}

Nesse exemplo acima o webserver determina o host de acordo com request e faz o roteamento para o server de destino.

Ip-based ou mixed

No mesmo Server Block podemos definir um Virtual Server para ambos ip-based e name-based, veja só:

server {
  listen      192.168.1.1:80;
  server_name example.org www.example.org;
  ...
}
server {
  listen      192.168.1.2:80;
  server_name example.com www.example.com;
  ...
}

Mais detalhes

https://httpd.apache.org/docs/current/vhosts/
https://nginx.org/en/docs/http/request_processing.html

Composer lock file

Sun, 26 Jun 2016 00:00:00 -0300

Devo ou não fazer o commit do arquivo composer.lock. Quando um ou vários packages é instalado como dependência em seu projeto, o Composer vai atualizar as informações de cada package no arquivo composer.lock.

Ao fazer o commit do arquivo composer.lock, e sempre que utilizar o comando composer install, o Composer vai então instalar as versões exatas definidos anteriormente no seu projeto.

Por isso é importante fazer o commit do arquivo composer.lock para garantir que as dependências de seu projeto sejam sempre as mesmas, isso vai evitar inconsistências e possíveis erros.

O que acontece seu eu não fazer o commit do `composer.lock`

Mesmo que esteja trabalhando um projeto sem a colaboração de outros developers pode acontecer inconsistências nas dependências do seu projeto.

Imagine o seguinte cenário onde você instalou o seguinte package como dependência, isso em seu ambiente de desenvolvimento.

"require": {
  "league/flysystem-aws-s3-v3": "^1.0"
},

Quando você publicar seu projeto no ambiente de produção ou até mesmo em executá-lo em outro local de desenvolvimento, tipicamente você vai executar o comando:

composer install

Como não vai existir o arquivo composer.lock na raiz do projeto, o Composer então vai instalar a versão mais recente do package league/flysystem-aws-s3-v3.

Até aqui tudo bem, mas digamos que alguns dias após o início do desenvolvimento do seu projeto a versão v1.2.0 do package league/flysystem-aws-s3-v3 foi lançado, então quando você instalar as dependências ao invés de obter a versão v1.0.0, que foi testado no ambiente de desenvolvimento, será instalado a versão v1.2.x.

Nesse momento que surge o problema! Se por ventura, alguma mudança no package teve algum breaking changes seu projeto pode estar com algum tipo de bug.

Por isso é fundamental fazer o commit do composer.lock sempre que desejar manter a consistência e instalar as versões exatas de suas dependências em seu projeto.

Em que situação não é necessário comitar `composer.lock`

As vezes, é desnecessário comitar composer.lock quando estiver desenvolvendo uma library.

Mais detalhes

https://getcomposer.org/doc/01-basic-usage.md#composer-lock-the-lock-file

Nginx CORS com múltiplos domínios

Wed, 09 Dec 2015 00:00:00 -0200

CORS (Cross-origin resource sharing) ou (compartilhamento de recursos de origem cruzada) é um mecanismo que permite que os recursos de acesso restrito (por exemplo, fontes) em uma página web possa ser acessado a partir de outro domínio de origem do qual o recurso foi originado. Wikipedia

Como posso definir CORS com Nginx

Implementar CORS é simples basta enviar o seguinte Header:

Access-Control-Allow-Origin: *

Para implementar CORS de uma maneira mais refinada quando um virtual host manipula mais de um domínio é bem simples.

Basicamente o que precisa ser feito é utilizar um Regex para capturar a lista de domínios que deseja enviar.

Esse exemplo é útil quando seu vhost serve webfonts para múltiplos domínios:

location ~* \.(?:ttf|ttc|otf|eot|woff|woff2)$ {
   if ( $http_origin ~* (https?://(.+\.)?(domain1|domain2|domain3)\.(?:net|com)$) ) {
      add_header "Access-Control-Allow-Origin" "$http_origin";
   }
}

Nesse exemplo os domínios que poderão acessar os recursos deste server serão:

domain1.net
domain1.com
domain2.net
domain2.com
domain3.net
domain3.com

Alterar public path no Laravel 5

Sat, 09 May 2015 00:00:00 -0300

No Laravel 5 me deparei com um problema comum que vem sendo discutido largamente por outros desenvolvedores, acontece que em versões anteriores do Laravel existia um arquivo bootstrap/paths.php muito util quando queríamos alterar os nomes de alguns dos diretórios padrão usado pelo framework, como por exemplo, a pasta webroot public que as vezes precisa se chamar public_html, www ou web dependendo do tipo de configuração do seu webserver ou do serviço de hospedagem que utiliza.

Pois bem, esse arquivo bootstrap/paths.php foi removido no Laravel v5.0, e agora não é mais possível definir esse tipo de configuração no framework por padrão, ou seja, se quiser alterar um desses diretórios terá que criar alguns hacks ou da maneira mais fácil que é extender a classe Illuminate\Foundation\Application e redefinir o método publicPath() ou qualquer outro path que deseja modificar ex. para o diretório storage deverá redefinir o método storagePath(), após criar a classe dentro do namespace do seu projeto também é necessário alterar o arquivo bootstrap/app.php onde a classe é instanciada sendo assim essa alteração será refletida em toda aplicação.

Passo 1: Estender a classe Application:

namespace MyApp
class Application extends \Illuminate\Foundation\Application {
    public function publicPath()
    {
        return $this->basePath.DIRECTORY_SEPARATOR.'public_html';
    }
}

Passo 2: Atualizar o arquivo bootstrap/app.php:

$app = new MyApp\Application(
    realpath(__DIR__.'/../')
);

Existe também outras maneiras de alterar os paths, se não quiser extender a class Application, exemplo redefinir helper function public_path() no seu index.php, como no exemplo logo abaixo retirado do fórum laracasts, mas não recomendo esse outro tipo de hack:

function public_path($path = '')
{
    return realpath(__DIR__);
}

Acesse arquivos remoto com SFTP e FileZilla

Sat, 17 Jan 2015 00:00:00 -0200

FTP (File Transfer Protocol) é o protrocolo muito utilizado para transferência de arquivos, porém o uso do FTP não é seguro, a maneira mais segura para transferência de arquivos entre um computador local e servidor remoto é através do SFTP (Secure Shell File Transfer Protocol).

Embora a semelhança com nome FTP, o SFTP possui características diferentes, uma delas é o tipo de autenticação e transferência de arquivos que é baseado em SSH Keys uma método com criptografia de chave pública, o que torna a comunicação entre um computador local e o servidor remoto totalmente segura.

A maneira para conectar a um servidor SFTP é um pouco diferente do FTP pois você deve utilizar sua SSH keys para estabelecer a autenticação com o servidor remoto. Neste post explico passo a passo como configurar uma conexão com servidor SFTP utilizando o FileZilla.

Requisitos

Para configurar uma conexão SFTP com FileZilla você precisa:

Criar sua SSH Key-pair.
Endereço do servidor remoto devidamente configurado com SSH e SFTP.
FileZilla.

Passo 1: Adicionar Private Key ao FileZilla

O FileZilla precisa saber onde esta sua chave privada (Private Key) criada anteriormente para ser usada toda vez que for estabelecer uma conexão com o servidor SFTP. Para dizer ao FileZilla o caminho até sua chave:

imagem 1: Tela de configurações do FileZilla

Abra o FileZilla.
Vá ao menu superior Editar > Configurações.
Na tela de configurações imagem 1 expanda o item Conexão e clique em SFTP.
Clique no botão Adicionar Arquivo de Chave.
Localize sua Private Key e clique Abrir, em seguida clique em OK na tela de configurações.

NOTA: O FileZilla suporta Private Keys no formato .ppk Se sua Private Key é um arquivo no formato .pem ou não foi gerada usando PuTTY o FileZilla exibirá uma janela de dialogo dizendo: arquivo não esta no formato suportado pelo FileZilla, e ainda se você definiu um Passphrase para sua chave a seguinte mensagem também será exibida: O arquivo esta protegido por senha deseja criar uma chave desprotegida no formato reconhecido. Se isso acontecer clique em Sim e digite sua senha se for o caso de ter definido Passphrase e depois salve e uma cópia da Private Key no formato .ppk em algum lugar seguro no seu computador.

Passo 2: Criar uma conexão SFTP

Agora que o FileZilla sabe o caminho de sua Private Key você precisa criar uma nova entrada no Gerenciador de Sites e informar os dados do servidor SFTP:

imagem 2.1: Tela Gerenciamento de Sites do FileZilla

Vá ao menu superior clique em Arquivo > Gerenciamento de Sites ou pressione crtl+S ou cmd+S no OSX.
Clique no botão Novo Site.
Na guia Geral preencha os dados do servidor SFTP:
- Host: Informe o endereço IP do servidor
- Porta: geralmente esse valor é 22
- Protocolo: selecione SFTP - SSH File Transfer Protocol
- Tipo de Login: selecione Normal
- Usuário: informe seu nome usuário
- Senha: deixe em branco pois não é necessário

Clique em Conectar, e pronto se tudo ocorreu como previsto deverá visualizar a janela comum de transferência de arquivos:

imagem 2.2: Tela de transferência de arquivo via SFTP do FileZilla

FTP não é seguro saiba por que

Sat, 10 Jan 2015 00:00:00 -0200

FTP (File Transfer Protocol) é um protocolo bem conhecido e vastamente usado para transferência de arquivos entre dois computadores, seu uso é feito principalmente em hospedagens de site para transferência de arquivos. Porém o uso de FTP não é seguro por diversas razões saiba por que.

Como funciona o FTP

O design do FTP permite conectar a outro computador remoto com autenticação de usuário e senha, ou também de forma anônima se o servidor for configurado para esse fim. Quando você abre uma nova conexão FTP usando um software client-server, como por exemplo o FileZilla, você digita seu login e senha e o endereço IP ou domínio do servidor, e seu software client-server envia através de comando suas credencias em texto plano para o servidor remoto que verifica se os dados de login estão corretos, e então cria-se uma sessão FTP entre os dois computadores, a partir daí é possível transferir arquivos para o servidor remoto e vice-versa.

E por que FTP é inseguro?

O uso do FTP é um grande risco de segurança porque a transferência de arquivos, tanto upload quanto download, são feitos sem encriptação, ou seja, a transmissão dos dados é feita pela rede em formato de texto plano o que significa que se alguém interceptar o pacote TCP durante a transmissão, método também conhecido como Sniffing, dará ao hacker acesso à todas informações de seus arquivos e credencias colocando em risco seu servidor e computador local.

Além disso, existem outras vulnerabilidades bem conhecidas deste protocolo.

Qual a solução seu eu uso FTP

Se você ou sua empresa se preocupa com a segurança de suas informações a solução é bem simples NÃO USE FTP, existem outros métodos conhecidos e de fácil implementação como por exemplo o WinSCP e SFTP.

Use SFTP invés do FTP

SFTP (Secure Shell File Transfer Protocol) é um protocolo parte do pacote OpenSSH. Embora a semelhança com nome FTP o SFTP tem seu design e recursos diferentes. Uma de suas vantagens é o método de autenticação baseado em SSH Key-pair, ou seja, não depende de usuário e senha e sua transmissão de dados é feita através de tunelamento SSH encriptada do inicio ao fim da conexão, o que significa que mesmo que alguém intercepte seus pacotes TCP estará impossibilitado de decifrar os dados transmitidos.

Como usar o SFTP

O SFTP é baseado em SSH Key pair, então basicamente o que precisa:

Criar sua SSH Keys, mas isso pode ser diferente entre sistemas Windows e Unix.
Configurar seu servidor com SFTP ou solicitar junto ao seu provedor de hospedagem de sites se oferece este recurso, mas dificilmente você encontrará esse recurso em hospedagem de site compartilhada. O ideal é que tenha um VPS gerenciável onde possa ter total acesso à configuração, sendo assim será possível configurar SFTP facilmente.
Utilizar um SFTP client, diversos softwares FTP client também oferece suporte para SFTP é o caso do FileZilla, veja como configurar uma conexão com SFTP com FileZilla.

Conclusão

FTP é inseguro é deve ser evitado sempre que possível, o uso de alternativas seguras como SFTP, SCP e WinSCP deve ser usado em seu lugar. Se seu provedor de hospedagem não oferece este recurso procure alternativas como VPS ou migre para empresas que possibilitam essa configuração.

Criar SSH Key pair no Windows

Thu, 18 Dec 2014 00:00:00 -0200

A maneira mais simples de criar SSH key no Windows é utilizando o PuTTY. O PuTTY é um programa de código aberto que emula um Terminal, semelhante ao Terminal do Linux, para estabelecer uma conexão SSH. PuTTY oferece o utilitário PuTTYGen no qual você deverá usar para criar sua chave.

Em ambientes Unix veja o post Como criar SSH Key pair em sistemas UNIX.

Key Pair, ou SSH Keys ou ainda Chave Pública consiste em duas chaves uma pública que deve ser instalada no servidor remoto, e a outra chave privada que fica salva no seu computador, as duas juntas permitem que você conecte de forma segura a um servidor remoto usando o protocolo SSH ou SFTP.

Passo 1: Download PuTTYgen

Vá até o site PuTTY faça o download do utilitário PuTTYGen.

Passo 2: Criar SSH Key

Execute o puttygen.exe, e log verá a janela PuTTY Key Generator imagem 2.1.
Na parte inferior da janela, no item Parameters por padrão já estará selecionado o algoritmo SSH-2 RSA e definido o número de bits 2048, esses parâmetros são o recomendado para gerar SSH Key.
Para criar SSH Key clique no botão Generate. E tenha certeza de movimentar o ponteiro do mouse logo a abaixo a barra de progresso até que seja finalizada.

imagem 2.1 Tela PuTTY Key Generator

Passo 3: Complete as informações e salve sua SSH Key

Na próxima tela, imagem 3.1 siga os passos:

Adicione um comentário para identificar sua Public Key ex. usuario@host.
Crie um Passphrase (recomendado). O Passphrase é como uma senha que precisa ser digitado cada vez que iniciar uma sessão SSH ou SFTP, o que torna sua SSH Key ainda mais segura.
Copie a Public Key para o servidor e salve em authorized_keys

NOTA: Para adicionar a sua chave pública na lista de chaves autorizadas é preciso ter acesso administrativo ao servidor no qual deseja estabelecer uma conexão SSH. Se você é usuário de um sistema onde esse acesso é restrito você deverá revelar sua chave pública para o responsável configurar e instalar para você. Lembre-se somente a chave pública deve ser revelada para terceiros.
Por fim, salve sua Private Key em algum local seguro no seu computador.

imagem 3.1 Gerando SSH keys com PuTTY

NOTA: PuTTY e OpenSSH usam diferentes formatos para Public Key. Sua Public Key deve começar com a linha: ssh-rsa AAAAAAAB3..... se esse valor for algo como: ---- BEGIN SSH2 PUBLIC KEY ---- .... esta errado.

Veja mais detalhes na documentação do PuTTY.

Criar SSH Keys em sistemas UNIX

Thu, 18 Dec 2014 00:00:00 -0200

Para criar sua SSH key em ambientes Unix siga os passos logo abaixo, se você é usuário Windows visite o post como criar ssh key pair no windows.

Passo 1: Verifique seu já possui SSH Key

Veja se já existe SSH keys no seu computador, em ambientes Unix pode ser encontrado em um desses diretórios ~/.ssh/identity, ~/.ssh/id_ecdsa, ~/.ssh/id_dsa ou ~/.ssh/id_rsa. Para verificar digite no terminal:

ls -al ~/.ssh

Dica: se você tiver uma nova instalação Mac OSX ou Linux, você não terá o diretório ~/.ssh criado ainda, esse diretório onde armazena suas chaves públicas e privadas será criado automaticamente no passo seguinte.

Passo 2: Criar uma nova SSH Key

Se ainda não tem sua SSH key deverá gerar uma usando o comando ssh-keygen:

ssh-keygen -t rsa -b 4096 -C "seuemail@example.com"

Explicando o comando acima:

Parâmetro -t específica o tipo de chave nesse caso usamos o algoritmo rsa para protocolo versão 2 outros possíveis valores são rsa1, dsa e ecdsa.
Parâmetro -C adiciona um comentário à chave pública, é apenas uma maneira fácil de identificar a finalidade desta chave, o valor pode ser user@host.
Parâmetro -b informa key size ou total de bits. O padrão é 2048, geralmente esse valor já é o suficiente para sua chave se quiser mais segurança use o valor máximo 4096.

ATENÇÃO: Para chaves RSA o valor mínimo é de 768 bits, mas não crie sua chave com menos de 2048 bits pois estudos apontam que é possível craquear esses tipos de chaves.

Defina Passphrase

O Passphrase é como uma senha e precisa ser digitado to vez que usar a chave para se conectar SSH, se você esquecer o Passphrase ou outra pessoa ter acesso à sua Private Key ficará impossibilitado de conectar ao servidor remoto. Caso não queira definir um Passphrase apenas deixe em branco, pressione enter duas vezes para finalizar.

Passo 4: Copie sua chave pública para o servidor

Após executar o comando para gerar SSH keys dois arquivos serão salvos no diretório ~/ssh por padrão os arquivos são id_rsa e id_rsa.pub, mas é possível criá-los com nomes e diretórios diferentes se for necessário.

A chave pública, cujo a extensão é .pub, deve ser copiado para o servidor e o seu conteúdo é algo como:

ssh-rsa AAAAB3NzaC1yc2EAAAADAQA .....

A chave privada tem o seguinte conteúdo:

-----BEGIN RSA PRIVATE KEY-----
MIIJKQIBAAKCAgEAzpHUcAE5w5e49Qw2S4cp17OmsIc1D8yfNR7y/ZLsf0382zsw
.....

e deve ter apenas permissão de leitura pelo seu usuário, altere usando o comando:

chmod 400 ~/.ssh/id_rsa

Com sua SSH key pair criada, é hora de copiar a chave pública para o servidor, se você não é o administrador do servidor remoto deverá enviar o conteúdo da chave pública para o responsável fazer isso.

No servidor remoto, usando um editor de sua preferencia adicione a chave pública ao arquivo ~/.ssh/authorized_keys, ou simplesmente utilize o comando:

cat ~/.ssh/id_rsa.pub | ssh user@123.45.56.78 "mkdir -p ~/.ssh && cat >>  ~/.ssh/authorized_keys"

Passo 5: Faça um teste com sua SSH Key

ssh user@123.456.789.0

Se sua SSH key foi salva em um diretório diferente de ~/.ssh você deverá informar o diretório onde esta a chave para para ter sucesso na conexão com servidor.

ssh -i /diretorio/subpasta/sua_chave_privada user@123.456.789.0

Passo 6: Bonus, usuários Mac OSX

Se você definiu um Passphrase, pode salvar esse valor na sua Keychain e assim evitar ter que digitar o passphrase sempre que for conectar ao servidor remoto. Para adicionar sua SSH key na Keychain use o comando ssh-add:

ssh-add -K ~/.ssh/id_rsa

Digite sua Passphrase e sua chave será armazena na Keychain.

Para visualizar a lista de chaves adicionadas ao ssh-agent:

ssh-add -l

Esse comando exibe o tamanho de bits de sua chave, footprint e o diretório da chave privada da seguinte forma:

2048 ee:aa:11:11:bb:cc:gg:11:Ca:Fe:00:E1:49:30:8C:01 ~/.ssh/id_rsa (RSA)

Mais informações sobre SSH Keys:

https://help.ubuntu.com/community/SSH/OpenSSH/Keys

SSH Keys

Fri, 28 Nov 2014 00:00:00 -0200

Key Pair, ou SSH Keys ou ainda Chave Pública, é o meio de identificação entre seu computador e um servidor SSH usando método de autenticação chave de criptografia pública. Uma de suas vantagens diferentemente do método tradicional com login e senha é que para autenticação com servidor remoto você não precisa enviar seu login e senha, e mesmo que uma pessoa mal intencionada intercepte sua transmissão de dados pela rede não poderá ter acesso à suas credencias impossibilitando roubo de seus dados de acesso. E também, usando SSH Keys para autenticação elimina drasticamente o risco de um hacker tentar adivinhar seu login e senha enviando centenas ou milhares de combinações aleatórias de login e senha para entrar no sistema, esse é um tipo de ataque comum em sistemas baseado em autenticação de login e senha chamado de brute-force password.

Além de oferecer uma camada de segurança, autenticação por SSH keys pode ser ainda mais conveniente do que o método tradicional de autenticação por login e senha. Quando usado com o programa SSH Agent, SSH keys permite a conexão com um servidor, ou múltiplos servidores, sem a necessidade de ter que lembrar ou digitar sua senha e login para cada acesso.

Como funciona SSH keys

SSH keys consiste em um par de chaves uma pública que deve ser instalada no servidor remoto, e uma outra chave privada que fica salva no seu computador. Somente você poderá ter acesso à chave privada, então tenha certeza de mantê-la salva em um lugar seguro em seu computador com as devidas permissões e uma boa Passphrase. As duas chaves juntas permitem que você conecte de forma segura a um servidor remoto usando o protocolo SSH ou SFTP.

NOTA: Para adicionar a sua chave pública na lista de chaves autorizadas é preciso ter acesso administrativo ao servidor no qual deseja estabelecer uma conexão SSH. Se você é usuário de um sistema onde esse acesso é restrito você deverá revelar sua chave pública para o responsável configurar e instalar para você. Lembre-se somente a chave pública deve ser revelada para terceiros.

Tipos de encriptação

O algoritmo usado para encriptar suas chaves pode ser RSA1, RSA, DSA ou ECDSA, porém o uso desses algoritmos depende da finalidade da sua chave e de recursos suportado pelo servidor SSH.

RSA1 (Rivest-Shamir-Adleman) é um algoritmo para o protocolo SSH versão 1, seu uso é limitado a servidores que não suportam a versão recente SSH 2.
RSA (Rivest-Shamir-Adleman) é o algoritmo para o protocolo SSH versão 2 o mais utilizado em servidores SSH e o mais seguro hoje em dia, possibilita autenticar e transmitir dados criptografados até o seu destino. Esse algoritmo é o RECOMENDADO para sua chave SSH.
DSA (Digital Signature Algorithm) é um algoritmo que pode ser usado para gerar sua chave, porém DSA tem se tornado menos seguro nos últimos anos. Sua função é somente autenticar DSA não encripta ou decripta dados.
ECDSA é um algoritmo variante do DSA provê tamanho menor da sua chave, esses tipos de chaves são usado apenas para autenticação.

Key Size

Key Size é o número de bits usado na criação da chave, esse número varia dependendo do algoritmo usado.

Para SSH keys RSA, o tamanho minimo de bits é 768 bits e o padrão é 2048 bits. Você pode tornar sua chave ainda mais segura usando 4096 bits.

NOTA: Para RSA não é recomendado utilizar menos do que 2048 bits. Geralmente 2048 bits é considerado seguro.

SSH keys DSA, devem conter exatos 1024 bits.

SSH keys ECDSA, aceita um dos três valores da curva elíptica: 256, 384 ou 521 bits.

Criar SSH Key pair

Para criar sua SSH keys você precisa ter o programa ssh-keygen parte do pacote OpenSSH encontrado apenas em sistemas Unix. Em distribuições do Linux e Mac OSX esse programa já vem instalado por padrão. Veja neste post como criar SSH Keys em sistemas Unix.

No Windows, o programa ssh-keygen não existe. A maneira mais simples de criar sua chave é utilizando o PuTTY, PuTTY é um programa de código aberto que emula um Terminal, semelhante ao Terminal do Linux, para estabelecer uma conexão SSH. PuTTY oferece o utilitário PuTTYGen no qual você deverá usar para criar sua chave. Veja neste post como criar sua SSH Key no Windows.

Alternativas como CopSSH pode ser usado no Windows ou se você usa GitHub o programa GitHub para Windows oferece o Git Shell como parte da instalação onde é possível criar SSH Keys usando o comando ssh-keygen do mesmo modo em sistemas Unix.

Adriano Rosa

Setup Virtual Server com NGINX

Virtual Host no ambiente de desenvolvimento local

Linux

OSX

Conclusão

O que é um Virtual Host, Server Block ou Virtual Server?

Apache Virtual Host

Name-based

Ip-based

Nginx Virtual Host (Server Block / Virtual Server)

Name-based

Ip-based ou mixed

Mais detalhes

Composer lock file

O que acontece seu eu não fazer o commit do composer.lock

Em que situação não é necessário comitar composer.lock

Mais detalhes

Nginx CORS com múltiplos domínios

Como posso definir CORS com Nginx

Alterar public path no Laravel 5

Acesse arquivos remoto com SFTP e FileZilla

Requisitos

Passo 1: Adicionar Private Key ao FileZilla

Passo 2: Criar uma conexão SFTP

FTP não é seguro saiba por que

Como funciona o FTP

E por que FTP é inseguro?

Qual a solução seu eu uso FTP

Use SFTP invés do FTP

Como usar o SFTP

Conclusão

Criar SSH Key pair no Windows

Passo 1: Download PuTTYgen

Passo 2: Criar SSH Key

Passo 3: Complete as informações e salve sua SSH Key

Criar SSH Keys em sistemas UNIX

Passo 1: Verifique seu já possui SSH Key

Passo 2: Criar uma nova SSH Key

Defina Passphrase

Passo 4: Copie sua chave pública para o servidor

Passo 5: Faça um teste com sua SSH Key

Passo 6: Bonus, usuários Mac OSX

Mais informações sobre SSH Keys:

SSH Keys

Como funciona SSH keys

Tipos de encriptação

Key Size

Criar SSH Key pair

O que acontece seu eu não fazer o commit do `composer.lock`

Em que situação não é necessário comitar `composer.lock`