Set SSH tunnel as opt-in if you plan to enable dashboard user/password/OAuth

[Geotig]

✅ Have you read and understood the above guidelines?

yes

🔎 Did you run the script with verbose mode enabled?

Yes, verbose mode was enabled and the output is included below

📜 What is the name of the script you are using?

HermesAgent

📂 What was the exact command used to execute the script?

bash -c "$(curl -fsSL https://raw.githubusercontent.com/community-scripts/ProxmoxVE/main/ct/hermesagent.sh)"

⚙️ What settings are you using?

• Default Settings
• Advanced Settings

🖥️ Which Linux distribution are you using?

Debian 12

🧱 Is this Proxmox host running arm64?

No

📈 Which Proxmox version are you on?

pve-manager/8.4.19/a68fb383814bb1e6 (running kernel: 6.8.12-16-pve)

📝 Provide a clear and concise description of the issue.

For security reasons in May 2026, a SSH tunnel needs to be used to access the dashboard in the current state of the script. If using the desktop app, you need to use the tunnel too to connect to your backend in Proxmox.

As of June 2026 the documentation of Hermes Agent allows to set up a user/password login for secure networks or even OAuth if your infrastructure supports it: https://hermes-agent.nousresearch.com/docs/user-guide/features/web-dashboard#usernamepassword-provider-no-oauth-idp

It is not enforced by the install to create a user/password, but the capability is there, so the SSH tunnel seems redundant if you plan to set it up.

🔄 Steps to reproduce the issue.

Install Hermes Agent
Access the dashboard without a SSH tunnel

❌ Paste the full error output (if available).

No error output

🖼️ Additional context (optional).

https://hermes-agent.nousresearch.com/docs/user-guide/features/web-dashboard#usernamepassword-provider-no-oauth-idp

Issue with the discussion: community-scripts/ProxmoxVED#1831

[MickLesk]

This is maybe an Task, Not really an issue, when i read this?

@steveonjava you are the Maintainer of this tool. What do you say?

[steveonjava]

Thanks for filing this issue, @Geotig, and glad to see they added a username/password option to simplify access.

The new username/password gate is good, but by itself it doesn't provide transport security. If you expose the dashboard directly on the LAN with --host 0.0.0.0, Hermes serves it over plain HTTP, so the credentials and session traffic can still be intercepted by another machine on the network. You can address that by putting the dashboard behind a TLS-terminating reverse proxy or VPN, but that is additional infrastructure beyond simply enabling username/password access.

If you understand the risks, it is fairly easy for you to enable username/password support yourself. Just:

# Configure Hermes' built-in username/password provider
su - hermes -c 'hermes config set dashboard.basic_auth.username admin'
su - hermes -c 'hermes config set dashboard.basic_auth.password "CHANGE-ME"'

# Expose the dashboard to the LAN
sed -i 's/--host 127.0.0.1/--host 0.0.0.0/' \
  /etc/systemd/system/hermes-dashboard.service

systemctl daemon-reload
systemctl restart hermes-dashboard

Again, I would only recommend this on a network where you are comfortable sending the dashboard credentials and session traffic over plain HTTP. For anything beyond a trusted LAN, keep the SSH tunnel or put Hermes behind a VPN or properly configured HTTPS reverse proxy.

[Geotig]

Yes, I agree that the username/password is not enough, and I like that the documentation explains that is only for secure networks.

Thanks for the tip! I have already disabled the SSH tunnel requirement but filled the issue anyway. I would like to have this as an option during the install, but I understand if that is too risky, and there are other ways of installing Hermes on your infrastructure if you want, so there are options.

Thanks @steveonjava for the work on this script by the way!