Transferências de servidor para servidor com a CLI do Relayium (daemon direto)

Última atualização: 2026-09-01

Quando as duas máquinas são suas e cada uma conhece o endereço da outra, o SSH é um atrito a mais e um encontro é puro overhead. O daemon direto foi feito exatamente para isso: um servidor escuta, o outro faz push direto para ele sobre uma conexão TLS 1.3 com fixação. Sem retransmissor, sem SSH, sem código de emparelhamento: a confiança é por chave pública e é configurada uma única vez.

Este guia cobre iniciar o processo à escuta, fazer push para ele, aprovar um novo emissor no primeiro contato, automatizá-lo e executar o processo à escuta como um serviço do systemd.

Antes de começar

Tudo abaixo é a CLI do relayium, então instale-a primeiro se ainda não tiver. No macOS ou Linux, um comando coloca um binário pré-compilado no seu PATH:

curl -fsSL https://relayium.com/install.sh | sh

Prefere escolher o arquivo você mesmo, ou está no Windows? Pegue um binário na página de releases — relayium.com/cli lista todas as opções de instalação (ou go build -o relayium ./cmd/relayium se você tiver Go).
relayium --version confirma que está instalada. Pule isso e os comandos abaixo só imprimirão “command not found”.

Iniciar o processo à escuta (no receptor)

O que você precisa

Duas máquinas sob o seu controle, com o endereço do receptor alcançável a partir do emissor. Serve um nome de host ou um IP puro.
O relayium nas duas pontas. O daemon direto só fala o protocolo nativo, então aqui não existe alternativa com tar para salvar uma instalação faltando.
A porta do processo à escuta aberta ao emissor — 9031/TCP enquanto você não mudar — no firewall do host e em qualquer grupo de segurança na nuvem.
Um terminal no receptor para o primeiro push, para responder ao pedido de aprovação. Sem terminal, autorize o emissor de antemão (veja abaixo).

No servidor receptor, serve escuta os pushes e os escreve em um diretório. Ele roda continuamente por padrão; adicione --once para aceitar uma única transferência e sair. Você não compartilha nada com antecedência: não há impressões digitais para copiar antes:

Crie o diretório onde os envios devem aterrissar.
```
mkdir -p ~/inbox
```
Abra a porta do processo à escuta somente para o emissor. Substitua 203.0.113.7 pelo endereço do próprio emissor — o IP público, ou o privado se os dois servidores compartilham uma rede — e restrinja o grupo de segurança da nuvem à mesma origem em vez de à internet inteira.
```
sudo ufw allow from 203.0.113.7 to any port 9031 proto tcp
```
Inicie o processo à escuta num terminal, para que haja alguém para responder ao pedido de aprovação no primeiro push. Com --once ele aceita uma única transferência e sai; com --port você o tira de 9031.
```
relayium serve --dir ~/inbox
```

Como é um processo à escuta em execução

O serve informa o endereço em que se ligou, o diretório em que escreve e a impressão digital do próprio host. Enquanto não houver pares aprovados, ele também avisa que vai perguntar sobre cada novo.

relayium serve --dir ~/inbox
no authorized peers yet — you'll be asked to approve each new peer on its first push.
relayium serve: listening on [::]:9031, receiving into /home/you/inbox (fingerprint 5c1d9f04…)

O processo à escuta processa as conexões uma de cada vez e deposita os arquivos em --dir.
A porta padrão é 9031; altere-a com --port e abra-a no seu firewall.

Fazer push para ele (no emissor)

Do servidor emissor, faça push para o endereço relayium:// do receptor. A primeira conexão fixa a impressão digital do receptor; toda conexão posterior a verifica, e uma impressão digital alterada é recusada em vez de aceita silenciosamente — assim, uma chave trocada ou um ataque de intermediário é detectado, não confiado. No primeiro push, o emissor espera um momento enquanto o receptor o aprova (próximo passo).

Rode o push a partir do servidor emissor. Na primeiríssima conexão ele para exatamente aqui enquanto o receptor o aprova.
```
relayium push ./build.tar.zst relayium://receiver.example.com
```
Responda ao pedido no receptor: é a seção seguinte. Depois o push termina sozinho, e os push seguintes nunca mais param aqui.
Acrescente uma porta quando o processo à escuta não estiver na 9031.
```
relayium push ./build.tar.zst relayium://receiver.example.com:9040
```

