Cách cài đặt Gemini CLI trên VPS headless qua SSH

Bạn đang xây dựng gì

Một Gemini CLI luôn chạy trên máy chủ của bạn, có thể truy cập qua SSH, thực hiện các tác vụ agent dài hạn mà vẫn tiếp tục chạy sau khi bạn đóng laptop. Việc cài đặt chỉ gồm ba lệnh. Phần tốn công sức là những thứ vốn mặc định dành cho máy tính để bàn: CLI của Google muốn mở trình duyệt để bạn đăng nhập, nhưng máy chủ của bạn thì không có trình duyệt. Vì vậy, phần lớn hướng dẫn này là về cách thiết lập headless, cài đặt phiên bản Node hiện đại mà distro không cung cấp sẵn, cài đặt npm toàn cục không cần quyền root, xác thực không cần trình duyệt bằng API key được lưu tách biệt khỏi lịch sử shell, và dùng tmux để phiên SSH bị ngắt không làm gián đoạn tác vụ đang chạy.

Gemini CLI là một chương trình Node mã nguồn mở (Apache-2.0) (@google/gemini-cli) giao tiếp với các model Gemini của Google, có khả năng đọc/ghi file, chạy lệnh shell và điều khiển các công cụ trong thư mục làm việc. Trên một VPS, nó là một agent nhỏ, luôn sẵn sàng để bạn để nó tự chạy, đó là lý do tại sao tài khoản dùng để chạy nó và các thông tin xác thực lưu trên máy chủ quan trọng hơn bất kỳ thiết lập đơn lẻ nào ở đây.

Các điều kiện tiên quyết và những cạm bẫy cần lưu ý

• Một VPS Ubuntu 24.04 KVM mới với quyền root hoặc sudo. Mọi gói KVM đều dùng được; bản thân CLI này rất nhẹ, chỉ tốn vài trăm MB RAM khi chạy ngầm.
• Node.js 20 hoặc mới hơn. Đây là yêu cầu bắt buộc về phiên bản, gói mặc định của distro không đáp ứng được, xem phần tiếp theo.
• Cho phép kết nối HTTPS (cổng 443) ra ngoài tới các API của Google. Không cần mở cổng inbound; đây là client, không phải server, nên bạn không cần mở bất kỳ lỗ hổng firewall nào.
• Một phương thức xác thực không cần trình duyệt trên server: dùng Gemini API key từ Google AI Studio, hoặc SSH tunnel về trình duyệt trên máy cá nhân của bạn. Cách dùng API key là phương án tối ưu cho các script và tiến trình chạy tự động.
• Docker hoặc Podman, chỉ cần nếu bạn muốn sự cô lập của --sandbox. Đây là tùy chọn, sẽ được đề cập ở cuối bài.

Cạm bẫy mà ai cũng gặp phải: luồng đăng nhập lần đầu gemini được thiết kế cho máy tính để bàn. Nó cố gắng mở trình duyệt và trên một máy headless, nó sẽ thất bại hoặc đưa cho bạn một đường link không hoạt động. Hãy quyết định phương thức xác thực trước khi bắt đầu.

Lưu ý: gói phần mềm của distro đã quá cũ

Ubuntu 24.04 cung cấp Node 18.19.1 trong kho lưu trữ mặc định, đi kèm với npm 9.2.0. package.json của Gemini CLI yêu cầu engines: { node: ">=20" }, và npm mặc định không chặn việc cài đặt khi có sự khác biệt phiên bản; nó vẫn sẽ cài đặt và in ra một cảnh báo về khoảng cách phiên bản này:

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 }

Nếu bỏ qua cảnh báo đó, CLI sẽ chạy trên một runtime không được hỗ trợ, dẫn đến lỗi hoặc crash ngay khi gặp một API của Node 20+ mà nó mong đợi. Node 18 cũng đã kết thúc vòng đời vào tháng 4 năm 2025, vì vậy đây là một hướng đi không khả thi. Hãy cài đặt một bản LTS hiện tại trước khi cài đặt CLI. Có hai cách sạch sẽ để thực hiện: NodeSource (một apt repo có chữ ký dùng cho toàn hệ thống) hoặc nvm (trình quản lý phiên bản cho từng người dùng). Hãy chọn một cách.

