Thread này hay và bổ ích đó anh . Cho em hỏi vài câu:

1. Về whois
Giả sử whois lên thì ta đc kết quả site hva.net là
ns1.dns.net
ns2.dns.net
trong khi đó nslookup ta đc chỉ 1 cái là ns1.dns.net?
 

[root@network ~]# nslookup
> set type=any
>hva.net

2. Giả sử có nhiều domain trỏ về thì thêm bản ghi chổ nào?  

zone "langla.com" IN {
        type master;
        file "langla.zone";
        allow-update { none; };
};

$TTL 86400
@       IN SOA  ns.network.com. root.ns.network.com. (
                                        2010091101      ; serial
                                        1D      ; refresh
                                        1H      ; retry
                                        1W      ; expire
                                        3H )    ; minimum
@       NS      ns.network.com.
ns      A       192.168.137.222
www     A       192.168.137.222
@       A       192.168.137.222
mail    A       192.168.137.222

$TTL 86400
@       IN SOA  ns.network.com. root.ns.network.com. (
                                        2010091101      ; serial
                                        1D      ; refresh
                                        1H      ; retry
                                        1W      ; expire
                                        3H )    ; minimum
@       NS      ns.network.com.
222     PTR     ns.network.com.
222     PTR     www.network.com.
222     PTR     network.com.
222     PTR     mail.network.com.
222     PTR     langla.com.
222     PTR     www.langla.com.

Cho mình hỏi.
Nếu muốn authentication từ cả 2 phía Sever <=> Client. Phải cấu hình thế nào?
Khi đó quá trình bắt tay, chứng thực, mã hoá sẽ diễn ra như thế nào?
 

Cho mình hỏi.
Nếu muốn authentication từ cả 2 phía Sever <=> Client. Phải cấu hình thế nào?
Khi đó quá trình bắt tay, chứng thực, mã hoá sẽ diễn ra như thế nào?
 

Em chưa hiểu lắm câu hỏi của anh Conmale.


Nhưng theo em biết về dịch vụ SSH thì thế này:
Trường hợp Authentication phía server (Vì em thấy rất nhiều website đang để ssh như vậy):
1. Server cung cấp dịch vụ sshd, tự tạo ra một cặp key private/public.
2. Client request kết nối ssh đến server được Sever đẩy cho 1 public key (hoặc được copy, add bằng tay vào Client) chứa các thông tin định danh server.
3. Client kiểm tra và trusted public key này và sử dụng nó để mã hóa session key gửi lên.
4. Server sử dụng private key để giải mã lấy session key

Đây chính là bước kiểm soát authentication bằng cặp key trên. Không tính user/password.
Kiểm soát bằng việc trust hoặc không trust key được tạo ra.

Vấn đề em gặp phải ở đây là bất kỳ Client nào tạo request kết nối đến SSH server đều được Server đẩy cho public key của mình. Như vậy Client nào cũng có thể kết nối được đến Server miễn là chỉ cần user/password.

Vậy làm cách nào để Server kiểm tra Client đó có "trust" thật ko?. Để có user/pass cũng không kết nối được.

Theo em nghĩ phải có thêm bước ngược lại ở trên: Client tự tạo public và private key của mình, sau đó copy, add bằng tay lên server. Mỗi khi khởi tạo kết nối, client sẽ trình public key của mình ra cho server thấy nếu đúng thì mới tiếp tục các bước tiếp theo.
Có đúng vậy không anh?

@ xnohat: thank bài viết của bạn. Mình muốn biết khi bật tính năng đăng nhập ( xác thực ) bằng Public/Private Key cụ thể nó hay như thế nào?
 

@ sửa máy xnohat : có cần thêm dòng

Code:

chkconfig [--level <levels>] SSH on

không ta  

Ikut3 wrote:

@ sửa máy xnohat : có cần thêm dòng

Code:

chkconfig [--level <levels>] SSH on

không ta  