Como é um push bem-sucedido

No primeiro contato o emissor aprende e fixa a impressão digital do processo à escuta e então transfere. O receptor anota a impressão digital de quem empurrou e informa a contagem de arquivos e de bytes.

# on the SENDER, first contact
learned receiver.example.com:9031 5c1d9f04… (added to known_hosts)
  build.tar.zst (48213004 bytes)

# on the RECEIVER
authorized 74318e3b… (added to /home/you/.config/relayium/authorized_fingerprints)
received 1 file(s), 48213004 bytes from 74318e3b…

Sem retransmissor e sem retorno: se o processo à escuta não for alcançável, o push falha — os bytes do arquivo nunca são roteados por mais ninguém.
O mesmo motor de transferência dos outros modos: cada arquivo é conferido com um SHA-256 por arquivo e preparado em área temporária antes de ser instalado. O push não retoma, nem aqui nem por SSH — ele recusa um destino que já existe. Uma execução interrompida se conclui enviando os caminhos que faltam, ou com o relayium sync, que continua um arquivo parcial e que este processo à escuta respeita, a menos que tenha sido iniciado com --no-resume.

Aprovar o emissor no primeiro push (no receptor)

Na primeira vez que uma máquina nova faz push para o seu processo à escuta, serve (em um terminal) mostra de onde ela vem e sua impressão digital e pede que você a aprove — como o prompt de primeira conexão do SSH, mas no lado receptor:

# no RECEPTOR, quando um novo emissor faz push:
Incoming push from 203.0.113.7:54021
  fingerprint: 74318e3b…
Accept and remember this peer? [y/N] y

Responda y e essa impressão digital é lembrada em authorized_fingerprints; cada push posterior da mesma máquina passa então em silêncio.
A impressão digital é a identidade estável de uma máquina (sobrevive a reinicializações e mudanças de IP), então aprovar é um passo único por emissor.
O emissor, por sua vez, aprende a chave do processo à escuta na primeira conexão (confiança no primeiro uso) e a fixa em known_hosts.

Automatizá-lo (ou executá-lo sem terminal)

Como uma impressão digital aprovada é lembrada, os pushes posteriores não precisam de prompt, então relayium push se encaixa direto em um script de deploy ou CI para uma entrega de servidor para servidor criptografada e com integridade verificada. Para um trabalho agendado que escreve no mesmo diretório, use o relayium sync no lugar: o push recusa um destino que já existe, então um push repetido para um caminho fixo dá certo uma vez e é recusado depois. Quando serve roda sem terminal (um serviço do systemd, um pipe) ele não pode perguntar, então rejeita emissores desconhecidos; pré-autorize-os em vez disso. Obtenha a impressão digital com relayium id no emissor, ou copie-a da linha “rejected unauthorized peer …” no log do serve, e então:

# no RECEPTOR: pré-autorize um emissor sem prompt
relayium authorize --config-dir /etc/relayium 74318e3b...

Os arquivos de identidade e confiança ficam em ~/.config/relayium/ (substitua com --config-dir, por exemplo /etc/relayium para um serviço).
authorize é idempotente — executá-lo novamente para a mesma impressão digital não faz nada.

Executar o processo à escuta sob systemd

Para uma caixa de entrada sempre ativa, execute serve como um serviço do systemd. Aponte --config-dir para um local fixo como /etc/relayium para que a identidade seja estável entre reinicializações, e deixe o systemd mantê-la viva:

# /etc/systemd/system/relayium-serve.service
[Unit]
Description=Relayium daemon-direct listener
After=network-online.target

[Service]
ExecStart=/usr/local/bin/relayium serve --dir /srv/inbox --config-dir /etc/relayium
Restart=always
User=relayium

[Install]
WantedBy=multi-user.target

systemctl enable --now relayium-serve para iniciá-lo e subi-lo no boot.
Mantenha /etc/relayium/id.key legível apenas pelo usuário do serviço — relayium se recusa a carregar uma chave com permissões frouxas.

Quando um push não passa

Alcançabilidade e confiança são as duas primeiras coisas a verificar: ss -tinp no emissor diz se o processo à escuta chegou sequer a ser alcançado, e relayium authorize no receptor concede a um emissor recusado a confiança que lhe falta. Não são as únicas formas de um push falhar — um receptor sem espaço em disco, um diretório de entrada em que o seu usuário não pode escrever, ou um arquivo transferido que falha na verificação de integridade anunciam-se todos sozinhos — então leia o erro à sua frente em vez de supor que é um dos quatro abaixo.

