issue with ssh forwarding

Support
1

I have Sncthing set up on a banana pi running Debian. This is a headless setup so I’m trying to connect to the gui by setting up an ssh tunnel like so:

ssh -L 8080:127.0.0.1:8384 user@bananapi

the ssh connection is successful, however when i try to open 127.0.0.1:8080 in a browser the page doesn’t load and the ssh session throws the following error:

channel 3: open failed: connect failed: Connection refused

Every once in a while (say 1 out of every 100 connection attempt) the gui does open up and the error is not shown, however i don’t see that connected to any action i take.

I am seeing the same issue on a different machine running Ubuntu 16.04 headless. Another Ubuntu machine as well as another banana pi running the same version of Debian and Syncthing almost always work without a hitch.

I should also mention that on the Ubuntu machine with the issue another ssh port tunnel works flawlessly (for Duplicati).

I checked that sshd_config has AllowTcpForwarding yes in both host machines.

Any pointers on where to start looking for the source of the problem would be super appreciated.

2

It seems that either syncthing is not running or running on a different port as that happens, as that is what connection refused means.

3

That would have been my first guess as well, however i checked the config.xml of Syncthing on both machines and it is indeed listening on 8384, checked that it’s running as well.

4

I suggest checking ssh logs. Sadly this is more of an ssh issue than a syncthing issue so I am not sure how much help you’ll manage to get here.

5

I made an interesting discovery: after connecting with the ssh tunnel if i run systemctl --user status syncthing and then immediately after that sudo systemctl status syncthing and then i try reloading the gui, it does load without issues.

I’m not sure why this is yet.

I set up two brand new machines on DO with Ubuntu 16.04, installed syncthing on both and i see the same: first the error, then after the double status check the gui loads. As these are brand new machines, the ssh settings are default except for AllowUser and AllowTcpForwarding directives.

6

I wonder if it’s some sort of systemd process isolation/socket activation nonsense. See if running syncthing outside of systemd fixes the issue.

1 Like
7

It is not systemd, at least not with default debian settings - port forwarding works just fine here.

8

i’m seeing this on Ubuntu 16.04 with no custom settings (right after clean install) so Ubuntu could be touching the default systemd setup somehow (although i’m not at all sure, just guessing)

9

Is it maybe that Syncthing starts when you log in, and isn’t yet ready when you try the first time?

10

Interesting, that does seem to be the case. Opening the ssh session and then waiting about a minute or so, the gui opens up without issue.

Would that be a problem with how the service is running?

11

I’m sure the root cause is systemd, probably it has decided that your services should only run while you’re logged in.

12

Come on guys, systemd may be a craken that tries to do everything by itself and may have numerous other flaws, but it’s basic service management isn’t that bad :stuck_out_tongue:

In one of your posts you wrote about both using --user and not with systemctl. There are two fundamentally different types of systemd services: System services and user services (with --user). The difference is simple: System services run on boot and are administered by root, user services run at login and can be administered without root privileges. So I assume you set up systemd user services while you actually wanted system services.

1 Like
14

My guess would be that you are using a low power device like a Raspberry Pi or similar. I’ve got some experience trying to use those as sync servers, and it works more or less okay, depending on the amount of files and the overall space uses. But those slow devices need several minutes (1-35, depending on how slow they are and how resource intensive the stuff you want to sync is).

I dropped the first generation Pis, because they were really slow with their single core, but also because Raspbian had an unfortunate bug back then that regularly made the mount point of USB devices break.

My advice would be to use something with a minimum of two cores and AES-NI if it’s an Intel chip or the comparable AMD/ARM feature. The Zbox C3XX series works well for me with ~20 repos, >1TB total synced files and a healthy mix between really big (1080p+4k videos) and really small files (config + text files).

15

Thanks, I didn’t know user services only ran while logged in. I’m not yet sure how this relates to the second machine that iirc runs sysvinit, though I’ll have to double check that now.

16

@imsodin`s answer from above seems to be correct. Regardless, I’m seeing the same issue on both a Banana Pi which is dual core with 1 gig of ram and a 3 core 8gig VM running on an AMD opteron based host machine. What’s more I have a second Banana Pi set up, same exact model, same version of Debian and that machine doesn’t have the same issue.

That said, the user vs system service suggestion seems to be the source of this indeed.

17

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.