Jinsi ya kutumia Gemini CLI kwenye VPS

Unachojenga

Gemini CLI inayofanya kazi muda wote kwenye seva yako, inayopatikana kupitia SSH, inayotekeleza kazi ndefu za agent ambazo zinaendelea hata baada ya kufunga laptop. Ufungaji unahusisha amri tatu tu. Changamoto ni mambo yote yanayohitaji desktop: CLI ya Google inahitaji kufungua kivinjari (browser) ili kukuingiza kwenye akaunti, lakini seva yako haina kivinjari. Kwa hivyo, mwongozo huu unajikita kwenye njia ya headless — Node ya sasa ambayo distro yako haitoi, npm install ya kiwango cha juu (global) isiyohitaji root, uthibitisho wa browserless kwa kutumia API key ambayo utaihifadhi mbali na historia ya shell yako, na tmux ili kikao cha SSH kikikatika, kazi inayojiendesha isisimame.

Gemini CLI ni programu ya Node (@google/gemini-cli) ya chanzo wazi (Apache-2.0) inayozungumza na mifano ya Gemini ya Google. Inaweza kusoma na kuandika faili, kutekeleza amri za shell, na kuendesha zana kwenye directory ya kazi. Kwenye VPS, ni agent mdogo unaoweza kuuacha ukiendelea kufanya kazi — ndiyo maana akaunti inayotumika, na siri (credentials) zilizopo kwenye mashine, ni muhimu zaidi kuliko mipangilio yoyote hapa.

Mahitaji ya awali na changamoto zinazojulikana

• Ubuntu 24.04 KVM VPS mpya yenye root au sudo. Mpango wowote wa KVM unafaa; CLI ni nyepesi, inatumia MB few za RAM ikiwa imetulia.
• Node.js 20 au zaidi. Hii ndiyo mipaka ya chini ya toleo; kifurushi cha distro ni chini ya toleo hili — angalia sehemu inayofuata.
• HTTPS ya kutoa (port 443) kwenda Google's APIs. Hakuna port za kuingia zinazohitajika; hii ni client, si server, hivyo huna haja ya kufungua firewall.
• Njia ya uthibitisho (authentication) isiyohitaji kivinjari (browser) kwenye server: iwe Gemini API key kutoka Google AI Studio, au SSH tunnel kurudi kwenye kivinjari kwenye mashine yako. Njia ya API-key ndiyo inayofaa kwa script na utendaji usio na usimamizi.
• Docker au Podman, ikiwa tu unataka --sandbox isolation. Ni hiari, itafafanuliwa mwishoni.

Changamoto inayowakwama kila mtu: mtiririko wa login wa gemini wakati wa kuanza umeundwa kwa ajili ya desktop. Inajaribu kufungua kivinjari na, kwenye headless box, itashindwa au itakupa link isiyofanya kazi. Amua njia ya uthibitisho kabla ya kuanza.

Node: kifurushi cha distro ni cha zamani mno

Ubuntu 24.04 inakuja na Node 18.19.1 kwenye viambata vyake (repositories), ikiwa na npm 9.2.0. Gemini CLI ya package.json inatangaza engines: { node: ">=20" }, na npm hauzuia kutofautiana kwa kimaandishi kwa kima kawaida — inasakinisha na kutoa onyo linaloeleza pengo hilo:

npm WARN EBADENGINE Unsupported engine {
npm WARN EBADENGINE   package: '@google/gemini-cli@0.50.0',
npm WARN EBADENGINE   required: { node: '>=20' },
npm WARN EBADENGINE   current: { node: 'v18.19.1', npm: '9.2.0' }
npm WARN EBADENGINE }

Ukipuuza onyo hilo, CLI itafanya kazi kwenye runtime isiyoungwa mkono, ambapo itafanya kazi vibaya au itafika mwisho (crash) mara tu itakapofikia API ya Node 20+ inayotarajiwa kuwepo. Node 18 pia ilifikia mwisho wa maisha (end-of-life) Aprili 2025, hivyo haina faida yoyote. Sakinisha LTS ya sasa kabla ya kusakinisha CLI. Njia mbili safi ni NodeSource (repo ya apt iliyosainiwa kwa mfumo mzima) au nvm (msimamizi wa toleo kwa kila mtumiaji). Chagua moja.

