kruffin

It does seem that way, however, in none of the AdaBoxes I've gotten from them have I had to sign up for their cloud services. That's where you think they would push it hard, but it just hasn't happened and I'm glad for that. There are usually a few samples that make use, but you always have the option to roll your own code on it and use their base libraries for interfacing with the hardware. It will be a sad (and probably disastrous) day when they bind their code to require cloud services especially considering some micros don't have wifi.

Neat, there is a whole section on dungeon generation in there too!

Sobering to think of the true (hardware only) price of that postcard in full view of anyone handling it: $36k ($450 * 81).

But amazing to think how far technology has advanced.

Reading again, it does look like the installation is limited in some way if you choose to use public keys and your user doesn't have the privileges (without sudo) necessary for some of Cockpit's commands it tries to run.

Note that when a user is authenticated in this way [public key] the authentication happens without a password, as such the standard cockpit reauthorization mechanisms do not work. The user will only be able to obtain additional privileges if they do not require a password.

Why does it require that the server has password logins enabled? This seems contrary to every "secure your server" guide I've seen and opens your server up to the password guessing game. It seems like a cool product, but that's a huge non-starter.

    The target server will need to have password based authentication enabled in sshd. When this is setup for the first time, Cockpit will ensure that the user connected to primary server has the same password on the secondary server.