SSH, acesso remoto e diagnóstico de recursos
Objetivos desta aula
- Acessar servidores com segurança e conforto, inclusive via bastion
- Aplicar hardening básico no serviço SSH
- Seguir um roteiro de diagnóstico para CPU, memória, disco e rede
- Interpretar load average, swap, %wa e inodes sem se enganar
1. SSH é a porta de entrada do trabalho remoto
Praticamente toda operação em servidor passa por SSH: acesso, cópia de arquivo (scp/rsync), túnel para banco e execução de comando remoto. Configurar bem economiza tempo todos os dias e evita o erro grave de conectar no host errado.
2. ~/.ssh/config: apelidos que evitam acidente
Defina Host cloudshop-prod com endereço, usuário e chave. Além de digitar menos, o nome deixa explícito onde você está agindo. Adicione ServerAliveInterval 30 para não cair em conexões longas.
3. Bastion e ProxyJump
Em nuvem, bancos e máquinas internas não têm endereço público. O acesso passa por um bastion (host de salto). Com ProxyJump cloudshop-prod você conecta ao host interno em um comando, sem copiar chave para o bastion — copiar chave privada para servidor é erro de segurança clássico.
4. Túnel de porta
ssh -L 5432:localhost:5432 cloudshop-db traz a porta do banco para a sua máquina, permitindo usar um cliente local sem expor o banco na internet. É a forma correta de "acessar o banco de produção": leitura pontual, por túnel, com credencial própria e auditada.
5. Hardening mínimo do servidor
PasswordAuthentication no— só chave.PermitRootLogin no— root não entra direto.AllowUsers/AllowGroups— lista curta de quem pode entrar.fail2ban— bloqueia tentativas repetidas.
Aplique, teste em outra sessão e só então encerre a atual. Assim um erro de configuração não te tranca fora do servidor.
6. Rastreabilidade: uma chave por pessoa
Cada pessoa com seu usuário e sua chave. Chave compartilhada elimina a resposta para "quem executou isso?", e é a primeira pergunta de qualquer auditoria depois de um incidente.
7. Servidor lento: siga um roteiro, não o instinto
Ordem que funciona: carga e CPU → memória e swap → disco (espaço e I/O) → rede e conexões → logs. Roteiro evita o vício de olhar sempre a mesma coisa e concluir errado.
8. Load average, o número mais mal interpretado
Load é a média de processos prontos ou esperando, nos últimos 1, 5 e 15 minutos. Compare sempre com nproc: load 4 em 4 núcleos é ocupação total saudável; load 12 em 4 núcleos é fila. Importante: espera por disco também conta no load do Linux — por isso load alto com CPU baixa aponta I/O.
9. Memória: cache não é vazamento
O Linux usa memória livre como cache de disco de propósito. Olhe a coluna available em free -h, não used. Os sinais reais de pressão são swap em atividade (colunas si/so no vmstat) e mensagens do OOM killer no log do kernel.
10. Disco: espaço, inodes e I/O
São três problemas diferentes: df -h para espaço, df -i para inodes (milhões de arquivos pequenos esgotam inodes com disco "livre") e iostat -xz para I/O, onde %util e await altos indicam disco saturado. Em nuvem, também há limite de IOPS do volume contratado.
11. Rede e conexões
ss -s resume os sockets; ss -tan state time-wait | wc -l mostra conexões em encerramento; ping e traceroute avaliam caminho. Erros comuns: esgotar limite de conexões da aplicação ou do banco, e DNS lento fazendo tudo parecer travado.
12. Do diagnóstico ao runbook
Fecha o módulo escrevendo o seu docs/runbook-linux.md: para cada sintoma (lento, disco cheio, serviço caiu, porta ocupada, memória alta), liste os comandos em ordem, o que observar e a ação. Runbook é o documento que operadores de plantão realmente usam — e um item forte no seu portfólio.
Na prática
SSH confortável e seguro
bash
cat >> ~/.ssh/config <<'EOF'
Host cloudshop-prod
HostName 203.0.113.10
User cloudshop-ops
IdentityFile ~/.ssh/id_ed25519
ServerAliveInterval 30
Host cloudshop-db
HostName 10.0.2.15
User cloudshop-ops
ProxyJump cloudshop-prod # salta pelo bastion, sem copiar chave para la
EOF
ssh cloudshop-prod
ssh -L 5432:localhost:5432 cloudshop-db # tunel para acessar o banco local
ssh cloudshop-prod 'uptime; df -h /' # executa comando remoto e saiNota de segurança: No servidor: PasswordAuthentication no, PermitRootLogin no. Aplique e teste em outra sessão antes de encerrar a atual.
Hardening do SSH com validação segura
bash
sudo tee /etc/ssh/sshd_config.d/99-hardening.conf >/dev/null <<'EOF'
PasswordAuthentication no
PermitRootLogin no
KbdInteractiveAuthentication no
AllowGroups ssh-users
MaxAuthTries 3
EOF
sudo groupadd -f ssh-users && sudo usermod -aG ssh-users cloudshop-ops
sudo sshd -t # valida a sintaxe ANTES de reiniciar (sem saida = ok)
sudo systemctl reload ssh
# Agora abra UMA NOVA sessao em outro terminal para confirmar o acesso.
# Se falhar, voce ainda tem a sessao antiga aberta para corrigir.Nota de segurança: Nunca encerre a sessão atual antes de validar o novo acesso: é a forma mais comum de perder o servidor.
Diagnóstico em ordem
bash
uptime # load average: 12,04 10,88 7,31
nproc # 4 -> load 12 em 4 nucleos = fila de 3x
top -b -n1 | head -15 # veja %Cpu(s): us, sy e wa (wa alto = espera de I/O)
free -h # olhe a coluna available, nao used
vmstat 1 5 # si/so > 0 indicam swap ativo = pressao de memoria
df -h && df -i # espaco e inodes
iostat -xz 1 3 2>/dev/null # %util ~100 e await alto = disco saturado
ss -s # resumo de conexoes
journalctl -k -p err --since "30 min ago" | tail # OOM killer, erros de discoEsqueleto do runbook (docs/runbook-linux.md)
markdown
# Runbook Linux — CloudShop
## Sintoma: servidor lento
1. uptime / nproc -> load vs nucleos (fila?)
2. top -> %wa alto? entao I/O, nao CPU
3. free -h / vmstat 1 5-> available baixo e swap ativo?
4. iostat -xz 1 3 -> %util e await por disco
5. journalctl -k -p err-> OOM killer, erro de disco
Acao: identificar o processo dominante e decidir entre limitar, escalar ou corrigir consulta.
## Sintoma: disco cheio
1. df -h (partição) 2. df -i (inodes) 3. du -xh --max-depth=1 <dir> | sort -h
Acao: rotacionar logs, podar imagens de container, alertar em 80%.
## Sintoma: servico caiu
1. systemctl status <unit> 2. journalctl -u <unit> -p err --since "15 min ago"
3. Verificar dono/permissao de diretorios e EnvironmentFile
Acao: corrigir causa, confirmar Restart=on-failure, registrar no diario.
## Sintoma: porta em uso
ss -tulpn | grep :<porta> -> identificar PID -> kill -TERM antes de kill -KILLPor que isso importa
Toda entrevista de infra faz a pergunta 'o servidor está lento, e agora?'. Ter um roteiro é a resposta que aprova.
Erro comum
Concluir vazamento de memória olhando 'used' sem observar available e swap.
Dica de produção
Monitore inodes além de espaço: milhões de arquivos pequenos enchem inodes com disco 'livre'.
Alerta de segurança
Cada pessoa com sua própria chave e usuário. Chave compartilhada elimina rastreabilidade.
Pergunta de entrevista
Load average 12 em uma máquina de 4 vCPUs: o que isso significa e o que você olha depois?
Glossário
- load average
- Média de processos prontos ou esperando execução; comparar sempre com o número de núcleos.
- ProxyJump
- Recurso do SSH para acessar host interno através de um bastion.
- bastion
- Host de salto exposto de forma controlada, único caminho de acesso à rede privada.
- swap
- Área em disco usada quando a memória física se esgota; atividade constante indica pressão.
- %wa (iowait)
- Percentual de tempo em que a CPU está ociosa esperando entrada/saída.
- IOPS
- Operações de entrada/saída por segundo suportadas pelo disco ou volume.
- túnel SSH
- Encaminhamento de porta que permite acessar um serviço interno pela conexão SSH.
- runbook
- Documento com sintomas, comandos e ações usado durante plantão e incidentes.
Conexão com o CloudShop
Preparar acesso seguro ao host de produção do CloudShop via bastion.
Quiz da aula
1. Em free -h, qual coluna melhor indica memória realmente utilizável?
2. Load average 12 em uma máquina de 4 núcleos, com %wa alto. Qual hipótese é mais provável?
3. Qual é a forma correta de acessar um banco em rede privada?
4. Disco com 40% livre, mas a aplicação não consegue criar arquivos. O que verificar?
Minhas anotações
Salvo automaticamente neste navegador.