Experience as first time / new user

[bigbasti]

I was following along the X channel and decided now is the time to gibe OpenShip 0.6.1 a try.

I bought a server from Hetzner (8gb ram, 4 cores, 80gb ssd) and opened the docs to start installing.

Install went well, I started opencode without arguments and set up a domain and account.

I opened the Web UI and logged in successfully.

Unfortunately this is where the intuitive flow came to an end.

I was eager to setup the E-Mail service to use my server for emails, so I opened "Emails" in the side bar, entered my domain, an admin password and clicked Start Setup button. The UI briefly disappears and instantly comes back to the same form. No Error no hint on whats failing.

The Console Log shows this: POST /api/proxy/api/system/check 400 (Bad Request)

Something seems to be off... so I clicked around and found under Servers this message:

Reached server but the server refused authentication. The key or password stored for this server doesn't match what's authorised in ~/.ssh/authorized_keys on the host.

Could be related? I don't know.

I clicked on Edit Credentials in the error message and was taken to SSH connection options where I could enter the username which to use when connecting and could select password or ssh key as authentication method.
Since I disabled password login for my server, only SSH key works for authentication.

I created the key on the device at ~/.ssh/my_key and my_key.pub and configured those values including the key password. But it fails to connect every time. I ran out of ideas on what to try, since the errors the UI displays are not very helpful.

What do I need to do to make OpenShip connect to the same server it is running on?

[Hydralerne]

The deployment functionality is already done and working. Since the product is still in beta, we’ve been using this phase to make the email server production-ready before we reach LTS.

The email server will be working properly with today’s release. We had some issues after migrating it to a container-based setup for better security and isolation, but we’ve fixed them in the upcoming release.

Thanks for your patience, and please let us know if you run into any other issues

https://x.com/openshipio/status/2086121281531888042?s=20

[bigbasti]

Thanks for the quick response - but you did not address my actual problem.

I did not have problem with mail as I didn't even come so far to run it.

My problem was in making OpenShip connect to the actual server its currently running on.

What is OpenShip expecting here from me? The key is correct tested it by manually connecting to port 22 of the server

[climba03003]

What is OpenShip expecting here from me?

I came to same problem in 0.3.0.
Have you try to change the Key Path outside ~/.ssh?
The problems I face previously is that the ~/.ssh actually on denylist, which opneship deny to read.

[Hydralerne]

Hello guys, the fix is already in main, in 2 hours we will publish the new release, and all this fixed, sorry for that

[Hydralerne]

please try again now, all fixed, update to 0.6.5

[bigbasti]

Hi,

I tried but had no success.

OpenShip always tells me it either cant read the key (permission) or it cant find it.

I tried placing the key in:
/tmp/key
/root/key
/root/.ssh/key

all no success.

I wonder why does OpenShip need a key at all? Its already running on the server, and I need to connect to it again? Makes not sense to me.

How do you expect the key to be placed and where so OpenShot can successfully read it?

Thank

[Hydralerne]

Oh, I got you now.

When installing OpenShip, there’s a default option to give OpenShip access to the same server. This automatically connects the server, and you’ll find it listed as “This Server” in the servers list.

Let me make sure I understand two things:

1. You’re using the CLI directly on the VPS, right?
2. You can’t use the SSH key of the same server to connect to itself. We already have another option for this.

Actually, in this situation, the SSH path didn’t work because you set the path on the host, while the OpenShip API is running inside a container, so that path isn’t accessible from inside the container.

That’s why we added the direct upload option instead of using a file path.

[Hydralerne]

The option is:

“Let OpenShip operate this machine’s OS?”
→ Allow (recommended)

Additionally, Settings → Infrastructure → Deploy to this machine controls the same thing.

So, if you selected Disallow during installation, you can enable it again at any time from there. Once enabled, the same server will automatically appear in your Servers list.

[bigbasti]

This is my current configuration - looks like yours.

The server IS in the servers list but OpenShip says it cant connect:

When I click on the server I get this:

[Hydralerne]

Gonna investigate this.
Have you tried the desktop mode? You can install the desktop app and connect the server from there? can you tell if that works for you

[Hydralerne]

wait, you are not root ? maybe that is the issue : ( gonna confirm this

[bigbasti]

No I did not try Desktop mode since I'm on a Mac :)

[Hydralerne]

If you can, please download the Mac desktop version and see if it works. The desktop app uses an end-to-end connection, so it’s a different mechanism from the CLI.

https://openship.io/download

[Hydralerne]

Sorry for the runaround here — you were chasing something that was never fixable from the UI, and that's our bug, not your setup.

What was actually happening

"This Server" isn't a normal SSH server row. It's this box, reached from the API container through an internal channel (root@host.docker.internal:22) using a key the CLI provisions at install. The username/key fields on that row are display-only — nothing ever dials with them. So every key you placed at /tmp/key, /root/key, /root/.ssh/key, and every credential you entered, was ignored by design — while we kept showing you an "Edit credentials" button. That's the worst part of this report and it's entirely on us.

Three concrete bugs behind your screenshots:

1. The card named the wrong machine. It said "Reached <your-public-ip>:22", but the dial only ever touched host.docker.internal. We were printing the row's display address instead of the address we actually dialed.
2. The error text was the wrong advice. "Check the username, private key, passphrase" is remote-server guidance that doesn't apply to this channel at all.
3. Our host-channel health check never authenticates. It only tests whether something is listening on port 22. So a channel whose key isn't accepted reports as healthy, the install reports success, and you only discover it later through a misleading card. We fixed exactly this class of problem for network/firewall failures in Host control does not open the firewall for host.docker.internal SSH, and there is no reachability preflight #490 and never carried the lesson over to the auth side.

Why 0.6.5 probably didn't clear it for you

0.6.1 had a real bug where, under sudo, the key could be written into /home/<you>/.ssh/authorized_keys while the container was told to log in as root — the two halves disagreeing. That's fixed in 0.6.2+ (we now choose the account deliberately and authorize root's file via sudo), and openship update re-runs that provisioning, so it should have repaired it.

Since you're still seeing root@host.docker.internal rejected, the most likely remaining cause is that your host doesn't permit root SSH login at all — a perfectly sensible thing to have configured, and something we should have detected and told you, instead of blaming your credentials.

Could you run these two on the host?

sudo sshd -T | grep -i permitrootlogin
sudo grep -c openship /root/.ssh/authorized_keys

If the first says no, that's the answer — and we'll handle that case properly rather than reporting it as rejected credentials.

What we're changing

• Host-channel health actually authenticates instead of TCP-probing, and reports "key not authorized" and "root login refused" as distinct, named states.
• Install verifies the channel with a real dial and fails loudly with sshd's own reason, instead of declaring success because port 22 is open.
• The error names the address we actually dialed, with host-channel-specific wording and remedy.
• No "Edit credentials" button on This Server, because it does nothing there.

Thanks for pushing on this, and sorry it cost you this much time. Your question — "why does OpenShip need a key at all? It's already running on the server" — was exactly the right one. On a Docker install the API runs in a container, so it does need a route back out to the host; but you should never have had to reason about that, and it certainly should never have been presented to you as your credentials being wrong.

[bigbasti]

no, you can't connect as root to the machine, admin user has sudo preveliges:

admin@comp:~$ sudo sshd -T | grep -i permitrootlogin
permitrootlogin no
admin@comp:~$ sudo grep -c openship /root/.ssh/authorized_keys
1

Hope this help