à trên Ubuntu thì không cần lệnh này do nó có gốc xứ từ họ Debian , nó vẫn sử dụng các script trong init để khởi chạy các tiến trình dịch vụ trong suốt quá trình khởi động hệ thống . Do đó ngay lệnh chkconfig cũng không có sẵn trên các hệ thống Ubuntu

vì thấy Ikut3 hỏi lệnh chkconfig nên anh nghĩ là em thường sử dụng distro thuộc họ Red Hat ? Nếu đúng vậy thì với họ Red Hat thì chuyện chạy lệnh trên là nên vì Red Hat chặt chẽ hơn Ubuntu , nó buộc quản lý các dịch vụ theo runlevel ( Ubuntu cũng có upstart nhưng hình như ít dùng lắm ), việc quản lý theo runlevel giúp kiểm soát các hoạt động của dịch vụ trên hệ thống kĩ lưỡng hơn 

sysv-rc-conf sshd on

mình nghĩ ngoài việc thảo luận cách cài đặt dịch vụ, thì nên mở rộng theo chiều sâu thế này:

* nên bắt đầu bằng giao thức. ví dụ thảo luận về dịch vụ DNS mà lại không nói về giao thức DNS thì dễ dẫn đến nhầm lẫn *đã hiểu về DNS nhưng thật ra không hiểu gì về DNS*. hoặc thảo luận về OpenSSH thì cũng nên thảo luận về giao thức SSH, chẳng hạn như ai cũng nói là Public-Key Authentication an toàn, vậy thực chất nó an toàn hơn ở mức độ nào? nếu nói PKA là an toàn, vậy thì Password-Based Authentication không an toàn ở chỗ nào? đóng góp của bạn antiadmin là điểm khởi đầu tốt, nên đào sâu hơn nữa.

* nên nói thêm về các rủi ro thường gặp, và cách để kiện toàn các dịch vụ này. ví dụ như OpenSSH thường bị scan, vậy làm thế nào để phòng ngừa? cách tốt nhất là gì?

* bàn thêm về việc đảm bảo tính sẵn sàng cao cho các dịch vụ này. ví dụ như DNS là một dịch vụ rất quan trọng, vậy làm thế nào để đảm bảo nó luôn chạy?

-m 

Vấn đề em gặp phải ở đây là bất kỳ Client nào tạo request kết nối đến SSH server đều được Server đẩy cho public key của mình. Như vậy Client nào cũng có thể kết nối được đến Server miễn là chỉ cần user/password.

Vậy làm cách nào để Server kiểm tra Client đó có "trust" thật ko?. Để có user/pass cũng không kết nối được.

 

antiadmin wrote:

Vấn đề em gặp phải ở đây là bất kỳ Client nào tạo request kết nối đến SSH server đều được Server đẩy cho public key của mình. Như vậy Client nào cũng có thể kết nối được đến Server miễn là chỉ cần user/password.

Vậy làm cách nào để Server kiểm tra Client đó có "trust" thật ko?. Để có user/pass cũng không kết nối được.

 

Chào bạn,
Theo mình để làm rõ vấn đề này đầu tiên chúng ta nên xác định chúng ta cần gì ở đây. Chúng ta cần làm sao để server xác định được người dùng đăng nhập đến là người dùng hợp lệ có quyền truy nhập vào hệ thống (hay theo bạn nói là "trust thật"). Server có thể đưa ra nhiều cách để xác định: user/password, key-based... Tại sao user và pass không thể dùng để trust được mà cặp pub/pri key lại có thể trust được? Nói đơn giản thì thế này: server trust client chính bằng cặp user/pass, client có thể đưa ra cặp user/pass chứng tỏ client đó trust được (chúng ta - server quy định điều đó cơ mà). Client có user/pass thì trên server cũng phải lưu giữ cặp giá trị này (hoặc tương đương) để từ đó xác định người dùng có quyền ko, tương tự với cặp pub/pri key, như bạn nói server cũng phải lưu public key của client phải ko nào. Nếu bạn nghĩ: "Ồ, user và pass nguy hiểm lắm, nhỡ lộ thì sao, làm sao mà trust được?", vậy private key thì sao, cũng dễ dàng bị chẩm mất lắm chứ . Về mặt logic, không có sự khác nhau nào giữa 2 thứ mà bạn kể trên trong việc trust cả.

