// GUIA DO UTILIZADOR

Guia operacional — o que fazer, passo a passo, para tirar o máximo partido do SSHBorg.

⚙⚙⚙

// ADICIONAR UM HOST

Toque no botão + no ecrã de hosts para adicionar um novo servidor.

Campos obrigatórios

  • Hostname / IP — o endereço ou IP do servidor. São suportados IPv4 e IPv6.
  • Porta — predefinido como 22. Altere se o seu servidor usa uma porta SSH diferente.
  • Nome de utilizador — o utilizador Unix com que quer iniciar sessão (ex. ubuntu, root, deploy).
  • Autenticação — escolha entre palavra-passe ou chave SSH (recomendado).

Verificação da impressão digital do host

Na primeira ligação, o SSHBorg mostra a impressão digital do servidor e pede que a aceite. É uma verificação de segurança: garante que está a ligar à máquina correta e não a um impostor. Verifique se a impressão digital corresponde à fornecida pelo administrador do servidor antes de aceitar.

Uma vez aceite, a impressão digital é guardada localmente. Se mudar numa ligação futura, o SSHBorg avisá-lo-á — pode indicar uma reconstrução do servidor, uma rotação de chaves ou um ataque man-in-the-middle.

// DICA
Pode verificar a impressão digital do servidor a qualquer momento com: 
ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub

// CHAVES SSH

A autenticação por chave é mais segura do que as palavras-passe e, após a configuração, não requer memorizar nem digitar nada.

Gerar uma chave

Vá a Definições → Chaves SSH → Gerar nova chave. O SSHBorg suporta:

  • Ed25519 — recomendado. Rápido, compacto e seguro.
  • ECDSA (P-256 / P-384) — boa compatibilidade com servidores mais antigos.
  • RSA (2048 / 4096 bits) — compatibilidade máxima, mas mais lento.

Dê à chave um nome significativo (ex. meu-vps ou servidor-trabalho) para a identificar mais tarde.

// NOTA DE SEGURANÇA
O SSHBorg não permite intencionalmente a exportação de chaves privadas. A chave nunca sai do dispositivo. Se precisar da mesma chave noutro dispositivo, gere uma nova lá e autorize-a separadamente nos seus servidores — é a abordagem mais segura.

Autorizar a chave no servidor

Após gerar uma chave, toque nela para ver a chave pública. Copie-a e cole-a no ficheiro ~/.ssh/authorized_keys do servidor para o utilizador pretendido.

  1. No telemóvel, abra SSHBorg → Definições → Chaves SSH → toque na chave → copie a chave pública.
  2. Inicie sessão no servidor (com palavra-passe ou com outra chave já disponível).
  3. Adicione a chave pública ao ficheiro de chaves autorizadas: 
    mkdir -p ~/.ssh
chmod 700 ~/.ssh
echo "ssh-ed25519 AAAA...suachavecopiada..." >> ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keys
  4. Tente ligar com o SSHBorg — deverá iniciar sessão sem pedir palavra-passe.
// REQUISITO DO SERVIDOR
Certifique-se de que o servidor tem PubkeyAuthentication yes em /etc/ssh/sshd_config. É o predefinido na maioria das distribuições, mas algumas imagens reforçadas desativam-no.

Cifração adicional da chave

O SSHBorg oferece uma frase-passe adicional opcional para as suas chaves (Definições → Chaves SSH → toque numa chave → Ativar cifração). Quando ativa, a chave é cifrada com uma frase que o SSHBorg não guarda — será pedida sempre que a chave for usada.

Fortemente recomendado se guarda credenciais sensíveis no telemóvel ou se tem o bloqueio biométrico desativado.

// SUGESTÕES DE COMANDOS

O SSHBorg mostra uma barra de sugestões acima do teclado enquanto digita no terminal. As sugestões provêm do histórico de shell do utilizador com que se ligou.

Como funciona

Quando uma sessão terminal é aberta, o SSHBorg lê o ficheiro de histórico de shell no servidor remoto. Verifica as seguintes localizações por ordem:

  1. ~/.bash_history — predefinido para shells Bash
  2. ~/.zsh_history — predefinido para Zsh (também verificado como $HISTFILE se definido)
  3. ~/.local/share/fish/fish_history — para utilizadores de Fish shell

O primeiro ficheiro que existe e é legível é utilizado. Enquanto digita, os comandos são filtrados em tempo real e mostrados como chips na barra de sugestões. Toque num chip para inserir o comando.

Resolução de problemas

Não aparecem sugestões

  • O ficheiro de histórico pode ainda não existir (primeiro início de sessão ou shell não configurado para guardar o histórico).
  • Certifique-se de que o shell está configurado para guardar o histórico. Para Bash, adicione ao ~/.bashrc: 
    HISTFILE=~/.bash_history
HISTSIZE=10000
HISTFILESIZE=20000
  • Para Zsh, adicione ao ~/.zshrc: 
    HISTFILE=~/.zsh_history