NodeSource, nếu bạn muốn Node khả dụng cho mọi người dùng trên máy chủ:

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 phải in ra v20.x hoặc cao hơn, v24.x là bản LTS đang hoạt động hiện tại. Hãy kiểm tra trang chủ của NodeSource để lấy script thiết lập mới nhất; setup_24.x trong URL là phần cần thay đổi khi có bản LTS mới hơn.

nvm, nếu bạn muốn giữ Node trong thư mục home của một người dùng và không bao giờ cần dùng đến 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 trong URL đó là phiên bản mới nhất tại thời điểm viết bài này; hãy kiểm tra README của nvm để lấy bản release mới nhất và thay thế phiên bản trước khi chạy lệnh. nvm có một ưu điểm thực sự cho công việc này: nó cài đặt Node và các gói global vào trong ~/.nvm, vì vậy vấn đề quyền hạn khi cài đặt global ở phần tiếp theo sẽ không bao giờ xảy ra. Nếu bạn chọn cách dùng nvm, bạn có thể bỏ qua bước npm-prefix.

Cài đặt CLI mà không cần sudo npm -g

Lệnh dễ gây nhầm lẫn là sudo npm install -g @google/gemini-cli. Đừng chạy nó. Một global prefix thuộc sở hữu của root sẽ gây ra lỗi quyền truy cập cho mọi lần cài đặt sau này và để lại các file thuộc quyền root trong npm cache, gây rắc rối về sau. Chạy một lệnh npm install -g thông thường (không sudo) với Node của hệ thống sẽ dẫn đến lỗi khác:

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'

Đó là khi npm cố gắng ghi vào /usr/lib, nơi user của bạn không có quyền. Cách sửa không phải là dùng sudo, mà là trỏ global prefix của npm về thư mục home để các gói cài đặt global nằm ở nơi bạn sở hữu:

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, không phải ~/.profile, là có chủ đích: tmux, công cụ bạn sẽ dùng để chạy CLI trong hai phần tới, khởi tạo một non-login shell đọc file ~/.bashrc và bỏ qua ~/.profile. Do đó, một dòng PATH đặt sai file sẽ khiến gemini không khả dụng đúng nơi bạn cần. Việc gemini --version in ra số phiên bản là bài kiểm tra hoàn chỉnh. Nếu bạn nhận được gemini: command not found, nghĩa là lệnh export PATH của bạn chưa có hiệu lực, hãy xem các kiểu lỗi. Với nvm, hãy bỏ qua hoàn toàn các dòng thiết lập prefix: nó đã tự cài đặt các gói global vào thư mục home của bạn rồi.

Nếu bạn đã chạy sudo npm trước đó và giờ thấy Your cache folder contains root-owned files, hãy sửa lỗi một lần bằng sudo chown -R $(id -u):$(id -g) ~/.npm.

Vấn đề xác thực headless và cách xử lý

Chạy gemini ở chế độ tương tác lần đầu, công cụ sẽ đề nghị bạn đăng nhập bằng tài khoản Google. Trên máy tính cá nhân, thao tác này sẽ mở một tab trình duyệt. Trên VPS headless, không có trình duyệt nào cả, nên luồng xác thực sẽ in ra một URL localhost mà nó mong đợi bạn mở, hoặc thất bại hoàn toàn với thông báo kiểu như:

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

Cái bẫy nằm ở redirect_uri=http://localhost:PORT. Ngay cả khi bạn mở URL đó trên laptop và phê duyệt, Google vẫn redirect về http://localhost:PORT, tức là localhost trên máy chủ, một cổng mà laptop của bạn không thể truy cập tới. Quá trình đăng nhập không bao giờ hoàn tất.

Có hai cách chính thống để vượt qua.

