SSD Nodes Learn Hosting plans →
मार्गदर्शक Matt Connorद्वारे Matt Connor

फोनवरून Hermes agent पर्यंत पोहोचण्याचे 3 सुरक्षित मार्ग

Hermes agent VPS वर चालत असल्यास फोनवरून dashboard कसे वापरायचे ते शिका: private mesh, public HTTPS endpoint किंवा SSH निवडा आणि फोन हरवल्यास access revoke करा.

फोनवरून आपल्या Hermes agent पर्यंत पोहोचण्याचे तीन मार्ग

फोनवरून आपल्या Hermes agent पर्यंत पोहोचण्यासाठी त्याचे web dashboard वापरता. प्रत्यक्ष निर्णय हा dashboard च्या पुढे कोणती रचना आहे याचा असतो. पहिला पर्याय private mesh network आहे. या रचनेत dashboard फक्त Tailscale address वर listen करतो आणि कोणताही port internet कडे उघडा नसतो. दुसरा पर्याय reverse proxy मागे TLS (transport layer security) आणि login असलेला public endpoint आहे. येथे तो login आपल्या server वरील terminal चे संरक्षण करणारी एकमेव गोष्ट असते. तिसरा पर्याय terminal app मधून SSH (secure shell) वापरणे आहे. यासाठी सर्वात कमी setup लागतो आणि सर्वाधिक access मिळतो.

हा मार्गदर्शक आपल्या स्वतःच्या VPS वर Hermes agent चालवणे इथे संपतो तिथून पुढे सुरू होतो. Agent install केलेला आहे, तो command line वर प्रतिसाद देतो आणि आता तो आपल्या फोनवर उपलब्ध हवा आहे.

खालील commands v2026.8.3 tag वर आधारित आहेत. हा tag 3 August 2026 रोजी प्रकाशित झाला आणि release notes मध्ये v0.20.0 असा नमूद आहे. Hermes वारंवार releases प्रकाशित करतो. त्यामुळे main चे अनुसरण करण्याऐवजी machine ला एखाद्या tag वर स्थिर ठेवा. Installer commit स्वीकारतो:

curl -fsSL https://hermes-agent.nousresearch.com/install.sh | bash -s -- --commit 3c27eb6234bf
hermes --version

hermes --version प्रत्यक्षात काय install झाले आहे ते दाखवते. या पृष्ठावरील कोणत्याही flag वर विश्वास ठेवण्यापूर्वी त्याची tag शी तुलना करा.

रिपॉझिटरीमध्ये काय उपलब्ध आहे आणि काय उपलब्ध नाही

Hermes रिपॉझिटरीमध्ये iOS किंवा Android अॅप नाही. Native client म्हणजे hermes desktop (alias hermes gui). हे macOS, Windows आणि Linux साठी Electron अॅप्लिकेशन आहे. ते स्थानिक agent ऐवजी remote agent शी जोडता येते. Settings मधील Gateway अंतर्गत remote URL http://<server-address>:9119 वर सेट करा किंवा ते सुरू करण्यापूर्वी HERMES_DESKTOP_REMOTE_URL=http://<server-address>:9119 export करा. यामुळे दुसऱ्या laptop वरून काम करता येते. फोनसाठी मात्र याचा उपयोग होत नाही.

फोनवरून वापरायचे इंटरफेस म्हणजे hermes dashboard, म्हणजे browser interface. यात configuration, sessions, cron jobs, skills, logs आणि messaging platforms व्यवस्थापित करता येतात. यात terminal देखील समाविष्ट आहे. Server PTY (pseudo-terminal) मागे hermes --tui सुरू करतो आणि त्याचे output page मध्ये stream करतो. अरुंद स्क्रीनवर session switcher slide-over panel मध्ये रूपांतरित होतो. त्यामुळे फोनवरही layout योग्य प्रकारे कार्य करते.

By default dashboard 127.0.0.1:9119 वर listen करते आणि server वरच browser tab उघडते. Headless VPS (virtual private server) वर याचा उपयोग होत नाही. Browser न उघडता ते सुरू करा आणि socket तपासा:

hermes dashboard --no-open
ss -lntp | grep 9119