Mình nghĩ topic này khá hay, tuy nhiên theo mình nên chuyển 1 tuần thành 1 tháng hoặc hơn. Có quá nhiều thứ để nói đến dù chỉ với 1 dịch vụ.

-giobuon 

- Cơ chế làm việc của PKA cũng an toàn hơn cặp user/pass: user/pass phải được truyền qua network mỗi khi đăng nhập,
 

Cho 3 ngày cơ mà
Thiếu Key Generation và đi kèm với nó là khái niệm Euler's totient function.
Encryption và Decryption chưa trình bày tử tế. Lại còn thiếu Digital Signature nữa chứ!

Client nhận server public key sau khi click yes nó được lưu vào known_hosts của client.

Server: Đây là public key của tao, mày chấp nhận không, chấp nhận thì ghi vào know_hosts của mày đi. Nhớ mặt tao nhé. Lần sau mày sẽ không bị hỏi có chấp nhận không.
Client: Ok, tao tin mày, coi như tao đã biết mặt mày, lần tới gặp lại thể nào tao cũng nhận ra.

Lần tới server gửi PU của nó, client check trong known_hosts của nó, so sánh thấy trùng nhau thì ok.

Client muốn connect tới server mà không bị hỏi pass thì public key của client phải nằm ở server:/.ssh/authorized_keys
Copy client identity id_dsa.pub hoặc id_rsa.pub lên server rồi "cat" nó vào authorized_keys của server.

ý nghĩa là:
Client: Ê cu thẻ ra vào của tao đây!
Server: À thẻ thằng này có trong authorized_keys, ok vào đi ku!

trong thư mục server:/ssh/ là public key và private key của server
Ví dụ có id_dsa và id_dsa.pub, id_rsa và id_rsa.pub là identity của server
ơ thế còn ssh_host_dsa_key.pub và ssh_host_dsa_key, lại còn cả ssh_host_key và ssh_host_key.pub
ssh_host_rsa_key.pub và ssh_host_rsa_key
? mấy cái này là cái gì? dsa và rsa ý nghĩa là dùng giải thuật nào đấy. Như kiểu tiếng Lào tiếng Thái đấy.

Mấy file đó có ý nghĩa gì? xem ssh_config và sshd_config.

cẩn thận id_dsa.pub của client được copy lên .ssh của server mà lại quên chưa xóa thì nó là của client đấy.
Các Identity của server nằm ở thư mục hiện /ssh/ chứ ko phải thư mục ẩn /.ssh/. Xem thêm các file config


Dùng client connect đến server sau đó xem trong know_hosts của client có chứa cái entry nào trùng với cái file .pub nào trong thư mục ssh trên server.

Nếu chỉ dùng E (PU, M) thì trong M phải có thông tin thằng gửi . Thằng nào gửi? Có toàn vẹn(integrity) không? Ở đây cần digital signature của client nếu nó dùng public key.

Còn không xác thực bằng pass thì nó sinh session key na ná SSL protocol.

Với môi trường mà chỉ cần server broadcast messages tới clients ko cần bí mật chỉ cần E(PR của server, M+hash(M)) là đủ (chống replay attack có thể thêm time stamp vào). Nơi nhận dùng PU của server để giải mã.

Mô tả RSA thế kia là chưa đủ. Chả khác gì PKI không mà còn chưa đủ. Còn Elgamal nữa. Lại còn EC và Pailler cũng là Public Key, chưa kể thiên hạ còn bịa ra một số loại khác nữa!

Hiểu PKI, RSA, Egamal đi, có lợi cho cậu chứ ko cho tớ đâu!


# đã chỉnh thành Euler's totient function theo comment của bác Starghost