Cách Kết Nối Đến VPS Của Bạn Qua Tor

Anonymity · 8 phút đọc

Trả lời nhanh: Bạn có thể định tuyến SSH qua Tor theo hai hướng: trỏ máy khách của bạn vào proxy SOCKS cục bộ của Tor để ẩn IP của chính bạn khỏi máy chủ, hoặc công bố cổng SSH của VPS như một dịch vụ onion Tor để bản thân máy chủ không bao giờ có cổng SSH nào có thể truy cập được trên mạng công cộng (clearnet). Cả hai có thể được kết hợp để không đầu nào của phiên kết nối chạm vào internet mở. Hãy dự đoán độ trễ cao hơn đáng kể so với kết nối trực tiếp, vì vậy hãy coi đây là kỹ thuật truy cập quản trị cho công việc shell tương tác, không phải phương tiện truyền tải cho các tệp lớn.

Hai vấn đề khác nhau, cả hai đều được gọi là 'SSH qua Tor'

Những người tìm kiếm truy cập tor vps thường đang cố giải quyết một trong hai vấn đề khác nhau, và cách thiết lập khác nhau tùy theo vấn đề nào áp dụng. Vấn đề đầu tiên là ở phía máy khách: bạn muốn ẩn địa chỉ IP của chính mình khỏi máy chủ, khỏi bất kỳ ai theo dõi mạng cục bộ của bạn, và khỏi bất kỳ ai sau này triệu tập log kết nối của nhà cung cấp VPS. Vấn đề thứ hai là ở phía máy chủ: bạn muốn bản thân VPS không có cổng SSH nào có thể truy cập được từ internet công cộng, để nó không thể bị tìm thấy bởi một công cụ quét cổng, không thể bị nhắm mục tiêu bởi một bot credential-stuffing, hoặc không thể bị định vị địa lý bởi dịch vụ đang lắng nghe của nó.

Đây không phải là loại trừ lẫn nhau. Rất nhiều sự nhầm lẫn trong các luồng thảo luận diễn đàn về ssh over tor bắt nguồn từ việc mọi người lẫn lộn giữa 'tôi muốn giấu ai đang kết nối' và 'tôi muốn giấu đang kết nối đến cái gì'. Hướng dẫn này bao gồm cả hai, bắt đầu với thiết lập phía máy khách đơn giản hơn, sau đó là cách tiếp cận dịch vụ onion cho máy chủ, sau đó là cách gia cố kết quả và hiệu năng thực tế bạn nên mong đợi.

Ẩn danh phía máy khách: máy khách SSH của bạn định tuyến qua Tor để máy chủ (và bất kỳ ai ghi log kết nối đến của nó) thấy một exit hoặc relay Tor, không phải IP thật của bạn
Ẩn danh phía máy chủ: sshd chỉ có thể truy cập qua một địa chỉ onion Tor, vì vậy không có IP:cổng công khai nào cho SSH cả

Phương pháp 1: định tuyến máy khách SSH của bạn qua proxy SOCKS của Tor

Một máy khách Tor đang chạy (daemon Tor, không nhất thiết là Tor Browser) mở một proxy SOCKS5 cục bộ, mặc định tại 127.0.0.1:9050. Bất kỳ ứng dụng nào hỗ trợ SOCKS đều có thể được trỏ vào đó, và bản thân SSH không nói SOCKS một cách gốc, vì vậy bạn cần một cầu nối nhỏ. Hai cách tiếp cận phổ biến là torsocks, bao bọc một lệnh và buộc các kết nối TCP của nó đi qua proxy, và một mục ProxyCommand trong cấu hình SSH của bạn để dẫn kết nối qua một netcat hỗ trợ SOCKS.

