Best practice for exporting identity files from a Ziti-protected host?

1

Hello Ziti community,

We’re running into a practical challenge with backing up identity files and would love your advice.

Setup:

  • Host alpha (Ubuntu VPS) is protected by Ziti — only accessible through the gateway node (also Ubuntu).

  • Port 22 is blocked externally (zero trust posture). SSH access works fine using ssh alpha through Ziti tunneling.

  • Identity files live in /opt/openziti/etc/identities/ on alpha (e.g. config.json, alpha-host.json).

Goal:

Back up these identity files securely onto a developer laptop (macOS), so we can archive them off-host.

What we tried:

  1. scp via Ziti alias:

    1. scp -r alpha:/opt/openziti/etc/identities/* ~/Identities/alpha/

  →   Result: Permission denied because files require sudo.
  1. tar + ssh stream with sudo:
ssh -tt alpha 'sudo tar czf - -C /opt/openziti/etc/identities .' \ > ~/Identities/alpha/alpha-identities.tar.gz

Result: prompts for sudo password, but often closes the tunnel after entering it (connection closes).

  1. scp with sudo cat workaround:
ssh -t alpha 'sudo cat /opt/openziti/etc/identities/config.json' > ~/Identities/alpha/config.json

Same issue, requires sudo and session ends.

Problem:

Because port 22 is closed to the internet, we cannot temporarily fall back to a direct scp.

Through Ziti tunneling, the SSH session works fine, but interactive sudo breaks file transfers.

Question:

:backhand_index_pointing_right: What’s the recommended/best-practice way to export or back up /opt/openziti/etc/identities/ from a Ziti-protected host like this?

Should we:

  • Add a one-time secure “file transfer” service in Ziti?

  • Use sudo tee with base64 encode/decode over SSH?

  • Or is there a simpler, officially recommended workflow?

Any guidance would be super helpful :folded_hands:

2

To be completely honest, the 'best practice' is DO NOT DO THIS... So that's the "best practice"... With that out of the way, the next answer is "store secrets however you deem it acceptable to store secrets". Identity files contain private keys and must be treated as confidential secrets. Backing them up really isn't recommended.

With all that out of the way, it sounds like you're running into a different problem. The way you describe it, I believe you have some machine somewhere that is not accessible in any way shape or form OTHER than by using OpenZiti. Is that correct, and you're trying to test a disaster recovery type of scenario?

I'm confused as to why you'd be using ssh or scp at all if port 22 was totally blocked so I feel like there's a piece of this puzzle that's missing or I'm not understanding

3

Dear TheLumberJack,

Thanks a lot for the quick reply :folded_hands:, it is well appreciated.

Let me clarify our setup so there’s no confusion:

  • I do not expose port 22 on the internet. It’s blocked in UFW.

  • SSH works only via the Ziti overlay (e.g. ssh alpha) — so all admin access is already tunneled through Ziti.

  • The issue is not with “SSH not being available.” SSH works fine over Ziti.

The real problem is:

  • Identity files live under /opt/openziti/etc/identities/ and require sudo to read.

  • When I tried to use scp or tar | ssh through the Ziti tunnel, the sudo password prompt breaks the stream and the session closes.

So the challenge is how to securely copy root-owned files off-host when the only way in is through Ziti SSH.

I am not asking “should we back up identities” (I understand the risk and will protect them as secrets).

I am asking: What is the best workflow to copy these files through Ziti SSH without needing to re-open port 22 externally?

Would you recommend:

  1. Setting up a temporary Ziti service for secure file transfer (e.g. SFTP-over-Ziti)?

  2. Using a base64 | tee trick over SSH to capture files safely?

  3. Or is there another officially recommended pattern you’ve seen work in the community?

Thanks again for clarifying — I just want to make sure we’re aligned on the actual scenario (SSH over Ziti, not raw port 22).

4

--EDITed forgot it's being accessed via ssh...--

@qrkourier (or someone with a bit more linux foo than I have) would be great to have comment.

You could grant that user that is ssh'ing access to that path. That'd be what I would do. Let the user ssh'ing access the file using group/user permissions

5

Yes, suppose you installed the ziti-edge-tunnel package in Linux, and have a POSIX group named “ziti” that can access the agent socket and identity files, and you are logging in with SSH as user named “bob”.

You must add “bob” to group “ziti” and re-login.

sudo usermod -aG ziti bob

Re-login with SSH

Alternatively, you can run sudo interactively so you can type a password via SSH if, when you run ssh , add the ssh -t flag to provision an interactive session.

1 Like
6

Awesome, Thanks a lot. Works perfectly !!!

1 Like