127.0.0.1:9119 वरील listener फक्त server वरून पोहोचता येतो. 0.0.0.0:9119 वरील listener मशीन जोडलेल्या प्रत्येक network वरून पोहोचता येतो. यात public network देखील समाविष्ट आहे. त्यामुळे server किती exposed आहे हे त्या एकाच ओळीवर ठरते. म्हणून अंदाज न बांधता ती ओळ तपासा.

पर्याय 1: Tailscale सहगीयगीय खासगी जाळे

याच्या विरोधात ठोस कारण नसल्यास हा पर्याय निवडा. Tailscale हे WireGuard वर आधारित mesh VPN (virtual private network) आहे. तुम्ही नोंदणी केलेल्या प्रत्येक device ला स्थिर address मिळतो आणि ते इतर devices शी थेट संवाद साधते. तुमचा phone त्याच mesh मध्ये सामील होतो. त्यामुळे dashboard साठी सार्वजनिक port ची गरजच राहत नाही.

Server वर:

curl -fsSL https://tailscale.com/install.sh | sh
sudo tailscale up
tailscale ip -4

Phone वर Tailscale app install करा आणि त्याच account ने sign in करा. Server वरील tailscale status नंतर phone चे नाव दाखवते. आता tailscale ip -4 ने दाखवलेल्या address वर dashboard bind करा:

hermes dashboard --host 100.101.102.103 --port 9119 --no-open

0.0.0.0 ऐवजी mesh address वर bind केल्याने listening socket फक्त Tailscale interface वर उपलब्ध राहतो. तुमच्या public IP address चे port scan केल्यावर 9119 वर काहीही आढळत नाही, कारण तेथे काहीही listening करत नाही. त्यामुळे तुमचे firewall हेच एकमेव संरक्षण राहात नाही. ss -lntp | grep 9119 ने पुन्हा याची खात्री करा.

Bind address authentication देखील ठरवतो. हा महत्त्वाचा भाग अनेकदा दुर्लक्षित होतो. 127.0.0.1 वर dashboard ला login नसतो. इतर कोणत्याही address वर auth gate अनिवार्य असतो. कोणताही provider configure केलेला नसल्यास server सुरू होण्यास नकार देतो. Project याला failing closed म्हणतो. पहिल्यांदा ते interactively चालवा. त्यावेळी तेथेच username आणि password सेट करण्याचा पर्याय मिळतो. ही माहिती ~/.hermes/config.yaml मधील dashboard.basic_auth म्हणून जतन केली जाते. त्याच provider चे configuration ~/.hermes/.env द्वारेही करता येते. Project च्या स्वतःच्या worked example मध्ये हीच पद्धत वापरली आहे:

HERMES_DASHBOARD_BASIC_AUTH_USERNAME=you
HERMES_DASHBOARD_BASIC_AUTH_PASSWORD_HASH=scrypt$16384$8$1$...
HERMES_DASHBOARD_BASIC_AUTH_SECRET=a-long-random-string

openssl rand -hex 32 ने तो secret generate करा आणि त्यानंतर तो बदलू नका. हा session cookie वर स्वाक्षरी करतो. त्यामुळे तो बदलल्यास प्रत्येक device मधून sign out केले जाते. याच file मध्ये तुमच्या model API keys देखील असतात. म्हणून chmod 600 ~/.hermes/.env वापरून ती private ठेवा.

त्यावर विश्वास ठेवण्यापूर्वी mesh वरील दुसऱ्या machine वरून gate तपासा:

curl -s http://100.101.102.103:9119/api/status | jq '.auth_required, .auth_providers'

true नंतर ["basic"] दिसत असल्यास gate सुरू आहे आणि password provider प्रतिसाद देत आहे. त्या provider विषयी project चे documentation स्पष्ट आहे: तो trusted network किंवा VPN साठी आहे. सार्वजनिक internet कडे उघडलेल्या dashboard साठी तो योग्य नाही. Mesh मध्ये तुमची परिस्थिती नेमकी अशीच आहे.

Tailnet मध्ये HTTPS वापरण्यासाठी port Tailscale कडे सोपवा:

sudo tailscale serve --bg localhost:9119
sudo tailscale serve status

Tailscale machine च्या MagicDNS name साठी जारी केलेल्या certificate ने TLS termination करते. त्यामुळे browser warning दाखवणे थांबवतो आणि session cookie ला त्याचा Secure flag मिळतो. प्रथम Tailscale admin console मधील DNS page वर MagicDNS आणि HTTPS Certificates enable करा. त्याच वेळी acknowledgement वाचा: तुमची machine names आणि tailnet DNS name सार्वजनिक certificate transparency ledger वर प्रकाशित केली जातात. हा ledger कोणीही वाचू शकतो.

याची खरी किंमत coordination server आहे. तुमच्या phone आणि VPS मधील traffic end-to-end encrypted असतो आणि Tailscale मधून जात नाही. मात्र कोणती devices mesh मध्ये असतील हे ठरवणारे account तुमच्या hardware वर राहत नाही. हे महत्त्वाचे असल्यास Headscale, self-hosted Tailscale control server वापरून control plane स्वतः चालवा आणि tailscale up --login-server https://headscale.example.com वापरून clients त्याकडे निर्देशित करा. Mesh वगळून peers manually configure करायचे असल्यास plain WireGuard आणि Tailscale यांची तुलना मध्ये त्यासाठी काय गमवावे लागते ते दिले आहे.

पर्याय 2: सार्वजनिक HTTPS endpoint आणि त्यातील धोका

कधीकधी mesh उपलब्ध नसते. कामाच्या फोनवर VPN client install करण्याची परवानगी नसू शकते. अशा वेळी dashboard reverse proxy मागे ठेवता येतो. Dashboard loopback वर ठेवा आणि certificate Caddy कडे सोपवा:

hermes.example.com {
  reverse_proxy 127.0.0.1:9119
}

Caddy certificate स्वतः मिळवतो आणि renew करतो. त्याचा reverse_proxy WebSocket upgrades कोणत्याही अतिरिक्त directives शिवाय पुढे पाठवतो. Dashboard मधील embedded terminal साठी हे आवश्यक आहे. nginx वर Upgrade आणि Connection headers स्वतः जोडावे लागतात. nginx वर Certbot वापरून Let's Encrypt certificate जारी करणे या प्रक्रियेतील TLS भाग स्पष्ट करते. Login callbacks योग्य host कडे निर्देशित होण्यासाठी Hermes ला त्याचे सार्वजनिक नाव द्या:

dashboard:
  public_url: "https://hermes.example.com"

आता धोका समजून घ्या. Auth gate विनंती ज्या address वरून आली त्यावर नाही, तर bind address वर आधारित असते. 127.0.0.1 वर bind केलेला dashboard proxy मागे असताना loopback पाहतो, login आवश्यक नाही असा निर्णय घेतो आणि proxy ज्याला प्रवेश देतो त्याला सेवा देतो. प्रत्यक्षात काय public केले आहे ते तपासा:

curl -s https://hermes.example.com/api/status | jq '.auth_required'

यातून false दिसत असेल, तर तुमच्या server वरील terminal पर्यंत पोहोचण्यासाठी internet वरून फक्त एक URL पुरेसा आहे. यासाठी कोणत्याही exploit ची आवश्यकता नाही आणि logs मध्ये कोणतीही त्रुटी नोंदवली जाणार नाही. यावर दोन उपाय आहेत आणि त्यांपैकी किमान एक लागू करणे आवश्यक आहे. एकतर proxy मध्ये authentication लागू करा. त्यासाठी forward auth द्वारे self-hosted single sign-on provider म्हणून Authentik पुढे ठेवा. किंवा dashboard चा स्वतःचा OIDC (OpenID Connect) provider configure करा:

HERMES_DASHBOARD_OIDC_ISSUER=https://auth.example.com/application/o/hermes/
HERMES_DASHBOARD_OIDC_CLIENT_ID=hermes-dashboard
HERMES_DASHBOARD_OIDC_SCOPES="openid profile email"

