Vendor support access
One switch under Services, Vendor support access, opens a path: the box dials out to a relay and holds a reverse tunnel there while the switch is on. Off closes it within seconds, and nothing can reopen it from outside. It ships off.
What the switch grants
The path, never the credential. The tunnel carries the box's SSH port to the relay, and SSH is key-only: whoever connects still needs a key the box already trusts. On a Machine bought with pipeOS the vendor's key is baked in; on a box you built, nobody has a key until you add one, and the switch alone lets nobody in. The relay sees only encrypted traffic.
Turning it on
| 1. the switch | the box generates its tunnel key the first time; the Services view shows the public key, the relay and the port |
| 2. waiting for a port | until the relay has your key, the card reads waiting for a port. Send the public key to your vendor by any channel |
| 3. pinned | the vendor adds the key on the relay, pinned to one port so one box cannot stand in for another; the box connects within its thirty-second retry and the pill reads tunnel up |
| 4. off | the tunnel dies within seconds and cannot reconnect |
The tunnel key is in the sealed vault, never shared to cluster members, gone with pipeos unclaim.
The relay
One small host that accepts the tunnel user for reverse forwarding only, no shell, no local forwards. The image ships configured for the vendor's relay, [email protected], in /etc/pipeos/support.conf; support access is still off until you turn it on, and a box never switched on has never spoken to it. On your own image, point that file at your own relay, or blank it and the service refuses to start: build your own.
Revocation
Yours: the switch. The vendor's: the key is removed from the relay, and the tunnel has nowhere to land. Either side alone closes the path.