VPS & Security on Blog do Aquasp

Como evitar quedas por inatividade quando você está conectado via SSH

Tue, 09 Dec 2025 01:41:02 +0000

Introdução

Uma das coisas mais frustrantes quando se trabalha em um servidor?

Sua sessão SSH cai por causa de uma oscilação rápida no Wi-Fi, de um tempo limite por inatividade ou de uma conexão instável.

Resolva isso de vez em 30 segundos.

A solução universal: edite sua configuração do SSH

Isso funciona no Linux, macOS e Windows — e aguenta falhas de rede de até ~4–5 minutos.

Passo 1: Crie ou edite o arquivo de configuração do SSH

No Linux / macOS:

mkdir -p ~/.ssh
nano ~/.ssh/config

No Windows (PowerShell):

# Replace YourUsername with your actual Windows username
mkdir "$HOME\.ssh" -Force
notepad "$HOME\.ssh\config"

Passo 2: Adicione estas linhas

sshHost *
 ServerAliveInterval 120
 ServerAliveCountMax 3
 TCPKeepAlive yes

Salve e saia.

Pronto. É só isso.

O que isso faz de verdade

Configuração	Significado
`Host *`	Aplica estas regras a todas as conexões SSH
`ServerAliveInterval 120`	A cada 2 minutos, seu computador envia um pacotinho de “ainda estou aqui”
`ServerAliveCountMax 3`	Só se 3 pacotes seguidos falharem → aí a conexão é fechada (~6 min)
`TCPKeepAlive yes`	Keepalive extra no nível do sistema operacional (ajuda com alguns roteadores/firewalls)

Resultado: agora sua sessão SSH sobrevive a:

Troca de rede Wi-Fi
Notebook entrando e saindo da suspensão
Quedas rápidas de internet
Reconexões de VPN

…sem travar nem cair.

Agora você é inabalável

De agora em diante, quando sua internet piscar, sua sessão SSH simplesmente… espera com paciência.

Chega de “Connection reset by peer” Chega de perder sessões do tmux Chega de raiva

Você oficialmente subiu de nível.

Obrigado pela leitura — e continue conectado!

Como hospedar em casa com facilidade e colocar seus projetos online mesmo atrás de CGNAT

Tue, 09 Dec 2025 01:13:41 +0000

Introdução

Quer rodar serviços pesados em um servidor potente em casa, mesmo com o seu provedor te colocando atrás de CGNAT? Este guia mostra exatamente como colocá-los online — do jeito clássico e à prova de balas, usando túneis SSH reversos.

Sem Cloudflare Tunnel. Sem Ngrok. Só SSH + systemd.

As desvantagens (e por que dá para lidar com elas)

Internet de casa não tem a qualidade de um datacenter (quedas acontecem)
A maioria dos provedores usa CGNAT → não dá para abrir portas do jeito normal

Solução: use uma VPS barata como “ponte” pública. Seu servidor pesado fica em casa. A VPS só encaminha as portas.

Como funciona – a mágica dos túneis SSH reversos (-R)

Internet → Cheap VPS (public IP) → SSH reverse tunnel → Your home server (behind CGNAT)

O seu servidor de casa abre uma conexão SSH de saída até a VPS e diz: “Tudo o que chegar na sua porta 8096 → mande para o meu Jellyfin local na 8096”

Nenhuma porta aberta no roteador de casa. Nenhuma exposição.

Configuração passo a passo

1. No seu servidor de casa (o potente)

# Create folder for tunnel configs
sudo mkdir -p /etc/sshtunnels

# Example: expose Jellyfin (port 8096)
sudo nano /etc/sshtunnels/jellyfin.conf

Conteúdo do arquivo:

8096:8096 # remote_port:local_port
443:8443 # optional: HTTPS reverse proxy on VPS → your local 8443
80:8080

Uma linha por serviço. O primeiro número = porta na VPS, o segundo = porta no seu servidor de casa.

2. Gere uma chave SSH (se você ainda não tiver uma)

ssh-keygen -t ed25519 -C "home-server-tunnel"

Copie a chave pública para a sua VPS:

ssh-copy-id user@your-vps-ip