Cách thứ nhất là dùng API key, đây là lựa chọn mặc định phù hợp cho server. Tạo một key trong Google AI Studio (aistudio.google.com) và cung cấp cho CLI thông qua biến môi trường; nó sẽ đọc GEMINI_API_KEY và bỏ qua hoàn toàn luồng xác thực qua trình duyệt. Lưu ý phần "giữ nó khỏi lịch sử lệnh và các file mà người khác có thể đọc". Đừng gõ export GEMINI_API_KEY=AIza... trực tiếp tại prompt, nó sẽ lưu vào ~/.bash_history dưới dạng văn bản thuần, và đừng lưu nó vào file mà người khác có quyền đọc. Hãy ghi nó vào một file có mode 600 mà shell sẽ load khi khởi động:

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 nghĩa là chỉ user của bạn mới có quyền đọc file này. Xác nhận key đã được nạp vào môi trường bằng printenv GEMINI_API_KEY; nếu lệnh này không in ra gì, CLI sẽ quay lại luồng xác thực trình duyệt và thất bại. Nó cũng đọc file .env trong ~/.gemini/ nếu bạn thích cấu trúc đó, quy tắc vẫn tương tự, nên hãy dùng chmod 600 ~/.gemini/.env.

Cách thứ hai là giữ nguyên việc đăng nhập bằng tài khoản Google cá nhân (và gói miễn phí của nó) bằng cách tunnel callback OAuth về laptop của bạn. Điểm khó là server loopback của CLI bind vào một cổng ngẫu nhiên mỗi lần chạy, nên không có cổng cố định để forward trừ khi bạn ghim nó lại bằng biến môi trường OAUTH_CALLBACK_PORT, sau đó forward chính xác cổng đó:

# 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 không thể mở trình duyệt nên nó sẽ in ra URL xác thực; hãy mở URL đó trên trình duyệt laptop, phê duyệt, và khi Google redirect về http://localhost:8085/..., SSH forward sẽ chuyển nó đến server loopback trên VPS và quá trình đăng nhập hoàn tất. Nếu không ghim cổng, nó sẽ nhảy sang một cổng ngẫu nhiên mỗi lần chạy, khiến không có ssh -L nào thiết lập trước đó có thể bắt được. Cách này hoạt động, nhưng yêu cầu bạn phải ngồi trước trình duyệt, nên không dùng được cho script. Với bất kỳ tiến trình nào chạy nền, hãy dùng API key.

Đối với Vertex AI hoặc dự án Google Cloud thay vì AI Studio, hãy thiết lập GOOGLE_API_KEY cùng với GOOGLE_GENAI_USE_VERTEXAI=true, hoặc GOOGLE_CLOUD_PROJECT cho license Code Assist, áp dụng cùng quy tắc quản lý biến môi trường và file mode 600.

Chạy nó bên trong tmux để phiên SSH bị ngắt không làm nó dừng lại

Một tiến trình gemini bạn khởi chạy trực tiếp từ shell SSH là tiến trình con của shell đó. Nếu mất kết nối, gập laptop, Wi-Fi chập chờn, hoặc quá thời gian chờ (idle timeout), sshd sẽ đóng pseudo-terminal, shell nhận tín hiệu SIGHUP và nó sẽ ngắt kết nối CLI ngay lập tức. Một tác vụ đang chạy dở mười phút sẽ chết theo, và khi kết nối lại, bạn không còn tiến trình nào để khôi phục.

tmux giải quyết vấn đề này bằng cách làm chủ shell thay vì để sshd làm chủ. Đây là mô hình tương tự như chạy một AI coding agent trên VPS từ xa bên trong tmux, và nó hoạt động hoàn toàn giống nhau ở đây:

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 sẽ attach vào một session có tên gemini nếu nó tồn tại và tạo mới nếu chưa có, vì vậy đây là lệnh duy nhất cần chạy ngay sau mỗi lần đăng nhập. Shell bên trong thuộc về tmux server đang chạy độc lập, không phải phiên SSH của bạn, nên việc mất kết nối cũng không làm CLI ngừng hoạt động. Khi kết nối lại, bạn chỉ cần attach là quay lại đúng trạng thái cũ. Nếu bạn chạy nhiều agent session trên cùng một máy, mỗi cái một tmux session, chúng sẽ không thể giao tiếp với nhau, khác với Claude Code là một session có thể chuyển văn bản cho session khác trên cùng VPS, vì vậy hãy giữ mỗi job Gemini độc lập hoặc điều phối chúng thông qua các file trên ổ cứng.