हे योग्यरीत्या केले तरी या पर्यायाची एक किमान सुरक्षा मर्यादा असते. सार्वजनिक login page वर कोणीही पोहोचू शकतो आणि त्यावर हल्ला करू शकतो. त्या login page मागे तुमच्या VPS वरील shell असते. त्यासाठी username आणि password ही मर्यादित सुरक्षा आहे. म्हणूनच public binds साठी docs OAuth किंवा OIDC वापरण्याचा आग्रह धरतात. Login वर rate limit लागू करा, proxy ports आणि SSH वगळता इतर सर्वांसाठी ufw बंद ठेवा, आणि अधूनमधून access log तपासा.

पर्याय 3: मोबाइल टर्मिनलवरून SSH आणि mosh

सर्वात कमी प्रयत्नांचा मार्ग म्हणजे फोनवर टर्मिनल अॅप स्थापित करणे, त्यात SSH key लोड करणे आणि agent चा स्वतःचा text interface वापरणे.

ssh you@vps.example.com
tmux new -A -s phone
hermes --tui

tmux new -A -s phone नावाच्या phone session शी जोडतो किंवा अशी session नसल्यास ती तयार करतो. त्यामुळे connection तुटले तरी agent चालू राहतो आणि पुढच्या वेळी तुम्ही त्याच ठिकाणी परत येता. हीच पद्धत फोनवरून Claude Code नियंत्रित करण्यासाठी वापरली जाते.

मोबाइल network वर साधा SSH वापरणे त्रासदायक असते. फोनचा address बदलला किंवा फोन sleep mode मध्ये गेला की connection तुटतो. Mosh ही समस्या सोडवतो. तो UDP (user datagram protocol) वर चालतो आणि byte stream ऐवजी terminal state sync करतो. त्यामुळे wifi वरून cellular network कडे जातानाही session सुरू राहते:

sudo apt install -y mosh
sudo ufw allow 60000:61000/udp

फोनवरून mosh you@vps.example.com चालवा. Mosh तुमच्या विद्यमान SSH login वर mosh-server सुरू करतो आणि त्यानंतर session UDP मधील 60000 ते 61000 या range वर हलवतो. म्हणून ही range खुली असणे आवश्यक आहे.

याची security cost सरळ आहे. SSH session म्हणजे shell, आणि shell म्हणजे त्या account ला करता येणारी प्रत्येक गोष्ट. अशा वेळी चोरीला गेलेला unlocked phone आणि तुमच्या files यांच्यामध्ये agent चे approval prompts हीच शेवटची सुरक्षा उरते. यासाठी स्वतंत्र non-root account वापरा, फक्त key authentication वापरा आणि तुम्ही जवळ बाळगत असलेल्या device वर key ठेवण्यापूर्वी VPS वरील SSH hardening करा.

मोबाइल नेटवर्कवर काय बिघडते

चार गोष्टी बिघडतात. आणि त्या configuration बदलून दूर करता येणाऱ्या bugs नाहीत.

तुम्ही पाहत नसताना dashboard तुम्हाला logout करते. हे किती लवकर घडते, हे login provider वर अवलंबून असते. Username आणि password provider default ने 12 तास टिकणारी sessions जारी करतो. हे session_ttl_seconds मधील dashboard.basic_auth द्वारे ठरवले जाते. Nous Portal OAuth provider 15 मिनिटांच्या TTL (time to live) असलेले access tokens जारी करतो. त्याच्या सध्याच्या API contract मध्ये refresh token नाही. Token ची मुदत संपल्यावर page ला 401 response दिसतो आणि ते /login वर परत नेते. 15 मिनिटांचा token असल्यास dashboard उघडा, phone वीस मिनिटांसाठी खिशात ठेवा आणि परत आल्यावर login screen दिसेल; तुम्ही टाइप करत असलेला मजकूरही गमावलेला असेल. काहीही बिघडलेले नाही. पुन्हा sign in करा.