NodeSource, ikiwa unataka Node iweze kutumiwa na kila mtumiaji kwenye mashine:

sudo apt-get update
sudo apt-get install -y ca-certificates curl gnupg
curl -fsSL https://deb.nodesource.com/setup_24.x | sudo -E bash -
sudo apt-get install -y nodejs
node --version

node --version lazima itoe v20.x au zaidi — v24.x ndiyo LTS inayotumika sasa. Angalia ukurasa wa NodeSource kwa script ya usanidi ya sasa; setup_24.x kwenye URL ndiyo sehemu ya kubadilisha wakati LTS mpya itakapotoka.

nvm, ikiwa ungependa kuweka Node ndani ya home directory ya mtumiaji mmoja na usitumie sudo:

curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.40.1/install.sh | bash
source ~/.bashrc
nvm install --lts
node --version

v0.40.1 kwenye URL hiyo ilikuwa ya sasa wakati hii ikiandikwa; angalia README ya nvm kwa toleo la hivi karibuni na ubadilishe toleo hilo kabla ya kuifanya. nvm ina faida kubwa kwa kazi hii: inasakinisha Node na vifurushi vyake vya global chini ya ~/.nvm, hivyo tatizo la ruhusa la global-install katika sehemu inayofuata halitatokea. Ukichagua njia ya nvm, unaweza kuruka hatua ya npm-prefix.

Sakinisha CLI bila sudo npm -g

Amri inayovutia ni sudo npm install -g @google/gemini-cli. Usitumie. Prefix ya global inayomilikiwa na root husababisha makosa ya ruhusa (permission errors) wakati wa kusakinisha vitu vingine baadaye. Pia huacha faili zinazomilikiwa na root kwenye npm cache yako, jambo ambalo litasababisha matatizo miezi kadhaa ijayo. Ukitekeleza npm install -g ya kawaida (bila sudo) dhidi ya Node ya mfumo, utapata tatizo lingine:

npm error code EACCES
npm error syscall mkdir
npm error path /usr/lib/node_modules/@google
npm error errno -13
npm error Error: EACCES: permission denied, mkdir '/usr/lib/node_modules/@google'

Hiyo ni npm ikijaribu kuandika ndani ya /usr/lib, ambapo mtumiaji wako hana ruhusa. Suluhisho si kutumia sudo — ni kuelekeza global prefix ya npm kwenye directory yako ya home ili usakinishaji wa global uwekwe mahali unapomiliki:

mkdir -p ~/.npm-global
npm config set prefix ~/.npm-global
echo 'export PATH="$HOME/.npm-global/bin:$PATH"' >> ~/.bashrc
source ~/.bashrc
npm install -g @google/gemini-cli
gemini --version

~/.bashrc, si ~/.profile, ni kwa makusudi: tmux — ambayo utaitumia ndani ya CLI katika sehemu mbili zijazo — huanzisha non-login shell inayosoma ~/.bashrc na kuruka ~/.profile, hivyo mstari wa PATH kwenye faili isiyo sahihi huacha gemini ikiwa haionekani mahali unapohitaji. gemini --version kuchapisha namba ya toleo ndiyo jaribio kamili. Kama badala yake unapata gemini: command not found, export yako ya PATH haikukubali — angalia aina za makosa. Kwenye nvm, ruka mistari ya prefix kabisa: tayari inasakinisha vitu vya global chini ya home yako.

Kama ulitekeleza sudo npm hapo awali na sasa unaona Your cache folder contains root-owned files, irekebishe mara moja kwa kutumia sudo chown -R $(id -u):$(id -g) ~/.npm.

Tatizo la uthibitisho (auth) bila kioo, na jinsi ya kulitatua

Unapokimbiza gemini kwa mara ya kwanza, itakuuliza uingie kwa kutumia akaunti yako ya Google. Kwenye kompyuta ya kawaida, itafungua tab kwenye kivinjari (browser). Kwenye VPS isiyo na kioo (headless), hakuna kivinjari, hivyo mchakato utatoa URL ya localhost inayopaswa kufunguliwa, au utafeli kabisa na ujumbe kama huu:

Failed to open browser. Please visit the following URL to authorize:
https://accounts.google.com/o/oauth2/v2/auth?...&redirect_uri=http://localhost:PORT