HISTSIZE=10000
SAVEHIST=10000
setopt APPEND_HISTORY SHARE_HISTORY

As sugestões pertencem ao utilizador errado

// LIMITAÇÃO CONHECIDA
Se se ligar como um utilizador e depois executar sudo su - root (ou mudar para outro utilizador com su), a barra de sugestões continua a mostrar o histórico do utilizador de início de sessão original, não de root. Isto porque o SSHBorg lê o ficheiro de histórico antes de o shell iniciar, usando as credenciais de ligação.

Para obter sugestões do histórico de root, adicione uma entrada de host separada no SSHBorg configurada para iniciar sessão diretamente como root (se o servidor permitir).

// REENCAMINHAMENTO DE AGENTE

O reencaminhamento de agente SSH permite usar as chaves guardadas no SSHBorg para autenticar ligações adicionais feitas a partir de dentro do servidor remoto — por exemplo, para git clone de um repositório privado, ou para saltar para uma segunda máquina.

Ativar o reencaminhamento no SSHBorg

Ao adicionar ou editar um host, ative o interruptor Reencaminhamento de agente. O SSHBorg atuará como agente SSH para essa sessão.

Configuração no servidor

O servidor tem de permitir o reencaminhamento de agente. Verifique /etc/ssh/sshd_config:

AllowAgentForwarding yes

Este é o predefinido na maioria dos sistemas. Após alteração, reinicie o daemon SSH:

sudo systemctl restart sshd

Configuração de cliente por host (opcional)

Se também se liga a este servidor a partir de um portátil ou computador de secretária, pode configurar o reencaminhamento de forma permanente no seu ~/.ssh/config local:

Host myserver
    HostName 203.0.113.42
    User ubuntu
    ForwardAgent yes
// NOTA DE SEGURANÇA
O reencaminhamento de agente dá ao servidor remoto acesso temporário ao socket do seu agente SSH. Um utilizador root (ou um processo comprometido) nesse servidor poderia usar as suas chaves para se ligar a outros sítios enquanto a sessão está ativa. Ative o reencaminhamento apenas em servidores de confiança.

// QUEDAS DE LIGAÇÃO E MULTIPLEXADORES

O SSH é uma ligação TCP ativa entre o seu telemóvel e o servidor. Se a ligação for interrompida — mesmo por um segundo — a sessão e tudo o que estava a correr nela perde-se.

Porque caem as ligações no móvel

As redes móveis são particularmente propensas a quedas de ligação por várias razões:

  • Mudanças de endereço IP — ao viajar ou mudar de antena, o seu operador pode atribuir-lhe um novo IP público. Como as ligações TCP estão ligadas ao endereço IP, a sessão SSH existente torna-se imediatamente inválida.
  • Mudança Wi-Fi ↔ dados móveis — mudar entre uma rede Wi-Fi e dados móveis (ou vice-versa) altera o seu IP e quebra qualquer ligação TCP aberta.
  • Tempos limite de inatividade — operadores e routers NAT encerram frequentemente ligações inativas após alguns minutos. As sessões ativas mas silenciosas (observar logs, aguardar entrada) são vulneráveis.
  • Perda de sinal — túneis, parques de estacionamento subterrâneos ou simplesmente um sinal fraco podem interromper brevemente a rede, o que é suficiente para terminar uma sessão.
// IMPORTANTE
Se estiver a executar um comando longo (uma compilação, uma cópia de segurança, uma migração de base de dados) diretamente no terminal SSH e a ligação cair, o comando é interrompido imediatamente. Qualquer trabalho parcial pode ficar num estado inconsistente.

A solução: tmux ou screen

Um multiplexador de terminal executa uma sessão persistente no servidor, completamente independente da sua ligação SSH. Se a ligação cair, a sessão e tudo o que está a correr continua. Ao religar, reincorpora-se e encontra tudo exatamente como deixou.

É o hábito mais útil para quem gere servidores a partir do telemóvel.

Início rápido com tmux

tmux está disponível na maioria das distribuições Linux modernas e é a escolha recomendada.

# Iniciar uma nova sessão com nome
tmux new -s work

# Desligar da sessão (deixá-la a correr)
Ctrl+B, depois D

# Listar sessões em execução
tmux ls

# Religar a uma sessão
tmux attach -t work

# Religar à sessão mais recente
tmux attach

Início rápido com screen

screen é mais antigo mas disponível em praticamente qualquer sistema Unix, incluindo imagens mínimas onde tmux pode não estar instalado.

# Iniciar uma nova sessão com nome
screen -S work

# Desligar da sessão
Ctrl+A, depois D

# Listar sessões em execução
screen -ls

# Religar a uma sessão
screen -r work

Fluxo de trabalho recomendado no móvel

  1. Ligue ao servidor com o SSHBorg.
  2. Inicie ou reincorpore-se imediatamente a uma sessão tmux/screen: tmux attach || tmux new -s main
  3. Execute os seus comandos dentro do multiplexador.
  4. Se a ligação cair, basta religar — a sessão ainda está lá.
