Device Auto Accept

Feature
1

I have a feature request for an automatic connection of devices. Of course there is the introducer option, but its function is slightly different.

Within a LAN, under “Add Device”, I get all the devices it contains to connect. An “Auto Accept” function would be helpful here as an optional option so that you do not have to go into all GUIs to accept each other.

Devices that are outside the LAN are clearly not displayed under “Add Device”. If you could now store an individual, separate device code in each device, which would then be the same in all relevant devices, you could also have the relevant devices connected automatically via and beyond the LAN.

Would it be possible?

1 Like
2

This would be equivalent to offering all files without authentication to the local LAN. I’m not sure that’s a feature we want. When you control the involved devices you can set one to be introducer instead.

3

Agree, introducer and auto-accept are features for trusted devices (even if transient trust). Having this for completely untrusted devices is a no from me.

1 Like
4

Understandable from the point of view. It would also mean taking responsibility accordingly. So I continue to test Introducer, but is not limited to devices, it also recommends appropriate peers and I wanted to avoid that.

5

I think in general introducer and auto-accept are anti-features that are hard to reason about causing a lot of confusion between users and I’m somewhat sad that we’ve caved in and implemented them.

2 Likes
6

actually I find the introducer extremely valuable.

I’ve spent this afternoon setting up a remote readonly device, and a selfhosted discovery, relay servers and a “master” device. (and yes, the three can happily coexist on the same host, provided name resolution resolves to network interface address and not localhost - I’ll just google later how to selfhost a stun server and also change the software update url to localhost to stop flooding the private dns server with queries)

I will need to auto accept several hundreds remote devices.

It’s already useful that I can deploy the remote device using the “distribution” device as an introducer one, it’s already nice that I can click on the master device web UI to accept “invitations”, it’s again extremely useful that I setup the remote to auto accept folders… but it would have been ever cool to be able to set a flag in config.xml to auto accept device invitations, during the deployment phase.

7

I agree. As I understand the introducer only introduces devices for a matching folder share. And if a device already has access to a specific folder then it doesn’t really matter much from a security perspective if another device can also offer that data, since the data is already available anyway.

8

It does matter a lot from security perspective. I, as a malicious actor, can add an empty folder with id “only-to-be-shared-with-x”, and suddenly get access to your folder that I shouldn’t have access to.

9

But your device and my device must already be connected and sharing that folder for your other device to be added.

And then I still have to accept the malicious folder?

10

Thats no longer true if you have device auto-accept, which is what is being argued for here.

11

Ahh gotcha. Yeah I’m not a fan of the device auto accept.

12

With respect, one of the best things about Syncthing is that it was designed to be secure. It seems difficult, at least to me, to configure Syncthing to do something insecure. I like it this way; I think auto accept for devices is a mistake.

1 Like
13

but you (the user) can enable device auto accept only for a short time frame during initial deployment. my support staff would definitely appreciate that, they’ll have to manually click about a thousand times on introducer web UI to accept new devices :slight_smile:

14

The api is there for you to automate it. I don’t think this option is suitable for mainstream.

1 Like
15

I will keep reading the docs, still a novice to this software. Did not know that I could do that using the API, thanks!

1 Like
16

alright. looks like api was the more complicated direction to do it. instead I used much easier the syncthing-cli. noting here for my future self:

$ cat add-all-pending.sh
#!/bin/bash

# Get the list of pending devices
PENDING_DEVICES=$(syncthing cli show pending devices)

# Add each pending device
echo "$PENDING_DEVICES" | jq -c 'to_entries[]' | while IFS= read -r device; do
  DEVICE_ID=$(echo "$device" | jq -r '.key')
  DEVICE_NAME=$(echo "$device" | jq -r '.value.name')
  DEVICE_ADDRESS=$(echo "$device" | jq -r '.value.address')

  # Add the device using syncthing-cli
  echo syncthing cli config devices add --device-id "$DEVICE_ID" --name "$DEVICE_NAME" --addresses "$DEVICE_ADDRESS"
  syncthing cli config devices add --device-id "$DEVICE_ID" --name "$DEVICE_NAME" --addresses "$DEVICE_ADDRESS"
done
4 Likes
17

aaaand several trial-and-error-bing-copilot hours later, auto share the default folder to all previously auto accepted devices (note the direction, from our introducer to the others, not accepting their offers - that is syncthing cli config devices "$DEVICE_ID" auto-accept-folders set true)

$ cat add-all-pending-folders.sh
#!/bin/bash

# Set your Syncthing API key and base URL
API_KEY="x"
BASE_URL="https://x:8384"
FOLDER_ID="default"  # Replace with your actual folder ID

# Get the list of pending folders
PENDING_FOLDERS=$(curl -s -k -X GET -H "X-API-Key: $API_KEY" "$BASE_URL/rest/cluster/pending/folders")

# Extract device IDs from the pending folders list
DEVICE_IDS=($(echo "$PENDING_FOLDERS" | jq -r '.[].offeredBy | keys[]'))

# Check if any device IDs were found
if [ ${#DEVICE_IDS[@]} -eq 0 ]; then
    exit 0
fi

# Iterate through each device ID and add it to the JSON payload
for DEVICE_ID in "${DEVICE_IDS[@]}"; do
        echo syncthing cli config folders "default" devices add --device-id="$DEVICE_ID"
        syncthing cli config folders "default" devices add --device-id="$DEVICE_ID"
done

and yes it’s slower than using the way the gui does it because it serializes adding, but it’s easier for me.

2 Likes