Đối với các tác vụ chạy script không tương tác, Gemini CLI có chế độ headless: gemini -p "summarise the failing tests in this repo" in ra câu trả lời rồi thoát, và --output-format json cung cấp đầu ra dạng máy đọc được để pipe sang nơi khác. Chế độ headless với API key chính là thứ bạn cần bên trong một tmux session đang chạy batch job dài, hoặc được kích hoạt từ một cron entry, với một lưu ý: cron job không load các file cấu hình đăng nhập của bạn, vì vậy hãy cung cấp cho dòng crontab biến GEMINI_API_KEY riêng (hoặc cho lệnh tự source ~/.gemini_env), nếu không CLI sẽ quay về luồng xác thực qua trình duyệt và bị lỗi.

Sandboxing và phân quyền trên máy chủ chạy production

Một agent có quyền truy cập shell chính là một shell. Gemini CLI có thể chạy các lệnh và mặc định nó sẽ hỏi trước mỗi lệnh rủi ro, nhưng người dùng thường chọn --yolo (tự động chấp thuận mọi lệnh gọi công cụ). Khi đó, nó có thể xóa file, push lên git hoặc truy cập các dịch vụ nội bộ với toàn quyền của người dùng đang chạy nó. Trên một máy chủ đang chạy production, đây là phạm vi ảnh hưởng thực tế chứ không phải giả thuyết.

Ba biện pháp kiểm soát, theo thứ tự hiệu quả:

• Chạy bằng một người dùng chuyên biệt, không có quyền root. Không dùng root, không thêm vào nhóm sudo. Tạo một người dùng agent với thư mục home riêng, cài đặt Node và CLI tại đó. Nếu có một lệnh bị hiểu sai, nó cũng chỉ bị giới hạn trong tài khoản đó. Đây là quyết định quan trọng nhất.
• Không lưu credential production trên máy chủ. Không để ~/.aws/credentials production, không copy .env từ production về, không dùng mật khẩu database có quyền ghi vào bất cứ thứ gì quan trọng. Chỉ cấp credential staging hoặc quyền chỉ đọc (read-only).
• Sử dụng sandbox tích hợp. Nếu đã cài Docker hoặc Podman, gemini --sandbox (hoặc GEMINI_SANDBOX=docker) sẽ chạy các lệnh gọi công cụ của agent bên trong một container, cô lập với filesystem và network của host. Đây không phải là giải pháp thay thế cho việc dùng user không đặc quyền, nhưng là lớp bảo vệ thứ hai rất mạnh khi cùng một VPS đang thực hiện các tác vụ thực tế.

Nếu bạn đang chạy Gemini CLI cùng với các công cụ tự host khác, ví dụ như MCP server cung cấp công cụ cho agent trên cùng VPS, hãy coi mỗi khả năng được thêm vào là một bề mặt tấn công mới mà agent có thể tiếp cận. Hãy giới hạn các token được cấp cho nó chỉ trong đúng một công việc duy nhất.

Quota, chi phí và đường dẫn xác thực bạn chọn

Đường dẫn xác thực quyết định cách bạn bị tính phí. Tài khoản Google cá nhân (đường dẫn OAuth) sử dụng gói Gemini Code Assist miễn phí, với giới hạn thực tế theo phút và theo ngày; nếu vượt quá, các yêu cầu sẽ trả về lỗi rate-limit cho đến khi cửa sổ thời gian được reset. Một API key từ AI Studio có thể thuộc gói miễn phí hoặc gói trả phí tùy thuộc vào dự án, key trả phí sẽ nâng giới hạn và tính phí theo token. Xác thực qua Vertex và dự án Google Cloud sẽ được tính phí thông qua Google Cloud.