Changamoto ni redirect_uri=http://localhost:PORT. Hata ukifungua URL hiyo kwenye laptop yako na kuidhinisha, Google itakupeleka kwenye http://localhost:PORT — localhost kwenye seva, bandari (port) ambayo laptop yako haiwezi kuifikia. Uingiaji hautakamilika.

Kuna njia mbili sahihi za kutatua hili.

Njia ya kwanza ni kutumia API key, ambayo ndiyo njia bora kwa seva. Tengeneza key kwenye Google AI Studio (aistudio.google.com) na uipe CLI kama variable ya mazingira (environment variable); CLI itasoma GEMINI_API_KEY na kuruka mchakato wa kivinjari kabisa. Sasa, kuhusu suala la "kuepuka kuacha siri kwenye historia au mafaili yanayoweza kusomwa na kila mtu". Usiiandike export GEMINI_API_KEY=AIza... kwenye prompt — itaingia kwenye ~/.bash_history ikiwa wazi (cleartext), na usiiweke kwenye faili ambalo watu wengine wanaweza kusoma. Iandike kwenye faili yenye mode-600 ambayo shell inaisoma wakati wa kuanza:

umask 077
printf 'export GEMINI_API_KEY=%s\n' 'AIzaSyYOUR_KEY_HERE' > ~/.gemini_env
chmod 600 ~/.gemini_env
echo '[ -f ~/.gemini_env ] && . ~/.gemini_env' >> ~/.bashrc
source ~/.bashrc

chmod 600 inamaanisha kuwa mtumiaji wako pekee ndiye anayeweza kusoma faili hiyo. Hakikisha key imefika kwenye mazingira kwa kutumia printenv GEMINI_API_KEY; ikiwa haitoi chochote, CLI itarudi kwenye mchakato wa kivinjari na kufeli. Pia inasoma faili ya .env katika ~/.gemini/ ikiwa unapendelea mpangilio huo — sheria ni ile ile, hivyo chmod 600 ~/.gemini/.env.

Njia ya pili inatumia uthibitisho wa akaunti ya Google binafsi (na kiwango chake cha bure) kwa kutumia njia ya kutengeneza njia (tunnelling) ya OAuth callback kurudi kwenye laptop yako. Changamoto ni kwamba seva ya loopback ya CLI hutumia port ya random kila wakati inapokimbishwa, hivyo hakuna port thabiti ya kuifungulia isipokuwa uifunge kwanza kwa kutumia variable ya mazingira ya OAUTH_CALLBACK_PORT, kisha ufungue port hiyo hiyo:

# from your laptop, forward the callback port into the SSH session:
ssh -L 8085:localhost:8085 user@your-server
# then, on the server, pin the callback to the same port and start the CLI:
export OAUTH_CALLBACK_PORT=8085
gemini

CLI haiwezi kufungua kivinjari, hivyo itatoa URL ya uthibitisho; ifungue kwenye kivinjari cha laptop yako, idhinishe, na Google itakapoelekeza kwenye http://localhost:8085/..., SSH forwarding itapeleka data hiyo kwenye seva ya loopback kwenye VPS na uthibitisho utakamilika. Ukiiacha port bila kufungwa, itatua kwenye port mpya ya random kila wakati, ambayo hakuna ssh -L iliyowekwa mapema inayoweza kuipata. Inafanya kazi, lakini inahitaji upo kwenye kivinjari, hivyo haifai kwa script. Kwa kitu chochote unachokiacha kikikimbia, tumia API key.

Kwa Vertex AI au mradi wa Google Cloud badala ya AI Studio, weka GOOGLE_API_KEY pamoja na GOOGLE_GENAI_USE_VERTEXAI=true, au GOOGLE_CLOUD_PROJECT kwa leseni ya Code Assist — sheria ya variable ya mazingira ni ile ile, na faili ya mode-600 pia.

Itumie ndani ya tmux ili session ya SSH ikikatika isiuze kazi

Process ya gemini unayoianzisha moja kwa moja kutoka kwenye SSH shell ni mtoto wa shell hiyo. Ukipoteza muunganisho — kwa mfano laptop kufungwa, Wi-Fi kukatika, au idle timeout — sshd huondoa pseudo-terminal, shell inapata SIGHUP, na kisha inafunga CLI. Kazi ambayo inaendelea kwa dakika 10 wakati unahariri faili itakufa, na ukirudi kwenye muunganisho, hakutakuwa na process ya kuirejesha.

