I'm trying to set up consistent remote access to a linux machine via ssh over zrok:
Run on remote: zrok share private --backend-mode tcpTunnel 127.0.0.1:22
Run on local zrok access private xxxxx
Run on local in another terminal: ssh -p 9191 uname@127.0.0.1
This works great and I can happily use ssh.
However, when I run the share command in my startup script like this:
nohup zrok share private --backend-mode tcpTunnel 127.0.0.1:22 &
or
screen
zrok share private --backend-mode tcpTunnel 127.0.0.1:22
I get a
kex_exchange_identification: read: Connection reset by peer
Connection reset by 127.0.0.1 port 9191
error when trying to ssh in.
This error also appears in the local zrok window:
│[ 5.113] ERROR zrok/endpoints/tcpTunnel.(*Frontend).accept: error │
│dialing 'mubutnn93yev': unable to dial service 'mubutnn93yev': dial failed: │
│service 2U0JVJKVbl8R5uZXxgxaGC has no terminators │
Why is this, and is there a smarter way to start the zrok share programmatically that anyone uses already?
Cheers,
T
I suspect you need the --headless option in zrok share private so it only logs and doesn't try to display the terminal UI.
Another option is using Docker with network mode "host" so the zrok container can "see" your Docker host's 127.0.0.1:22. Here's a guide: Docker Private Share | Zrok. The Docker container uses the --headless option too, and has the added benefit of providing process management for things like auto-start after a reboot, which you could also achieve by creating a systemd service definition if you prefer to avoid Docker.
If you do feel like using Docker and you get to the part about downloading the Compose file for the share, then you can edit this part to have network_mode: host.
zrok-private-share:
network_mode: host
image: docker.io/openziti/zrok
command: share private --headless --backend-mode tcpTunnel 127.0.0.1:22
depends_on:
zrok-enable:
condition: service_completed_successfully
volumes:
- zrok_env:/mnt/.zrok
environment:
HOME: /mnt
PFXLOG_NO_JSON: "true"
This doesn't mean you have to use Docker on the ssh client side, but you could if you want.
I'm trying to run a very similar command on my work mac for the same reason (remote ssh control):
zrok share private --headless --backend-mode tcpTunnel 127.0.0.1:22
and am getting the same "service has no terminators" error on the client side.
Why could this be?
"service has no terminators" is very odd. Does it happen every time? This error is one that comes from the underlying OpenZiti overlay network, but it's very much unexpected. Are you self-hosting zrok or are you using the zrok.io SaaS offering?
I think this means the no terminators error was emitted when you ran something like this.
zrok access private --headless cdthz0z5fzzx
I'm using the zrok.io network, I can see that the host machine is being accessed by the client via api.zrok.io but no traffic shows up in the graph.
Yeah, that's really unexpected then. Can you reproduce it every time?
I wonder if it might be that your script is operating too fast? That's probably what it is... Can you loop the script a few times if you get that error with a sleep in between and see what happens? It probably takes 5-15 seconds for a share to get created. (ASSUMING you're creating a share then trying to access it immediately)
You mean the script on the host side?
Right now I'm running the command in terminal as a test, not seeing any output in the host console (even with -v argument) when I run the client access command.
I must admit, I haven't really ascertained exactly what your flow looks like yet. I am expecting you're running a command to create a share somewhere, then running the script to access the share and that accessing of the share is the one that's failing because the 'create' process is taking a bit of time?
But, we can level-set and I can just ask, "exactly what are you doing and how"? Can you share the script and methodology so that I can test it myself and replicate the problem? If you can reproduce it, it's a good chance I can reproduce it and it'll let me understand what you're doing and how.
Can you give me the script/steps to reproduce and I'll try with my env?
I have someone else who is reporting the same erorr at this time. zrok.io might be having "a blip"...
yeah. zrok is having an issue at this moment. i'm getting the same issue... I'll post back after we get it sorted.
Yes, sorry.
My exact workflow:
- Enable remote management in settings on work computer ("server", mac mini M2 Ventura 13.4)
- Test ssh on local network from personal computer ("client", macbook pro M2 Sonoma 14.2) using the following command:
ssh macminiusername@macminihostname.local, enter password and confirm that ssh server is running on the server mac.
- Download zrok arm64 binary on server mac, move to applications folder and add to path
- Enable zrok with token from api.zrok.io on server mac.
- Run on server mac:
zrok reserve private --backend-mode tcpTunnel 127.0.0.1:22 and get reserved share token
- Run on server mac:
zrok share reserved xxxxxx, zrok fires up
- Run on client mac: `zrok access private xxxxx, connection window opens, dotted line appears between the share and the access nodes on api.zrok.io.
- Run on client mac in new terminal:
nc 127.0.0.1 9191, command exits with a blank string
- Go back to zrok window on 1st terminal and read error:
ERROR zrok/endpoints/tcpTunnel.(*Frontend).accept: error dialing │
│'xxxxxxxxxxx': unable to dial service 'xxxxxxxxxxx': dial failed: service │
│xxxxxxxxxxxxxxxx has no terminators
Thanks for the quick responses
Edit:
Just saw your response and can try again after the reboot, thanks again.
Thanks for that.
Ok, things should be back and operational hopefully. Things are working on my side again. We had an OpenZiti overlay network upgrade today and it would seem as though something happened to cause this issue with zrok...
We'll be investigating the issue to determine what happened, adding more alerts etc...
Thanks for bringing this to our attention! Please try again and lemme know if it's fixed.
Working now, cheers and thank you.
1 Like
Hi guys,
After it working well yesterday, I am unable to get the zrok ssh connection going today.
Getting the same service xxx has no terminators message.
Any leads?
Best,
T
Hi @twisteddog99. I think we're experiencing some "unexpected success" that's putting strain on zrok in certain places. We're working through it, adding alerts, trying to find issues, etc. We move fast, so we should be able to figure out what is happening and fix it soon. Until then, we appreciate your patience with us as we work through it... 
Ok and thanks @TheLumberjack.
Do you think self-hosting would be a temporary solution?
T
We have added additional health checking in the last few days. Those checks have indicated things have been working properly but sure, it's possible another issue crops up. You could self-host, sure, that's always an option but I'd be interested in knowing if you're experiencing issues that we're not noticing? That'd be really good information for us since it'd indicate we missed a problem with the new monitoring (a gap we'd surely like to fix if that were the case).
Are you running into more troubles today? I've been using it all day myself playing around for home-lab stuff and it's been fine for me, personally, but maybe you're hitting an issue I'm not.