Hai lưu ý thực tế. Một agent chạy tự động trong vòng lặp có thể tiêu tốn quota rất nhanh, vì vậy hãy theo dõi nó vài lần đầu trước khi tin tưởng giao cho cron job. Và nếu lý do bạn chọn mô hình phía server là vì quyền riêng tư hoặc suy luận không giới hạn thay vì các mô hình được host bởi Google, đó là một công cụ khác, tự host một LLM mã nguồn mở với Ollama trên VPS sẽ giữ các trọng số và prompt trên máy của chính bạn, với cái giá là phải chạy một mô hình nhỏ hơn nhiều so với Gemini.

Cập nhật phần mềm

Gemini CLI thường xuyên có các bản release mới. Vì bạn đã cài đặt nó vào một prefix thuộc sở hữu của người dùng, việc cập nhật không bao giờ cần dùng đến sudo:

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

Có các kênh release như sau: @latest là bản ổn định, @preview là bản preview hàng tuần, @nightly là bản thử nghiệm mới nhất, hãy pin vào @latest cho bất kỳ thứ gì bạn cần sự ổn định. Trên nvm, các gói global nằm dưới phiên bản Node đang hoạt động, vì vậy sau khi nvm use để chuyển đổi phiên bản Node, bạn có thể cần cài đặt lại CLI. Hãy đọc ghi chú phát hành thay vì chạy theo mọi bản vá.

Các chế độ lỗi, với các chuỗi chính xác

npm WARN EBADENGINE Unsupported engine ... required: { node: '>=20' }, sau đó CLI bị crash khi runtime. Phiên bản Node quá cũ, bản distro là 18.19.1, cũng đã hết hạn hỗ trợ. Hãy cài đặt Node 20+ từ NodeSource hoặc nvm, xác nhận bằng node --version, và nếu bạn đã cài nhiều bản Node, hãy kiểm tra which node trỏ đến bản mới chứ không phải /usr/bin/node.

npm error code EACCES / permission denied, mkdir '/usr/lib/node_modules/...'. Cài đặt global vào một prefix thuộc sở hữu của root. Đừng dùng sudo, hãy thiết lập npm config set prefix ~/.npm-global, đặt ~/.npm-global/bin vào PATH, và cài đặt lại với user thường của bạn. Nếu một sudo npm trước đó để lại các file cache thuộc sở hữu của root (Your cache folder contains root-owned files), hãy chạy sudo chown -R $(id -u):$(id -g) ~/.npm.

Failed to open browser, đăng nhập bị treo, hoặc redirect_uri=http://localhost:PORT mà bạn không thể truy cập. Luồng OAuth yêu cầu một trình duyệt mà server không có, và callback localhost của nó trỏ về server chứ không phải laptop của bạn. Hãy sử dụng đường dẫn API-key (GEMINI_API_KEY), hoặc ghim OAUTH_CALLBACK_PORT, forward nó qua SSH với ssh -L, và mở URL đó tại máy cục bộ.

Tiến trình biến mất khi SSH bị ngắt. Bạn đã chạy gemini trực tiếp từ shell SSH, nên nó là tiến trình con của shell đó và bị kết thúc cùng với pty khi ngắt kết nối. Không có cách nào khôi phục. Hãy bắt đầu mọi phiên làm việc với tmux new -A -s gemini và chạy CLI bên trong đó.

Xác thực vẫn lỗi dù đã đặt key, CLI quay lại trình chọn xác thực, hoặc request trả về API key not valid với HTTP 400. Key không nằm trong môi trường mà CLI nhìn thấy. Xác nhận bằng printenv GEMINI_API_KEY; nếu nó trống, ~/.gemini_env của bạn chưa bao giờ được source, hãy kiểm tra dòng đó đã có trong ~/.bashrc chưa, vì các shell tương tác (bao gồm tmux) sẽ đọc file này nhưng cron và các shell không tương tác khác thì không. Một khoảng trắng hoặc dấu ngoặc thừa bên trong giá trị key cũng gây ra API key not valid.