Background tab मध्ये embedded terminal टिकत नाही. Server PTY मागे TUI (text user interface) सुरू करतो. Tab बंद झाल्यावर तो व्यवस्थित बंद केला जातो. पुन्हा उघडल्यावर नवीन TUI सुरू होते. Memory परत मिळवण्यासाठी mobile browsers background tabs काढून टाकतात. त्यामुळे दुसऱ्या app वर पुरेसा वेळ गेल्यास तो terminal बंद होतो. तुमचा chat history सुरक्षित असतो, कारण sessions server वर साठवलेल्या असतात आणि hermes sessions list अजूनही त्या दाखवतो. Terminal ला पुन्हा जोडता येत नाही. टिकणारी session हवी असल्यास SSH वर tmux वापरा.

Idle connections शांतपणे बंद होतात. NAT (network address translation) table मधील entries मोकळ्या करण्यासाठी mobile carriers idle TCP connections बंद करतात. Screen बंद झाल्यावर phone network सेवा जवळजवळ पूर्णपणे थांबवतो. काही काळ शांत असलेला WebSocket तुम्ही phone unlock करेपर्यंत बहुधा आधीच बंद झालेला असतो. Page तुम्ही त्याला touch केल्यानंतरच पुन्हा connect होतो. म्हणून phone वर SSH पेक्षा mosh अधिक चांगला वाटतो: गमावण्यासाठी त्याच्याकडे connectionच नसते.

कोणतीही notification push होत नाही. Dashboard किंवा SSH session यांपैकी कोणतीही गोष्ट तुमचा phone जागा करू शकत नाही. Device वर Hermes app नाही. त्यामुळे platform च्या push service पर्यंत पोहोचण्याचा मार्ग नाही. Agent चे दीर्घकाळ चालणारे काम पूर्ण होते आणि तुम्हाला ते पुढच्या वेळी पाहिल्यावर कळते.

Messaging gateway द्वारे notifications मिळतात

शेवटच्या समस्येसाठी gateway वापरा. Agent पर्यंत पोहोचण्याचा हा पूर्णपणे वेगळा मार्ग आहे. hermes gateway agent ला Telegram, Discord, Slack, WhatsApp, Signal आणि email यांसारख्या messaging platforms शी जोडते. त्यानंतर तुम्ही फोनवर आधीपासून push channel असलेल्या, background delivery हाताळणाऱ्या आणि network खंडित झाल्यावरही त्याची पुनर्प्राप्ती करणाऱ्या अॅपमध्ये agent शी संवाद साधता.

hermes gateway setup
hermes gateway install
hermes gateway status

hermes gateway install gateway ची systemd service म्हणून नोंदणी करते. त्यामुळे reboot नंतर ती पुन्हा सुरू होते. Installer मधील gateway stage ही पायरी तुमच्यासाठी करू शकतो. मात्र installer मधील कोणतीही प्रक्रिया hermes dashboard साठी unit तयार करत नाही. त्यामुळे restart नंतर dashboard आपोआप पुन्हा सुरू होणार नाही. तुम्ही ज्या components वर अवलंबून आहात त्यांच्यासाठी unit लिहा. VPS वर systemd services आणि timers लिहिणे येथे त्या file ची माहिती दिली आहे.

Conversation शिवाय scheduled job त्याच पद्धतीने result पाठवू शकते:

hermes send -t telegram -s "Backup report" -f /home/you/report.txt

येथे authorization चे default धोरण deny आहे. Allowlist सेट केलेली नसल्यास आणि GATEWAY_ALLOW_ALL_USERS unset असल्यास प्रत्येक user चा access नाकारला जातो. सुरुवातीसाठी हीच योग्य स्थिती आहे. तुम्हाला परवानगी द्यायची असलेली accounts ~/.hermes/.env मध्ये नमूद करा:

TELEGRAM_ALLOWED_USERS=123456789
GATEWAY_ALLOWED_USERS=123456789

किंवा numeric IDs paste करण्याऐवजी code-based pairing वापरा. Chat-style DM platforms साठी ही default पद्धत आहे. ~/.hermes/config.yaml मधील unauthorized_dm_behavior: pair वापरून ती स्पष्टपणे सेट करता येते. Agent ला message पाठवणाऱ्या अज्ञात account ला आठ अक्षरांचा code मिळतो. तुम्ही तो approve करेपर्यंत पुढे कोणतीही कृती होत नाही:

hermes pairing list
hermes pairing approve telegram ABC12DEF
hermes pairing revoke telegram 123456789

Codes एक तासानंतर expire होतात. User दर दहा मिनिटांनी एक code मागू शकतो. पाच अयशस्वी प्रयत्नांनंतर त्या account ला access करण्यापासून रोखले जाते.

हरवलेल्या फोनचा परिणाम मर्यादित करणे

तुमच्या agent पर्यंत पोहोचू शकणारा फोन तुमच्या server वर commands चालवू शकतो, आणि फोन हरवू शकतात. तो फोन हातात असलेल्या व्यक्तीला नेमके काय करता येईल हे आत्ताच ठरवा.

Approvals सुरू ठेवा. approvals.mode चे default मूल्य smart आहे. हे risk चे मूल्यमापन करण्यासाठी auxiliary model ला विचारते आणि फक्त low risk commands आपोआप approve करते. ते off वर सेट करणे म्हणजे सर्व काही --yolo सह चालवण्यासारखे आहे, आणि HERMES_YOLO_MODE=1 हे काम environment द्वारे करते. अशा स्थितीत agent शी संवाद साधणारा फोन सोबत बाळगू नका. तुम्ही झोपलेले असताना scheduled jobs स्वतः approve करू शकणार नाहीत, यासाठी approvals.cron_mode: deny सेट करा.

approvals:
  mode: smart
  cron_mode: deny

Agent ला नुकसान करण्यासाठी लहान कार्यक्षेत्र द्या. terminal.backend: docker commands अशा container मध्ये चालवते ज्यातून थोड्या निवडक क्षमतांव्यतिरिक्त सर्व Linux capabilities काढल्या जातात, no-new-privileges सेट केले जाते आणि processes ची संख्या मर्यादित केली जाते. त्यामुळे prompt ऐवजी container ही सीमा बनते. terminal.cwd working directory निश्चित करते. HERMES_WRITE_SAFE_ROOT मध्ये तुम्ही नमूद केलेल्या directories पुरते write_file आणि patch मर्यादित केले जातात. या directories च्या बाहेर write करण्याचा प्रयत्न block केला जातो आणि त्यावर approval देऊनही bypass करता येत नाही.

export HERMES_WRITE_SAFE_ROOT=/home/you/projects:/home/you/.hermes

Hermes आधीपासून ~/.ssh, ~/.aws, ~/.kube आणि /etc/sudoers येथे, तसेच ~/.hermes/.env सारख्या स्वतःच्या secret stores मध्ये writes block करते. Disk वरील इतर ठिकाणी असलेल्या project .env files read करण्यापासून block केल्या जातात, परंतु त्या writable राहतात. तुमच्या approval settings काहीही असल्या तरी destructive commands ची निश्चित hardline यादीही नाकारली जाते. याला किमान सुरक्षा-सीमा समजा; तुमची संपूर्ण योजना त्यावर आधारित ठेवू नका. Agent सामान्य user म्हणून चालवा; root म्हणून कधीही चालवू नका. Unattended अवस्थेत सुरू ठेवलेल्या कोणत्याही coding agent साठीही हेच तत्त्व लागू होते. अधिक तपशीलांसाठी VPS वर Claude Code सुरक्षितपणे चालवणे पहा.

त्यानंतर revocation steps आवश्यक होण्यापूर्वीच लिहून ठेवा. Tailscale admin console मधून device काढल्यास mesh access त्वरित बंद होतो. HERMES_DASHBOARD_BASIC_AUTH_SECRET बदलून restart केल्यास प्रत्येक device वरील प्रत्येक dashboard session invalid होतो, कारण ती value session cookie वर स्वाक्षरी करते. ~/.ssh/authorized_keys मधून फोनची public key delete केल्यास SSH access संपतो. hermes pairing revoke telegram <user-id> messaging account काढते. Provider keys वाचू शकणारी कोणतीही माहिती device वर होती, तर hermes auth logout <provider> वापरून ती keys revoke करा आणि upstream वर नवीन keys issue करा.

फक्त गृहीत न धरता परिणाम तपासा. या commands तुमच्या स्वतःच्या box वर चालवा. त्या काय output देतील हे तुमच्या setup वर अवलंबून असते:

tailscale status
hermes pairing list
hermes logs gateway -n 100
hermes status --deep

Logs ~/.hermes/logs/ अंतर्गत असतात. Incident नंतर ते वाचा. Incident झाला नसतानाही ते अधूनमधून वाचा.

FAQ

iOS किंवा Android साठी अधिकृत Hermes mobile app आहे का?

नाही. Hermes repository मध्ये command line interface, web dashboard आणि macOS, Windows आणि Linux साठी Electron desktop client दिले आहेत. iOS किंवा Android साठी first-party build उपलब्ध नाही. फोनवरून browser मध्ये web dashboard, SSH client किंवा hermes gateway द्वारे जोडलेले messaging platform वापरा. Third-party mobile clients उपलब्ध आहेत. मात्र ते तुमच्या agent ची credentials हाताळणारे third-party code असतात. त्यामुळे एखादा client install करण्यापूर्वी त्याचा source वाचा.

माझ्या फोनवरील Hermes dashboard मला logout का करते?

हे login provider वर अवलंबून असते. Nous Portal OAuth provider 15 minute TTL असलेले access tokens जारी करतो. त्याच्या सध्याच्या API contract मध्ये refresh token नाही. त्यामुळे token ची मुदत संपल्यावर page ला 401 मिळतो आणि ते /login वर जाते. फोनवरील browser background मध्ये ठेवल्यास हे स्पष्टपणे दिसते, कारण दुसऱ्या app मध्ये वीस मिनिटे राहणे पुरेसे असते. Username आणि password provider चे default session 12 hour चे असते आणि ते session_ttl_seconds द्वारे ठरवले जाते. या provider साठी HERMES_DASHBOARD_BASIC_AUTH_SECRET मध्ये स्थिर random value सेट करा. त्यामुळे restarts नंतर session signing key समान राहते आणि logout होण्याचे दुसरे कारण दूर होते.

Hermes dashboard सार्वजनिक इंटरनेटवर सुरक्षितपणे ठेवता येईल का?

तुम्ही स्वतः पडताळलेले authentication वापरत असल्यासच. Bind address वर आधारित auth gate सक्रिय होते. त्यामुळे 127.0.0.1 ला bind केलेले dashboard reverse proxy च्या मागे असल्यास इंटरनेटवरून login मागितला जात नाही. curl -s https://your-host/api/status | jq '.auth_required' चालवा आणि परत आलेले output वाचा. Username आणि password ऐवजी OAuth किंवा OIDC वापरा. Project च्या docs नुसार password provider trusted networks आणि VPNs साठी आहे. Private mesh वापरल्यास हा प्रश्नच उद्भवत नाही. म्हणून तो अधिक योग्य default आहे.

मला Tailscale account आवश्यक आहे का, की control plane स्वतः host करू शकतो?

तुम्ही ते स्वतः host करू शकता. Headscale हे Tailscale coordination server ची open implementation आहे. Official Tailscale clients tailscale up --login-server https://headscale.example.com वापरून त्याच्याशी connect होतात. त्यानंतर mesh मध्ये प्रवेशाची अनुमती असलेल्या devices ची list तुमच्या नियंत्रणात राहते. त्याची किंमत अशी आहे की आता तो server चालवणे आणि त्याचा backup घेणे तुमची जबाबदारी असते. तो down असताना तुम्ही device enrol किंवा re-authenticate करू शकत नाही.

Agent चे job पूर्ण झाल्यावर फोनवर notification कशी मिळवू?

Messaging gateway वापरा. Dashboard आणि SSH फोनला जागे करू शकत नाहीत, कारण push स्वीकारण्यासाठी device वर Hermes app नाही. hermes gateway setup वापरून agent ला Telegram, Signal, Discord किंवा अन्य supported platform शी connect करा. त्यानंतर त्या platform चे स्वतःचे app notification वितरित करेल. Cron job hermes send -t telegram -s "Job done" -f /path/to/report.txt वापरून एक message देखील पाठवू शकते. यासाठी model ला call करण्याची आवश्यकता नसते.