3. Crie o script que gerencia os túneis

sudo nano /usr/local/bin/sshtunnel.sh

#!/bin/bash

# === EDIT THESE ===
REMOTE_USER="root" # or your VPS user
REMOTE_HOST="123.45.67.89" # your VPS public IP
SSH_KEY="/home/youruser/.ssh/id_ed25519"
SSH_PORT="22" # change if you use a non-standard port
# ==================

INSTANCE="$1"
CONFIG_FILE="/etc/sshtunnels/${INSTANCE}.conf"

if [[ ! -f "$CONFIG_FILE" ]]; then
 echo "Error: Config file $CONFIG_FILE not found!"
 exit 1
fi

# Build -R arguments
FORWARD_OPTS=""
while IFS=: read -r remote_port local_port; do
 [[ -z "$remote_port" || "$remote_port" =~ ^# ]] && continue
 # Clean any old process using the remote port
 ssh -p "$SSH_PORT" "$REMOTE_USER@$REMOTE_HOST" \
 "lsof -i :$remote_port -t | xargs -r kill -9" 2>/dev/null
 FORWARD_OPTS="$FORWARD_OPTS -R $remote_port:localhost:$local_port"
done < "$CONFIG_FILE"

echo "Starting tunnel $INSTANCE → $REMOTE_HOST ($FORWARD_OPTS)"

exec ssh -o StrictHostKeyChecking=no \
 -o ServerAliveInterval=30 \
 -o ServerAliveCountThreshold=3 \
 -o ExitOnForwardFailure=yes \
 -o GatewayPorts=yes \
 -N -T \
 -i "$SSH_KEY" \
 -p "$SSH_PORT" \
 $FORWARD_OPTS \
 "$REMOTE_USER@$REMOTE_HOST"

Torne-o executável:

sudo chmod +x /usr/local/bin/sshtunnel.sh

4. Crie um serviço do systemd (início e reconexão automáticos)

sudo nano /etc/systemd/system/sshtunnel@.service

[Unit]
Description=SSH Reverse Tunnel for %i
After=network-online.target
Wants=network-online.target

[Service]
User=youruser # ← change to your home user (not root!)
Group=youruser
ExecStart=/usr/local/bin/sshtunnel.sh %i
Restart=always
RestartSec=10

[Install]
WantedBy=multi-user.target

Recarregue e ative:

sudo systemctl daemon-reload

# Start a tunnel (example: jellyfin)
sudo systemctl enable --now sshtunnel@jellyfin.service

Confira o status:

sudo systemctl status sshtunnel@jellyfin.service

5. No lado da VPS (opcional, mas recomendado)

Instale um servidor web pequeno ou o Caddy/nginx para cuidar do TLS e fazer proxy para as portas encaminhadas.

Exemplo com o Caddy (HTTPS automático):

# On the VPS
apt install caddy

# /etc/caddy/Caddyfile
jellyfin.yourdomain.com {
 reverse_proxy localhost:8096
}

Agora jellyfin.yourdomain.com → o seu Jellyfin de casa, totalmente criptografado.

Tudo rodando no meu servidor parrudo de casa, atrás de CGNAT.

Vantagens desta configuração

Funciona atrás de qualquer CGNAT / bloqueio do provedor
Nenhuma dependência de terceiros (sem Cloudflare, sem Ngrok)
Criptografia completa possível
Sobrevive a reinicializações (systemd + Restart=always)
Custa quase nada

Palavras finais

Este é o jeito realmente bacana que encontrei para hospedar serviços pesados em casa em 2025.

O seu hardware potente fica em casa. A sua VPS de US$ 1/mês é só uma guarda de trânsito.

Obrigado pela leitura — agora vá montar o seu home lab imbatível!

Como deixar sua VPS mais segura contra exclusões acidentais

Tue, 09 Dec 2025 00:31:57 +0000

Introdução

Você já apagou um arquivo ou uma pasta sem querer em uma VPS? Essa sensação é horrível. Às vezes você está trabalhando rápido e apaga um arquivo/pasta muito importante. Isso já aconteceu comigo. Hoje quero compartilhar com vocês uma ferramenta incrível: o trash-cli . Ele adiciona uma lixeira na linha de comando para evitar esses erros humanos.

Instalando o trash-cli

O trash-cli é uma ferramenta de linha de comando leve, disponível nos repositórios do Debian, o que a torna ideal para VPSs com poucos recursos.

Passos da instalação

Atualize a sua lista de pacotes:

sudo apt update

Instale o trash-cli:

sudo apt install trash-cli

Confira a instalação:

trash --version

Se tudo foi instalado corretamente, você verá as informações da versão.

O processo é rápido e quase não pesa na sua VPS.

Usando o trash-cli para apagar com mais segurança

Depois de instalado, o trash-cli oferece comandos para gerenciar arquivos com segurança. Ele move os itens para ~/.local/share/Trash/ em vez de apagá-los.

Comandos básicos

Mandar um arquivo ou diretório para a lixeira: trash file.txt ou trash directory.
Listar os itens na lixeira: trash-list (mostra os arquivos com as datas de exclusão).
Restaurar itens: trash-restore (menu interativo para escolher e recuperar arquivos).
Esvaziar a lixeira: trash-empty (apaga permanentemente todos os itens da lixeira).
Esvaziar itens antigos: trash-empty 30 (apaga itens com mais de 30 dias).

Exemplo de fluxo de trabalho:

trash important_file.txt # Move to trash
trash-list # Check what's there
trash-restore # Recover if needed

Isso substitui o uso arriscado do rm no dia a dia.

Criando um alias do rm para usar o trash-cli

Para deixar o rm mais seguro por padrão, crie um alias dele para o trash na configuração do seu shell. Assim, a maioria das exclusões vai para a lixeira.

Configurando o alias

Edite o seu arquivo ~/.bashrc:

nano ~/.bashrc

Adicione esta linha no final:

alias rm='trash'

Salve e saia (Ctrl+X, Y, Enter).
Recarregue a configuração:

source ~/.bashrc

Agora, rm file.txt vai usar o trash em vez de apagar permanentemente.

Automatizando o esvaziamento da lixeira com o cron

Para a lixeira não acumular indefinidamente, automatize o esvaziamento com uma tarefa no cron.

Configurando o esvaziamento semanal

Edite o seu crontab:

crontab -e

Adicione esta linha para a exclusão semanal (por exemplo, todo domingo às 2h da manhã):

0 2 * * 0 /usr/bin/trash-empty

0 2 * * 0: domingo às 2h da manhã.
/usr/bin/trash-empty: limpa toda a lixeira.

Salve e saia.
Confira:

crontab -l

Ajuste o agendamento como precisar (por exemplo, troque 0 por 1-6 para os dias de semana). Para esvaziar só uma parte, use trash-empty 30 para apagar os itens com mais de 30 dias.

Conclusão

Instalando o trash-cli, criando um alias do rm para o trash e configurando o esvaziamento automático, você deixa sua VPS muito mais segura contra exclusões acidentais. Essa abordagem adiciona uma camada recuperável sem sacrificar o desempenho. Lembre-se de combiná-la com backups regulares e cuidado ao usar comandos. Se você é novo na administração de VPS, comece aos poucos e teste bem. Para configurações mais avançadas, explore a integração com ferramentas de monitoramento. Fique seguro por aí!

Como deixar sua VPS segura

Tue, 09 Dec 2025 00:30:29 +0000

Introdução

Se você acabou de comprar uma VPS e está começando a hospedar seus próprios serviços, esta é uma das melhorias de segurança mais importantes que você pode fazer.

Ao trocar para autenticação por chave SSH e desativar o login por senha, seu servidor fica praticamente imune a ataques de força bruta — mesmo que alguém descubra sua senha ou que você ainda esteja usando a porta padrão 22.

Passo 1: Gere um par de chaves SSH na sua máquina local

Linux e macOS

Abra um terminal e rode:

ssh-keygen -t rsa -b 4096

ou (formato mais novo, recomendado):

Bash

ssh-keygen -t ed25519

Aperte Enter para aceitar o local padrão do arquivo e deixe a senha da chave (passphrase) em branco (é só apertar Enter duas vezes).

Suas chaves serão salvas como:

Chave privada: ~/.ssh/id_rsa ou ~/.ssh/id_ed25519
Chave pública: ~/.ssh/id_rsa.pub ou ~/.ssh/id_ed25519.pub

Nunca compartilhe a chave privada!

Windows (PowerShell)

Abra o PowerShell e rode:

ssh-keygen.exe -t ed25519

(ou -t rsa -b 4096 se o ed25519 não for suportado)

Aperte Enter em todas as perguntas (sem passphrase). As chaves serão criadas em C:\Users\YourUser.ssh\

Passo 2: Copie sua chave pública para a VPS

Linux e macOS (método mais fácil)

ssh-copy-id user@your-vps-ip

Troque user e your-vps-ip pelo seu nome de usuário e pelo IP do servidor.

Windows

Cole sua chave pública (é uma linha longa que começa com ssh-ed25519 ou ssh-rsa) → salve com Ctrl+O → Enter → Ctrl+X
Teste: abra um terminal/PowerShell novo e tente entrar. Deve funcionar sem pedir senha.

Edite o arquivo: (Bash)

nano ~/.ssh/authorized_keys

Crie a pasta .ssh e o arquivo authorized_keys (se ainda não existirem): (Bash)

mkdir -p ~/.ssh
chmod 700 ~/.ssh
touch ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keys

Entre na sua VPS normalmente (com senha): (PowerShell)

ssh user@your-vps-ip

Copie sua chave pública para a área de transferência: (PowerShell)

Get-Content $HOME\.ssh\id_ed25519.pub | Set-Clipboard

(ou id_rsa.pub se você usou RSA)

Passo 3: Desative a autenticação por senha

Agora que o login com chave funciona, desative completamente o login por senha.

Entre na sua VPS (usando sua chave) e edite a configuração do SSH:

sudo nano /etc/ssh/sshd_config

Encontre e altere (ou adicione) estas linhas:

PasswordAuthentication no
ChallengeResponseAuthentication no
UsePAM no
PubkeyAuthentication yes

Salve e saia.

Reinicie o serviço SSH:

sudo systemctl restart sshd

(ou sudo service ssh restart em sistemas mais antigos)

Teste final: tente entrar a partir de um terminal novo. Só deve funcionar com a sua chave privada — tentativas com senha serão recusadas na hora.

Pronto!

Agora sua VPS está protegida contra:

Ataques de força bruta
Credential stuffing (uso de senhas vazadas em massa)
Senhas fracas ou vazadas

Mesmo que um invasor saiba seu usuário e sua senha, ele não consegue entrar sem o arquivo da sua chave privada.

Dica de mestre: guarde um backup da sua chave privada em local seguro e considere adicionar uma passphrase depois, usando ssh-keygen -p.

Obrigado pela leitura! 😊

Cache de página, cache de objetos e cache de CDN – entendendo todos os tipos de cache

Mon, 08 Dec 2025 23:13:04 +0000

Entendendo os diferentes tipos de cache (principalmente para escalar sites com CMS)

Se você já se perguntou o que as pessoas querem dizer quando falam em “cache de página”, “cache de objetos” ou “cache de CDN”, este post é para você. Essas são as três principais camadas de cache, que fazem uma diferença enorme na hora de escalar o WordPress, o WooCommerce ou qualquer outro CMS.

O que é cache de página?

O cache de página (também chamado de cache de página inteira ou cache de HTML) é exatamente o que o nome diz: a página HTML inteira já renderizada é salva como um arquivo estático.

Em um site realmente estático (HTML + CSS + JS puros), não há necessidade de cache de página, porque todos os arquivos já são estáticos. Mas, com um CMS como o WordPress, cada requisição normalmente dispara PHP → tema → plugins → consultas ao banco de dados → saída em HTML. Esse processo consome CPU e leva tempo.

O cache de página inteira pula tudo isso. O primeiro visitante dispara o processo completo de PHP+MySQL, o HTML resultante é salvo, e todos os visitantes seguintes recebem na hora o HTML estático já gerado — sem PHP, sem consultas ao banco de dados, com quase zero de CPU.

Resultado: carga no servidor de 10 a 100× menor e páginas carregando muito mais rápido.

O que é cache de objetos?

O cache de objetos guarda os resultados de consultas caras ao banco de dados (ou de qualquer processamento lento) em uma memória rápida (geralmente Redis ou Memcached).

Pense nele como um intermediário superrápido entre o seu código PHP e o banco de dados.

Exemplo com o WordPress:

O WordPress precisa da lista de posts publicados → ele pergunta ao MySQL.
Primeira requisição: o MySQL faz o trabalho e devolve os dados, e o cache de objetos os salva na RAM.
As próximas 10 000 requisições: o cache de objetos devolve na hora os mesmos dados direto da memória → o MySQL dorme em paz.

O cache de objetos é esperto — ele se invalida sozinho quando os dados mudam (por exemplo, quando você publica um post novo).

Por que você ainda precisa dele, mesmo com o cache de página inteira:

Usuários logados (incluindo o painel do WordPress, as páginas de conta do WooCommerce etc.) não podem ter a página inteira em cache para todo mundo.
Essas páginas ainda passam pelo PHP e pelo MySQL → o cache de objetos as deixa toleráveis, em vez de dolorosamente lentas.

Cache de objetos + cache de página inteira juntos formam a combinação clássica para tráfego alto.

O que é cache de CDN?

Uma CDN (Content Delivery Network, ou rede de distribuição de conteúdo) copia seus arquivos estáticos (CSS, JS, imagens, fontes) — e, se você quiser, também suas páginas HTML inteiras — para servidores “PoP” espalhados pelo mundo.

Sem CDN: um visitante no Japão baixa tudo do seu servidor de origem que fica, digamos, no Brasil → latência alta.

Com CDN:

Os arquivos estáticos são entregues pelo PoP mais próximo (muitas vezes a menos de 30 ms).
Se você também ativar o cache de página inteira na CDN, a página HTML inteira também é entregue por esse PoP próximo → o servidor de origem nem é tocado nas páginas em cache.

É por isso que alguns sites carregam instantaneamente de qualquer lugar do planeta.

Exemplo real: o fluxo de tráfego do WordPress

Sem nenhum cache

Visitante → servidor web → PHP → dezenas de arquivos de plugins → consultas ao MySQL → HTML → visitante → CPU alta, TTFB lento, bate fácil nos limites de recursos.

Só com cache de página inteira

Primeiro visitante: o mesmo caminho lento de cima (mas o HTML é salvo). Os próximos 10 000 visitantes: o servidor web entrega na hora o HTML pronto → quase zero de CPU.

Só com cache de objetos

Toda requisição ainda roda PHP + plugins, mas as consultas ao banco são respondidas pela RAM em vez do disco → mais rápido que sem cache, mas ainda pesado.

Com cache de página inteira + cache de objetos

Visitantes anônimos → HTML estático (superrápido, quase sem carga)
Usuários logados → o PHP roda, mas o cache de objetos deixa as consultas ao banco instantâneas → carga administrável

Adicione por cima uma CDN com cache de página inteira

Agora até o HTML estático é entregue a partir de pontos de borda no mundo todo. O seu servidor de origem pode basicamente tirar um cochilo até que algo realmente precise de PHP (por exemplo, envio de formulários, invalidação de cache).

Conclusão

Aqui está a hierarquia, do mais impactante para o menos (para a maioria dos sites com CMS):

Cache de página inteira na CDN → o mais rápido para os visitantes, escala para milhões de acessos com quase nenhuma carga na origem.
Cache de página inteira na origem → ainda é um ganho enorme se você não puder fazer cache na CDN.
Cache de objetos (Redis/Memcached) → obrigatório para usuários logados, WooCommerce, painéis etc.
Todo o resto (OPcache, cache do navegador etc.) → bom de ter, geralmente já vem ativado por padrão.

Se você for fazer uma coisa só: ative um cache de página inteira decente (e leve-o para a sua CDN, se possível). Se você tem tráfego de usuários logados ou uma loja: adicione o cache de objetos com Redis/Memcached.

É isso — as três camadas de cache que movem basicamente todo site WordPress com tráfego alto no planeta.

Espero que isso tenha esclarecido as coisas!

Obrigado pela leitura! 😊