429 / RESOURCE_EXHAUSTED / thông báo giới hạn tốc độ (rate-limit). Bạn đã chạm ngưỡng quota cho tier xác thực mà bạn đang dùng. Hãy đợi cửa sổ thời gian reset, giảm tốc độ agent, hoặc chuyển sang API key có trả phí. Một agent bị kẹt trong vòng lặp thử lại sẽ liên tục gặp lỗi này, hãy dừng nó lại và kiểm tra xem nó đang thực hiện tác vụ gì.

FAQ

Làm thế nào để xác thực Gemini CLI trên server headless?

Hãy dùng API key thay vì đăng nhập qua trình duyệt. Tạo một key trong Google AI Studio, lưu nó vào một file có mode 600 mà shell của bạn sẽ đọc (export GEMINI_API_KEY=...), khi đó CLI sẽ bỏ qua hoàn toàn quy trình OAuth trên trình duyệt. Nếu bạn muốn dùng gói miễn phí của tài khoản cá nhân, hãy ghim cổng loopback bằng OAUTH_CALLBACK_PORT=8085, forward nó về laptop của bạn bằng ssh -L 8085:localhost:8085 user@server, rồi mở URL được in ra trên máy cục bộ. Tuy nhiên, cách này yêu cầu bạn phải thao tác trên trình duyệt nên không dùng được cho các script tự động.

Tại sao npm global install lại yêu cầu sudo, và làm sao để tránh nó?

Vì prefix mặc định cho các gói global của npm là /usr/lib/node_modules, nơi user của bạn không có quyền ghi, nên lệnh npm install -g thông thường sẽ bị lỗi EACCES. Cách sửa sai là dùng sudo npm -g, việc này để lại các file thuộc sở hữu của root và gây lỗi cho các lần cài đặt sau. Cách sửa đúng là trỏ prefix về thư mục home của bạn (npm config set prefix ~/.npm-global) và thêm bin của nó vào PATH, hoặc dùng nvm để tự động cài đặt các gói global vào thư mục home.

Làm thế nào để giữ cho Gemini CLI chạy sau khi tôi ngắt kết nối?

Hãy chạy nó bên trong tmux. Một tiến trình khởi chạy từ SSH shell sẽ bị tắt khi kết nối bị ngắt vì nó là tiến trình con của shell đó; tmux chạy shell bên trong một server tách biệt, giúp nó tồn tại sau khi ngắt kết nối. Hãy dùng tmux new -A -s gemini, chạy gemini bên trong đó, detach bằng Ctrl-b d, và reattach lại sau bằng tmux attach -t gemini.

Chạy Gemini CLI trên máy production có an toàn không?

Chỉ an toàn nếu bạn cẩn thận, vì một agent có quyền truy cập shell có thể làm bất cứ điều gì mà user đang chạy nó có thể làm. Hãy chạy nó dưới một user chuyên biệt, không có quyền sudo, không lưu thông tin xác thực production trên máy, tránh dùng --yolo để tự động phê duyệt, và sử dụng --sandbox (Docker hoặc Podman) để cô lập các lệnh gọi công cụ khỏi host. Tài khoản dùng để chạy quan trọng hơn bất kỳ flag đơn lẻ nào bạn thiết lập.

Tôi có cần mở cổng firewall nào cho Gemini CLI không?

Không. Đây là một client thực hiện các lệnh gọi HTTPS hướng ra ngoài tới các API của Google, nên nó cần cổng 443 outbound nhưng không cần cổng inbound nào cả. Nếu bạn dùng tunnel OAuth, cổng callback được ghim (ví dụ 8085) nằm trên localhost và được truy cập thông qua SSH forward của bạn, không phải là một cổng inbound mở. Hãy giữ cho các cổng inbound luôn bị khóa.