Cách kiểm tra nhanh nhất đơn giản là: cài đặt tor, xác nhận nó đang chạy, sau đó chạy torsocks ssh user@your-vps-ip. Nếu kết nối được, phiên SSH của bạn giờ đang được định tuyến qua một mạch Tor ba bước nhảy (three-hop). Với thứ bạn sẽ dùng hằng ngày, hãy thêm một khối Host vào ~/.ssh/config thay vì gõ torsocks mỗi lần, dùng một dòng ProxyCommand như nc -X 5 -x 127.0.0.1:9050 %h %p (với OpenBSD netcat) hoặc connect -S 127.0.0.1:9050 %h %p (với công cụ connect-proxy). Bằng cách đó ssh myhost đơn thuần vẫn hoạt động và luôn đi qua Tor mà bạn không phải nhớ bộ bao bọc.

Xác minh Tor thực sự đang chạy và lắng nghe trên 9050 trước khi khắc phục sự cố của bản thân SSH
torsocks ssh user@host là cách nhanh nhất để kiểm tra; một ProxyCommand trong ~/.ssh/config là cách bền vững để sử dụng hằng ngày
Phương pháp này ẩn IP của bạn khỏi VPS và khỏi bất kỳ ai đọc log xác thực của nó, nhưng bản thân cổng SSH vẫn mở cho internet công cộng

Phương pháp 2: công bố SSH như một dịch vụ onion Tor trên VPS

Nếu mục tiêu là giữ địa chỉ IP của chính VPS hoàn toàn ngoài bức tranh cho truy cập quản trị, máy chủ cần chạy Tor và chỉ công bố sshd như một dịch vụ ẩn (hidden service). Cài đặt tor trên VPS, sau đó thêm hai dòng vào torrc: HiddenServiceDir trỏ đến một thư mục mà Tor có thể ghi vào, và HiddenServicePort 22 127.0.0.1:22, báo cho Tor chuyển tiếp các kết nối đến cổng 22 của địa chỉ onion đến sshd đang lắng nghe cục bộ. Khởi động lại Tor, và nó sẽ tạo một tên miền .onion ngẫu nhiên dài trong thư mục đó ở lần khởi động đầu tiên.

Quan trọng là, bước này chỉ loại bỏ sự phơi nhiễm nếu sshd cũng được cấu hình để chỉ gắn (bind) vào 127.0.0.1 thay vì giao diện công cộng của VPS (ListenAddress 127.0.0.1 trong sshd_config, sau đó khởi động lại sshd). Bỏ qua bước này khiến SSH vẫn có thể truy cập được cả qua địa chỉ onion lẫn trực tiếp trên IP công cộng, điều này làm mất đi ý nghĩa của việc thiết lập. Sau khi hoàn tất, kết nối từ phía máy khách bằng torsocks ssh [email protected] — không có địa chỉ IPv4 hoặc IPv6 công cộng nào cho SSH từng xuất hiện trong một lần quét cổng của VPS.

Thêm HiddenServiceDir và HiddenServicePort 22 127.0.0.1:22 vào torrc, sau đó khởi động lại Tor
Gắn bản thân sshd chỉ vào 127.0.0.1 — một dịch vụ onion đứng trước một cổng vẫn công khai không ẩn đi được gì
Đọc tệp hostname được tạo ra bên trong HiddenServiceDir để lấy địa chỉ .onion cần kết nối
Kết nối bằng torsocks ssh [email protected]; một IP thuần túy sẽ không còn hoạt động cho SSH nữa

Khóa chặt xác thực khi SSH chỉ trả lời trên .onion

Ẩn cổng không thay thế việc gia cố đăng nhập. Dùng cặp khóa ed25519, tắt hoàn toàn xác thực bằng mật khẩu (PasswordAuthentication no), và tắt đăng nhập root qua SSH (PermitRootLogin no). Nếu khóa bạn dùng để truy cập VPS này là cùng một khóa bạn dùng cho các tài khoản hằng ngày của mình, tính ẩn danh có được từ dịch vụ onion bị phá hỏng ngay khi dấu vân tay (fingerprint) của khóa đó xuất hiện trong một vụ rò rỉ dữ liệu hoặc một lần quét Shodan/Censys gắn với tên bạn ở nơi khác — hãy tạo một khóa riêng dành cho hạ tầng ẩn danh.