tmux inatatua hili kwa kumiliki shell badala ya sshd kuimiliki. Huu ni mfumo ule ule kama kuendesha AI coding agent kwenye remote VPS ndani ya tmux, na hufanya kazi vilevile hapa:

sudo apt install -y tmux
tmux new -A -s gemini
# inside the session:
gemini
# detach with Ctrl-b then d — the task keeps running
# reconnect later from any machine:
tmux attach -t gemini

tmux new -A -s gemini huunganisha kwenye session inayoitwa gemini ikiwa ipo, na kuitengeneza ikiwa haipo, hivyo ni amri moja ya kuendesha baada ya kila login. Shell iliyo ndani ni mali ya tmux server iliyo detached, siyo mali ya SSH session yako, hivyo kuacha muunganisho kunaacha CLI ikiwa inafanya kazi. Unganisha tena, attach, na utarudi kwenye scrollback ile ile.

Kwa kazi zisizo za kutoingilika (non-interactive) na za scripted, Gemini CLI ina hali ya headless: gemini -p "summarise the failing tests in this repo" huchapisha jibu na kutoka, na --output-format json hutoa matokeo yanayoweza kusomwa na mashine ili kupitisha (pipe) kwingine. Hali ya headless ikiwa na API key ndiyo unayohitaji ndani ya tmux session inayorun kazi ndefu ya batch, au inayozinduliwa kutoka kwenye cron entry — kwa angalau kizuizi kimoja: cron job haichukui faili zako za login, hivyo toa kwenye mstari wa crontab GEMINI_API_KEY yake (au uweke amri iweze kusoma ~/.gemini_env), vinginevyo CLI itarudi kwenye mtiririko wa kivinjari (browser flow) na itashindwa.

Sandboxing na ruhusa kwenye mashine inayofanya kazi za uzalishaji (production)

Agent mwenye ufikiaji wa shell ni shell. Gemini CLI inaweza kuendesha amri, na kwa kawaida huuliza kabla ya kila amri yenye hatari — lakini watumiaji hutumia --yolo (kuidhinisha kila mwito wa zana kiotomatiki), na kisha inaweza kufuta faili, kutuma kwenye git, au kuwasiliana na huduma za ndani kwa mamlaka kamili ya mtumiaji anayefanya kazi kama yeye. Kwenye mashine inayofanya kazi za uzalishaji, hii ni hatari kubwa ya uharibifu, si nadharia tu.

Njia tatu za udhibiti, kwa mpangilio wa thamani yake:

• Iendeshe kama mtumiaji maalum asiye na mamlaka (unprivileged user). Usitumie root, wala mwanachama wa sudo. Unda mtumiaji wa agent mwenye nyumbani (home directory) yake, install Node na CLI hapo, na maelekezo yoyote yaliyosomwa vibaya yatabaki ndani ya akaunti hiyo pekee. Hii ndiyo hatua muhimu zaidi.
• Weka siri za uzalishaji (production credentials) nje ya mashine hiyo. Usiweke ~/.aws/credentials za uzalishaji, usinakili .env kutoka kwenye uzalishaji, na usitoe nywila ya database yenye uwezo wa kuandika kwenye kitu chochote muhimu. Mpe siri za staging au za kusoma tu (read-only).
• Tumia sandbox iliyojengwa ndani. Ukiwa na Docker au Podman imewekwa, gemini --sandbox (au GEMINI_SANDBOX=docker) huendesha mwito wa zana za agent ndani ya container iliyotenganishwa na mfumo wa faili na mtandao wa host. Hii si mbadala wa kutumia mtumiaji asiye na mamlaka, lakini ni tabaka la pili imara wakati VPS hiyo hiyo inafanya kazi halisi.

Ikiwa unaendesha Gemini CLI kando na zana nyingine zinazojihosti — kwa mfano MCP server inayotoa zana kwa agent kwenye VPS hiyo hiyo — chukulia kila uwezo unaoonzwa kama eneo zaidi ambalo agent anaweza kufikia, na uweke mipaka ya token anazopewa ili zifanye kazi moja tu.

Quota, gharama, na njia ya uthibitisho uliyochagua

