Khi server không còn nằm trên máy của bạn
Có một giai đoạn mà hầu hết dev đều trải qua: code không còn chạy trên máy local nữa.
Bạn bắt đầu thuê VPS, deploy lên cloud, chạy job background, config cron, debug production… và nhận ra một sự thật khá “khó chịu”:
Server ở đâu đó ngoài kia — và bạn cần “chui vào bên trong nó”.
Ban đầu, nhiều người chọn cách đơn giản nhất: mở port, dùng FTP upload file, hoặc thậm chí expose service để debug từ xa.
Lúc này mọi thứ vẫn chạy. Nhưng cảm giác không hề “an toàn”.
Khi việc “remote vào server” trở thành vấn đề
Nếu không có một cơ chế chuẩn, việc truy cập server từ xa sẽ nhanh chóng trở nên rối:
- Gửi username/password qua mạng (dễ bị sniff)
- Dùng FTP (truyền plain text)
- Mở port lung tung (tăng attack surface)
- Không kiểm soát được ai đang truy cập server
Tệ hơn, nếu bạn từng:
- Deploy qua FTP và file bị sửa lén
- Password bị lộ
- Server bị brute force
Bạn sẽ hiểu vấn đề không còn là “kết nối được”, mà là:
Kết nối an toàn và kiểm soát được
Thứ chúng ta thực sự cần
Nếu bóc tách lại, nhu cầu cốt lõi không phải là “remote vào server”, mà là:
- Confidentiality → dữ liệu không bị đọc lén
- Integrity → dữ liệu không bị sửa giữa đường
- Authentication → đúng người mới vào được
- Control → biết ai đang làm gì
Và quan trọng hơn:
Tất cả phải diễn ra trên một kênh giao tiếp không đáng tin (Internet)
Đây chính là lý do một cơ chế như SSH ra đời.
SSH – cách chúng ta “nói chuyện riêng” với server
SSH (Secure Shell) không phải là một tool đơn lẻ. Nó là một protocol — một bộ quy tắc giúp bạn giao tiếp với server một cách an toàn.
Hiểu đơn giản:
SSH là cách bạn mở một “phiên làm việc được mã hoá” giữa máy bạn và server.
Một cách hình dung đời thường
- HTTP giống như nói chuyện ngoài quán cà phê → ai cũng nghe được
- SSH giống như nói chuyện trong phòng kín, có khóa, có xác minh người vào
SSH hoạt động như thế nào (bên trong)
Đây là phần quan trọng nhất để hiểu bản chất.
1. Bắt đầu kết nối
Bạn chạy:
ssh root@your_server_ipMáy bạn (client) bắt đầu “bắt tay” với server.
2. Server đưa “chứng minh danh tính”
Server gửi về public key của nó.
👉 Đây giống như “chứng minh thư” của server.
Client sẽ:
- Kiểm tra xem key này đã từng thấy chưa
- Nếu chưa → hỏi bạn có tin không
- Nếu đã lưu → so sánh để tránh bị MITM (man-in-the-middle)
3. Tạo kênh mã hoá
Hai bên thực hiện:
- Key exchange (trao đổi khóa)
- Sinh ra một session key (khóa phiên)
👉 Từ đây trở đi, toàn bộ dữ liệu đều được mã hoá.
4. Xác thực người dùng
Có 2 cách chính:
Password (ít dùng trong production)
- Bạn nhập password
- Server kiểm tra
👉 Dễ dùng nhưng không an toàn (brute force)
SSH Key (chuẩn production)
Bạn có 2 thứ:
- Private key (giữ ở máy bạn)
- Public key (đặt trên server)
Flow:
- Server gửi challenge
- Client dùng private key để ký
- Server dùng public key để verify
👉 Không cần gửi password → cực kỳ an toàn
SSH có những chức năng gì?
1. Truy cập & quản lý server
Đây là use case phổ biến nhất:
ssh root@ipBạn có full quyền:
- chạy lệnh
- restart service
- deploy code
2. Truyền file an toàn
Thay vì FTP, dùng:
scp file.txt root@ip:/home/Hoặc:
rsync -avz ./app root@ip:/var/www/👉 Tất cả đều chạy qua SSH → encrypted
3. SSH Tunnel (cực kỳ mạnh nhưng ít người hiểu rõ)
Bạn có thể “đi đường vòng” qua SSH.
Ví dụ:
ssh -L 3307:localhost:3306 root@serverÝ nghĩa:
- Mở port 3307 trên máy local
- Mọi request sẽ được chuyển vào MySQL trên server
👉 Giống như bạn đang connect DB local, nhưng thực ra là remote
4. Port forwarding / secure proxy
SSH có thể:
- bypass firewall nội bộ
- truy cập service private
- debug production mà không expose port
SSH an toàn đến mức nào?
Nếu dùng đúng cách, SSH cực kỳ an toàn:
Điểm mạnh:
- Mã hoá toàn bộ traffic (encryption)
- Không gửi password (nếu dùng key)
- Chống MITM (nhờ host key verification)
- Có thể disable root login, password login
Nhưng vẫn có thể bị hack nếu:
- Dùng password yếu
- Không đổi port / không rate limit
- Lộ private key
- Không dùng firewall
👉 SSH không phải “tự động an toàn”
→ Nó an toàn khi config đúng
SSH vs SSL/TLS – đừng nhầm
Nhiều người hay nhầm 2 cái này.
Điểm giống:
- Đều mã hoá dữ liệu
- Đều dùng cryptography
Khác nhau ở mục đích:
| SSH | SSL/TLS |
|---|---|
| Remote server | Bảo mật web (HTTPS) |
| Dev/Admin dùng | User cuối dùng |
| Shell, command | HTTP, API |
| Stateful session | Request/Response |
👉 Hiểu đơn giản:
- SSH = bạn đăng nhập vào server
- TLS = user truy cập website an toàn
Cài SSH và connect VPS (DigitalOcean)
Giả sử bạn vừa tạo VPS trên DigitalOcean.
Bước 1: Tạo SSH key trên máy local
ssh-keygen -t ed25519 -C "your_email"Kết quả:
~/.ssh/id_ed25519→ private key~/.ssh/id_ed25519.pub→ public key
Bước 2: Add key vào DigitalOcean
- Vào dashboard
- Add SSH key (copy nội dung
.pub)
Bước 3: Tạo VPS
Chọn:
- Ubuntu
- Chọn SSH key vừa add
👉 Server sẽ tự inject public key
Bước 4: Connect
ssh root@your_ip👉 Không cần password
Bước 5: Hardening (rất quan trọng)
Sau khi login:
# Tạo user mới
adduser bao
# Add quyền sudo
usermod -aG sudo baoDisable root login
Edit:
nano /etc/ssh/sshd_configPermitRootLogin no
PasswordAuthentication noRestart:
systemctl restart sshSetup firewall
ufw allow OpenSSH
ufw enableKhi nào nên dùng / không nên dùng SSH
Nên dùng khi:
- Quản lý server
- Deploy backend
- Truy cập DB private
- Debug production
Không nên dùng khi:
- Build system automation phức tạp → nên dùng CI/CD
- Cho end-user access → dùng web interface/API
- Truyền file lớn liên tục → cân nhắc object storage
Góc nhìn thực tế
SSH không phải là “tool để connect server”.
Nó là:
Một lớp bảo mật nền tảng cho toàn bộ hoạt động vận hành hệ thống
Khi bạn hiểu nó:
- Bạn không còn mở port bừa
- Không còn dùng password login
- Không còn expose service nguy hiểm
Và quan trọng nhất:
Bạn bắt đầu suy nghĩ theo hướng “system-level” thay vì chỉ “code chạy là được”
Kết
Có những thứ trong tech nếu chỉ “biết dùng” thì đủ.
Nhưng SSH không phải một trong số đó.
Vì:
- Nó nằm ở boundary giữa bạn và production
- Nó liên quan trực tiếp đến security
Hiểu SSH không giúp bạn code nhanh hơn.
Nhưng nó giúp bạn không phá production — và điều đó quan trọng hơn rất nhiều.