Có một điều lặng lẽ ngừng hoạt động trong thiết lập này: các công cụ dựa trên IP như fail2ban. Vì các kết nối đến sshd thông qua tiến trình Tor cục bộ, địa chỉ nguồn mà sshd ghi log là 127.0.0.1 cho mọi lần đăng nhập, thành công hay không — không có IP kẻ tấn công nào để chặn. Đó không phải là một khoảng trống bạn cần lấp bằng một giải pháp thay thế; xác thực chỉ bằng khóa không có phương án dự phòng mật khẩu đã loại bỏ rủi ro brute-force mà fail2ban tồn tại để giảm thiểu. Chỉ đừng mong đợi log của nó có ý nghĩa trong cấu hình này.

Xác thực chỉ bằng khóa, ed25519, không có phương án dự phòng mật khẩu
Một cặp khóa riêng cho mỗi máy chủ ẩn danh, không bao giờ tái sử dụng từ một máy cá nhân
PermitRootLogin no, và một tài khoản không phải root với sudo cho công việc thực tế
Đừng dựa vào fail2ban hay danh sách cho phép theo IP một khi lưu lượng đến qua Tor — IP nguồn trong log luôn là loopback

Hiệu năng thực tế trông như thế nào

Một mạch Tor tiêu chuẩn gồm ba relay, và một kết nối dịch vụ onion xếp chồng hai mạch ba bước nhảy đầu cuối (một từ máy khách vào mạng Tor, một từ mạng Tor đến dịch vụ ẩn), vì vậy độ trễ khứ hồi thường rơi vào khoảng vài trăm mili giây đến vài giây, với những đợt tăng vọt thỉnh thoảng khi một mạch được xây dựng lại. Công việc tương tác — chỉnh sửa tệp cấu hình, kiểm tra log, khởi động lại một dịch vụ — hoàn toàn có thể sử dụng được ở mức độ trễ đó. Đặt ServerAliveInterval trong cấu hình SSH của bạn để các phiên nhàn rỗi không bị ngắt bởi bước nhảy phụ, và hãy chấp nhận thỉnh thoảng bị khựng lại khi Tor chọn một mạch mới.

Điều không hoạt động tốt là thông lượng. scp, rsync, hay bất cứ thứ gì di chuyển hàng gigabyte sẽ bò chậm so với một kết nối trực tiếp, vì các mạch Tor được tối ưu cho tính tương tác độ trễ thấp trên nhiều luồng ngắn hạn, chứ không phải băng thông bền vững. Với truyền dữ liệu thực sự — sao lưu, tải lên lớn — hãy dùng một kênh mã hóa trực tiếp (SSH/rsync thuần trên IP công cộng, hoặc một đường hầm WireGuard) và dành riêng đường Tor cho truy cập shell quản trị nơi việc ẩn kết nối quan trọng hơn tốc độ.

Những lỗi lặng lẽ phá vỡ tính ẩn danh mà bạn đang cố đạt được

Hầu hết các thất bại ở đây không phải là kỳ lạ — chúng là những khoảng trống cấu hình nhỏ để lại một cửa ngách mở. Hãy để ý những điều sau trước khi bạn tin tưởng vào thiết lập:

Không điều nào trong số này đòi hỏi công cụ tiên tiến để tránh; chúng chỉ đòi hỏi kiểm tra các cổng đang lắng nghe thực tế và hành vi DNS một lần, thay vì giả định rằng cấu hình Tor một mình đã hoàn thành công việc.

sshd vẫn gắn với giao diện công cộng song song với dịch vụ onion, vì vậy cổng 'ẩn' cũng có thể tìm thấy được bởi một lần quét cổng thuần túy
Phân giải tên máy chủ bên ngoài Tor (một lần tra cứu DNS lạc, hoặc một ứng dụng bỏ qua proxy SOCKS cho DNS) làm rò rỉ host bạn sắp kết nối trước khi kết nối Tor thậm chí bắt đầu
Một ProxyCommand âm thầm quay lại kết nối trực tiếp nếu Tor không chạy — hãy cấu hình nó để thất bại theo hướng đóng (fail closed), không phải mở, để một daemon Tor đã chết nghĩa là không có kết nối thay vì một kết nối clearnet ngoài ý muốn
Tái sử dụng một khóa SSH, dấu nhắc terminal, hay lịch sử shell gắn phiên này với một danh tính không ẩn danh ở nơi khác