Sintoma, verificação, correção

O push fica parado e depois falha com um erro de conexão.

# no EMISSOR, enquanto o push está rodando — execute duas vezes, com alguns segundos de intervalo
ss -tinp dst :9031
# ESTAB    o processo à escuta foi alcançado; não diz nada sobre progresso
# SYN-SENT nada respondeu naquela porta

SYN-SENT significa que os pacotes nunca chegaram a um socket à escuta. Confirme no receptor que o serve está no ar com ss -tlnp | grep 9031 e então abra 9031/TCP para o emissor no firewall do host e no grupo de segurança da nuvem. ESTAB prova apenas alcançabilidade — um socket estabelecido pode ficar ocioso ou travado —, então, para separar o que anda do que está parado, rode a verificação duas vezes com alguns segundos de intervalo e compare o contador bytes_acked que o -i imprime para aquele socket. Aqui não há caminho por retransmissor, então um processo à escuta inalcançável é uma falha seca, não uma lentidão.

O log do serve diz “rejected unauthorized peer …” e o push falha.

# no EMISSOR
relayium id
# 74318e3b…

# no RECEPTOR
relayium authorize --config-dir /etc/relayium 74318e3b…

O serve não tinha nenhum terminal a quem perguntar — uma unidade do systemd, um pipe — então uma impressão digital desconhecida é recusada em vez de aceita. Autorize-a de antemão: a impressão digital da linha de recusa é exatamente a que relayium id imprime no emissor, e o authorize é idempotente.

“fingerprint mismatch for receiver.example.com:9031”.

grep receiver.example.com ~/.config/relayium/known_hosts

O processo à escuta apresentou uma chave diferente da que foi fixada no primeiro contato. Se você girou essa chave de propósito, apague a linha correspondente do known_hosts e faça o push de novo. Se não foi você, deixe a linha em paz e descubra por que a chave mudou antes de enviar qualquer coisa.

A unidade do systemd morre na inicialização com um erro de permissões inseguras.

systemctl status relayium-serve
# secure: /etc/relayium/id.key has insecure permissions 0644; run: chmod 600 /etc/relayium/id.key
ls -l /etc/relayium/id.key

O relayium se recusa a carregar uma chave privada que qualquer um além do dono consiga ler, a mesma regra que o ssh aplica. Rode chmod 600 no caminho que o erro nomeia, confirme que ele pertence ao usuário do serviço e reinicie a unidade.

Perguntas frequentes

Em que o daemon direto difere de push por SSH?

push por SSH tunela a transferência pela sua conexão SSH e precisa de uma conta SSH no remoto. O daemon direto não precisa de SSH nem de conta — os dois servidores se autenticam mutuamente pela impressão digital do certificado sobre TLS com fixação, o que é mais leve quando as duas máquinas são suas.

Preciso copiar impressões digitais à mão de um lado para o outro?

Não. Em um terminal, serve pede que você aprove cada novo emissor no seu primeiro push — mostrando seu endereço e sua impressão digital — e o lembra, então os pushes posteriores são silenciosos. Você só recorre a relayium id ou relayium authorize em configurações não interativas como um serviço do systemd, onde não há ninguém para responder ao prompt.

Onde estão os arquivos de identidade e confiança?

Em ~/.config/relayium/ por padrão (substitua com --config-dir). id.key / id.crt são a identidade persistente deste host, known_hosts guarda as impressões digitais dos processos à escuta para os quais você fez push, e authorized_fingerprints é a lista de permissão de emissores do processo à escuta.

O que acontece se uma impressão digital mudar?

O push é recusado e avisa. A chave do processo à escuta é fixada em known_hosts no primeiro uso, então uma mudança posterior — um host com chave regenerada ou um ataque de intermediário — é rejeitada em vez de aceita silenciosamente. Remova a linha do known_hosts apenas se você rotacionou a chave intencionalmente.

Existe algum retorno por retransmissor?

Não. O daemon direto pressupõe um endereço de processo à escuta alcançável; se a conexão não puder ser feita, ela falha. Nada é jamais roteado via proxy pelo Relayium — esse é o propósito deste modo.

Conecte dois dos seus próprios servidores para transferências diretas — sem retransmissor, sem SSH, sem código de emparelhamento.

Obter a CLI