// DICA
Pode adicionar tmux attach || tmux new -s main ao seu ~/.bashrc ou ~/.zshrc no servidor para que uma sessão de multiplexador inicie automaticamente sempre que iniciar sessão via SSHBorg.

// JUMP HOSTS

Um jump host (também chamado bastion host) é um servidor intermédio pelo qual tem de passar para alcançar um servidor alvo não diretamente acessível a partir da internet. O SSHBorg suporta nativamente cadeias de salto simples e multi-salto.

Configurar um jump host no SSHBorg

  1. Adicione o servidor bastião como host normal no SSHBorg (ex. bastion).
  2. Adicione o servidor alvo como outro host.
  3. Nas definições do host alvo, defina Jump host para o bastião criado.
  4. Ative Reencaminhamento de agente na entrada do bastião — isto permite que a sua chave seja reencaminhada através do bastião para autenticação no alvo.
// COMO FUNCIONA
O SSHBorg estabelece primeiro uma ligação SSH ao bastião e depois abre um canal TCP reencaminhado através dele para o servidor alvo. A chave privada nunca sai do telemóvel — o bastião apenas faz proxy do fluxo cifrado.

Cadeias multi-salto

Se precisar de saltar por mais de um servidor intermédio (ex. internet → bastião → dmz → alvo), crie uma entrada para cada salto e encadeie-as:

  • bastion — sem jump host, reencaminhamento de agente ativo
  • dmz — jump host = bastion, reencaminhamento de agente ativo
  • target — jump host = dmz
// IMPORTANTE
O reencaminhamento de agente tem de estar ativo em cada salto intermédio, não apenas no primeiro. Sem isso, a cadeia de autenticação quebra e a ligação ao servidor final falhará com um erro "permission denied".

Configuração manual equivalente (para referência)

A configuração equivalente num ~/.ssh/config de computador tem este aspeto:

Host bastion
    HostName bastion.example.com
    User admin
    ForwardAgent yes

Host target
    HostName 10.0.1.50
    User ubuntu
    ProxyJump bastion
    ForwardAgent yes

Com esta configuração, ssh target no seu computador salta transparentemente pelo bastião.

Requisitos de firewall

  • O telemóvel tem de conseguir alcançar o bastião na sua porta SSH (normalmente 22).
  • O bastião tem de conseguir alcançar o alvo na sua porta SSH.
  • O alvo não precisa de ser alcançável diretamente a partir do telemóvel.

// SESSÕES MÚLTIPLAS

O SSHBorg permite manter várias sessões de terminal SSH e gestor de ficheiros SFTP abertas ao mesmo tempo, mesmo para servidores diferentes.

  • Abra uma sessão a partir do ecrã de hosts tocando em Terminal ou SFTP.
  • Mude entre sessões abertas usando o seletor de sessões no topo do ecrã.
  • As sessões permanecem ativas em segundo plano enquanto a ligação de rede se mantiver.
  • A lista de hosts mostra um pequeno distintivo junto a cada host com o número de sessões SSH e SFTP ativas, para ver de relance o que está aberto.
// DICA
Comandos de longa duração (compilações, cópias de segurança, seguimento de logs) continuam a correr mesmo quando muda para outra sessão. Use um multiplexador de terminal como tmux ou screen no servidor se quiser que sobrevivam mesmo a uma queda de ligação SSH.

// SEGURANÇA DA APP

Bloqueio biométrico

Ative o bloqueio biométrico em Definições → Segurança → Bloqueio biométrico. Quando ativo, o SSHBorg exige impressão digital ou reconhecimento facial antes de mostrar qualquer host, credencial ou dados de sessão.

Pode definir um tempo limite de inatividade — após esse número de minutos em segundo plano, a app bloqueia automaticamente.

Proteção de capturas de ecrã

Por predefinição, o SSHBorg bloqueia capturas de ecrã e gravação de ecrã para evitar que conteúdo sensível do terminal vaze através do ecrã de apps recentes ou ferramentas de captura.

Se precisar de fazer uma captura (ex. para partilhar uma saída do terminal), pode desativar temporariamente a proteção em Definições → Segurança → Permitir capturas.

Armazenamento de credenciais

Todas as credenciais (palavras-passe, chaves privadas, frases-passe) são guardadas cifradas usando o Android Keystore — um enclave seguro baseado em hardware disponível no Android 10+. Nunca são escritas em armazenamento externo nem transmitidas para lado nenhum.

// NOTA SOBRE CÓPIAS DE SEGURANÇA
Como as chaves são guardadas no Android Keystore, não podem ser incluídas na cópia de segurança na cloud do Android e não serão transferidas automaticamente para um novo telemóvel. Antes de mudar de dispositivo, certifique-se de autorizar uma nova chave gerada no novo dispositivo em todos os seus servidores.
⚙⚙⚙