Njia ya uthibitisho huamua jinsi unavyolipwa. Akaunti ya kibinafsi ya Google (njia ya OAuth) hutumia kiwango cha bure cha Gemini Code Assist, chenye mipaka halisi ya dakika na siku; ukivuka mipaka hiyo, maombi yataonyesha kosa la rate-limit hadi muda upojirekebishe. API key kutoka AI Studio inaweza kuwa ya kiwango cha bure au ya kulipia kulingana na mradi — key ya kulipia huongeza mipaka na kutoza gharama kwa kila token. Uthibitisho wa Vertex na Cloud-project hutoza kupitia Google Cloud.

Maelezo mawili ya kiufundi. Agent isiyo na usimamizi inayojiendesha kwenye loop inaweza kutumia quota haraka, hivyo iangalie mara chache za kwanza kabla ya kuiweka kwenye cron job. Na ikiwa sababu ya kutumia modeli upande wa seva ni faragha au utendaji usio na ukomo badala ya modeli za Google, hiyo ni zana tofauti — kujihostia open LLM kwa kutumia Ollama kwenye VPS huweka uzani (weights) na maelekezo (prompts) kwenye seva yako mwenyewe, kwa gharama ya kuendesha modeli ndogo zaidi kuliko Gemini.

Kuweka katika hali ya kisasa

Gemini CLI hutoa matoleo mapya mara kwa mara. Kwa sababu umeisakinisha kwenye prefix inayomilikiwa na mtumiaji, updates hazihitaji sudo:

npm install -g @google/gemini-cli@latest
gemini --version

Kuna njia za utoaji (release channels): @latest ni stable, @preview ni preview ya kila wiki, @nightly ni bleeding edge — tumia @latest kwa kitu chochote unachokitegemea. Kwenye nvm, vifurushi vya global vinaishi chini ya toleo la Node linalotumika, kwa hivyo baada ya nvm use kubadilisha Node, unaweza kuhitaji kusakinisha CLI upya. Soma maelezo ya utoaji (release notes) badala ya kufuatilia kila patch.

Njia za kushindwa, pamoja na maandishi halisi

npm WARN EBADENGINE Unsupported engine ... required: { node: '>=20' }, kisha CLI inafeli wakati wa utendaji. Node ni ya zamani sana — toleo la distro ni 18.19.1, ambalo limevuka muda wa msaada. Sakinisha Node 20+ kutoka NodeSource au nvm, thibitisha kwa node --version, na ikiwa una Node nyingi zilizosakinishwa, hakikisha which node inaashiria toleo jipya na si /usr/bin/node.

npm error code EACCES / permission denied, mkdir '/usr/lib/node_modules/...'. Usakinishaji wa jumla (global install) kwenye prefix inayomilikiwa na root. Usitumie sudo — weka npm config set prefix ~/.npm-global, weka ~/.npm-global/bin kwenye PATH, na usakinisha tena kama mtumiaji wako wa kawaida. Ikiwa sudo npm ya awali iliacha faili za cache zinazomilikiwa na root (Your cache folder contains root-owned files), run sudo chown -R $(id -u):$(id -g) ~/.npm.

Failed to open browser, kuingia (login) kunakokwama, au redirect_uri=http://localhost:PORT ambayo huwezi kuifikia. Mtiririko wa OAuth unahitaji kivinjari ambacho seva haina, na localhost callback yake inaashiria seva, si laptop yako. Tumia njia ya API-key (GEMINI_API_KEY), au pin OAUTH_CALLBACK_PORT, iweke mbele kupitia SSH kwa ssh -L, na ufungue URL hiyo ndani ya mashine yako.

Mchakato ulipotea wakati SSH ilipoisha. Ulirun gemini moja kwa moja kutoka kwenye SSH shell, hivyo ulikuwa mtoto wa shell hiyo na ulikufa pamoja na pty wakati wa kuunganishwa. Hakuna cha kuokoa. Anza kila session kwa kutumia tmux new -A -s gemini na urun CLI ndani yake.

Uthibitishaji (Auth) bado unashindwa baada ya kuweka key — CLI inarudi kwenye chaguo la auth, au ombi linatoa API key not valid pamoja na HTTP 400. Key haipo kwenye mazingira (environment) ambayo CLI inaona. Thibitisha kwa printenv GEMINI_API_KEY; ikiwa ni tupu, ~/.gemini_env yako haijawahi kusomwa — hakikisha mstari upo kwenye ~/.bashrc, ambayo shells za interactive (ikiwemo tmux) husoma lakini cron na shells nyingine zisizo za interactive hazisomi. Nafasi (space) au alama ya nukuu ndani ya thamani ya key pia husababisha API key not valid.