So sánh các phương pháp truy cập SSH
Phương pháp	Ẩn đi cái gì	Độ trễ thêm điển hình	Công sức thiết lập
SSH trực tiếp qua clearnet	Không gì ngoài mã hóa riêng của SSH	Không có	Không có
Máy khách định tuyến qua proxy SOCKS của Tor	Địa chỉ IP của bạn, khỏi máy chủ và log của nó	Vừa phải — khoảng một mạch Tor, ~300ms-1s	Thấp — torsocks hoặc một dòng ProxyCommand
SSH được công bố như một dịch vụ onion Tor	IP công cộng của VPS; không có cổng SSH mở trên internet	Vừa phải đến cao — thêm mạch ở phía máy chủ	Trung bình — thay đổi torrc và sshd_config
Kết hợp cả hai: máy khách qua Tor, máy chủ là dịch vụ onion	Cả hai đầu của kết nối đều tránh xa clearnet hoàn toàn	Cao nhất — hai mạch 3-bước-nhảy độc lập	Trung bình

FAQ

SSH qua Tor có làm suy yếu mã hóa của SSH không?+

Không. SSH đàm phán kênh mã hóa đầu cuối riêng của nó một cách độc lập với phương tiện truyền tải mang nó. Tor thêm lớp mã hóa mạch riêng của nó lên trên, vì vậy lưu lượng được mã hóa hai lần, không phải một lần với thứ gì đó yếu hơn.

SSH qua Tor có quá chậm cho công việc quản trị thực sự không?+

Đối với các phiên shell tương tác — chỉnh sửa tệp, kiểm tra log, khởi động lại dịch vụ — độ trễ thêm vào là đáng chú ý nhưng vẫn quản lý được. Đối với truyền tải hàng loạt như sao lưu hay tải lên lớn, hãy dùng một kết nối trực tiếp hoặc WireGuard thay thế và dành đường Tor cho truy cập quản trị.

Tôi có thể vẫn dùng fail2ban nếu SSH chỉ có thể truy cập qua một dịch vụ onion không?+

Không có ý nghĩa nhiều. Các kết nối đến sshd từ tiến trình cục bộ của Tor, vì vậy mọi lần đăng nhập đều ghi log như đến từ 127.0.0.1. Hãy dựa vào xác thực chỉ bằng khóa không có phương án dự phòng mật khẩu thay thế, vì điều đó loại bỏ rủi ro brute-force mà fail2ban được thiết kế để giải quyết.

Tôi có cần một VPN cũng như Tor để truy cập VPS không?+

Thường là không. Xâu chuỗi một VPN thương mại đứng trước Tor phần lớn chỉ chuyển sự tin cậy sang nhà cung cấp VPN mà không thêm bảo vệ thực sự nào cho trường hợp sử dụng này. Chỉ Tor cho phiên SSH, hoặc một đường hầm WireGuard khi độ trễ quan trọng hơn việc định tuyến qua mạng Tor, bao phủ các trường hợp thực tế.

Cả hai đầu có cần chạy Tor không, hay chỉ laptop của tôi?+

Chỉ máy khách của bạn cần chạy Tor để ẩn IP của chính bạn khỏi máy chủ (Phương pháp 1). Ẩn IP của máy chủ cũng đòi hỏi VPS phải chạy Tor, với sshd được công bố như một dịch vụ onion (Phương pháp 2) — hai thiết lập độc lập với nhau và có thể được dùng riêng lẻ hoặc kết hợp.

Sẵn sàng chuyển sang offshore?

Không KYC, không cần email — chỉ cần khóa ẩn danh và crypto. Triển khai trong ~55 giây.

Cấu hình VPS của bạn →