Dataplicity OS local console and remote access #

Dataplicity Remote Shell is the normal production support path. The device opens its Dataplicity connection outbound, so customer networks do not need an inbound SSH rule or port forwarding.

Production defaults #

The production Dataplicity OS profile:

locks the admin account on every boot;
keeps sshd disabled;
enables UFW with a deny-inbound policy and no rule for TCP port 22;
allows outbound traffic for Dataplicity and normal product connectivity.

The OpenSSH packages may be present in the image, but package presence does not mean that the service or firewall rule is enabled.

If an image maintainer deliberately enables key-based SSH for a controlled non-production workflow, the persistent authorised-keys path is /var/lib/dataplicity/ssh/authorized_keys. Local console unlock does not create or activate that path.

Temporarily unlock the local console #

An authorised operator can request Enable local console for a Dataplicity OS device. Dataplicity displays a one-time password and sends only the derived password hash to the device.

The unlock permits admin to sign in at the attached HDMI console until the next reboot. Boot locks the account again. It does not enable SSH, open TCP port 22, or change UFW.

Treat the displayed password as short-lived support material. Do not copy it into a product image, script, ticket, or documentation.

Staging debug profile versus production-profile releases #

Behaviour	Production-profile release (staging or prod)	Staging debug profile
`/etc/dataplicity/build-channel`	`production`	`debug`
`admin` at boot	Locked	Password login enabled; console-lock service masked
`root` password	No empty-root `debug-tweaks`	Password `dataplicity`
`sshd`	Disabled	Socket enabled
UFW TCP 22	No allow rule	Allow rule present
Extra packages	Secure default set	Diagnostics such as `tcpdump`, `lsof`, and `strace`
Allowed release target	Staging and prod	Staging only; blocked for prod

The staging debug profile is for controlled diagnostics only. Do not make production access depend on it. Qualify Remote Shell and the temporary local-console workflow as the recovery paths for customer units.

Lab builds from the public kas configuration may still enable bring-up conveniences such as debug-tweaks. Those builds are not customer releases.

Offline first boot has no web wizard #

Dataplicity OS does not expose a browser-based offline setup or recovery wizard. The merged image brings up wired networking with DHCP, then the first-boot service reads factory provisioning files and retries provisioning while connectivity becomes available. If provisioning remains offline, it retains those credentials for the next boot attempt rather than opening a local web screen.

Treat device-console output and service logs as operational evidence. Do not document or mock an offline wizard screen that the shipped image does not provide.

Verify a production unit #

Check that Remote Shell opens, then reboot and confirm:

local admin login is locked again;
the SSH service remains disabled;
UFW denies inbound traffic and has no port 22 allow rule;
the device reconnects to Dataplicity without inbound network changes.