429 / RESOURCE_EXHAUSTED / ujumbe wa kikomo cha matumizi (rate-limit). Umefika kwenye kiasi (quota) cha kiwango chochote ambacho auth yako inatumia. Subiri hadi muda upotee, punguza kasi ya agent, au hamia kwenye API key ya kulipia. Agent iliyokwama kwenye mzunguko wa kujaribu tena (retry loop) itaendelea kukutana na hali hii — iache na uangalie inachofanya.

FAQ

Jeaniweje kuingiza Gemini CLI kwenye seva isiyo na kioo (headless server)?

Tumia API key badala ya kuingia kwa kivinjari. Tengeneza key kwenye Google AI Studio, iweke kwenye faili ya mode-600 ambayo shell yako inaisoma (export GEMINI_API_KEY=...), na CLI itapita hatua ya OAuth ya kivinjari kabisa. Ikiwa unataka kiwango cha bure cha akaunti ya kibinafsi, funga port ya loopback kwa OAUTH_CALLBACK_PORT=8085, iweke (forward) kwenye laptop yako kwa ssh -L 8085:localhost:8085 user@server, na ufungue URL iliyoonyeshwa ndani ya kivinjari — lakini njia hii inahitaji uwepo wako kwenye kivinjari, hivyo haifai kwa skripti.

Kwa nini npm global install inahitaji sudo, na jinsi ya kuepuka hali hiyo?

Kwa sababu prefix ya kiwango cha npm ni /usr/lib/node_modules, ambayo mtumiaji wako hawezi kuandika kwenye hiyo, hivyo npm install -g ya kawaida itashindwa na EACCES. Suluhisho lisilo sahihi ni sudo npm -g, ambalo huacha faili zenye umiliki wa root ambazo huharibu usakinishaji wa baadaye. Suluhisho sahihi ni kuelekeza prefix kwenye nyumbani kwako (npm config set prefix ~/.npm-global) na kuongeza bin yake kwenye PATH, au utumie nvm, ambayo husakinisha vifurushi vya global chini ya nyumbani kwako kiotomatiki.

Je, nifanye nini ili Gemini CLI iendelee kufanya kazi baada ya mimi kuunganishwa (disconnect)?

Irun ndani ya tmux. Mchakato (process) ulioanzishwa kutoka kwenye shell ya SSH hufa wakati muunganisho unapokatika kwa sababu ni mtoto wa shell hiyo; tmux huendesha shell chini ya seva iliyotenganishwa (detached server) ambayo huendelea kuishi baada ya muunganisho kukatika. Tumia tmux new -A -s gemini, run gemini ndani yake, tenganisha (detach) kwa Ctrl-b d, na urudishe (reattach) baadaye kwa tmux attach -t gemini.

Je, ni salama kuendesha Gemini CLI kwenye seva ya uzalishaji (production box)?

Ni salama tu ikiwa utafanya kwa uangalifu, kwa sababu wakala (agent) mwenye ufikiaji wa shell anaweza kufanya chochote ambacho mtumiaji anayefanya kazi naye anaweza kufanya. Irun kama mtumiaji maalum asiye na mamlaka (unprivileged user) asiye na sudo, weka siri za uzalishaji mbali na mashine hiyo, epuka idhini ya kiotomatiki ya --yolo, na utumie --sandbox (Docker au Podman) ili kutenganisha wito wa zana (tool calls) kutoka kwa host. Akaunti inayoiendesha ni muhimu zaidi kuliko flag yoyote unayoweka.

Je, ninahitaji kufungua port yoyote ya firewall kwa Gemini CLI?

Hapana. Ni mteja (client) unaofanya wito wa HTTPS kuelekea kwenye API za Google, hivyo unahitaji port ya 443 ya kutoa (outbound) lakini hauhitaji port za kuingia (inbound). Ikiwa unatumia njia ya OAuth, port ya mrejesho iliyofungwa (kwa mfano 8085) ipo kwenye localhost na inafikiwa kupitia SSH forward yako, si kupitia port ya kuingia iliyofunguliwa. Weka ulinzi mkali kwenye port za kuingia.