SSH: Tính xác thực của máy chủ <host> không thể được thiết lập


83

Thông điệp này có ý nghĩa gì? Đây có phải là một vấn đề tiềm năng? Là kênh không an toàn?

Hay đây chỉ đơn giản là một thông báo mặc định luôn được hiển thị khi kết nối với máy chủ mới?

Trước đây tôi thường thấy thông báo này khi sử dụng SSH: Tôi luôn nhập thông tin đăng nhập bằng mật khẩu theo cách thông thường và tôi cảm thấy ổn vì tôi không sử dụng khóa riêng / công khai (an toàn hơn nhiều hơn một mật khẩu ngắn). Nhưng lần này tôi đã thiết lập khóa công khai với ssh cho kết nối của tôi với bitbucket nhưng tôi vẫn nhận được tin nhắn. Tôi biết rằng dấu nhắc mật khẩu ở cuối là một biện pháp bảo mật bổ sung khác, để giải mã khóa riêng.

Tôi hy vọng ai đó có thể đưa ra một lời giải thích hay cho ý nghĩa của thông điệp "tính xác thực không thể được thiết lập" này.

The authenticity of host 'bitbucket.org (207.223.240.181)' can't be established.

RSA key fingerprint is 97:8c:1b:f2:6f:14:6b:5c:3b:ec:aa:46:46:74:7c:40.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'bitbucket.org,207.223.240.181' (RSA) to the list of
known hosts.
Enter passphrase for key '/c/Users/Steven/.ssh/id_rsa':

2
Đây thực sự là một trong những thông điệp "có nghĩa là chính xác những gì nó nói". Nó có nghĩa là sshkhông có cách nào để nói rằng bạn đang thực sự nói chuyện bitbucket.org. Nếu bạn định cấu hình một số cách để nó biết, thì nó không hoạt động. Nếu bạn không, thì nó nói với bạn rằng bạn đã không làm.
David Schwartz

Câu trả lời:


71

Nó nói với bạn rằng bạn chưa bao giờ kết nối với máy chủ này trước đây. Nếu bạn đang mong đợi điều đó, nó hoàn toàn bình thường. Nếu bạn bị hoang tưởng, hãy xác minh tổng kiểm tra / dấu vân tay của khóa bằng kênh thay thế. (Nhưng lưu ý rằng ai đó có thể chuyển hướng kết nối ssh của bạn cũng có thể chuyển hướng một phiên trình duyệt web.)

Nếu bạn đã kết nối với máy chủ này trước khi cài đặt ssh này, thì máy chủ đó đã được cấu hình lại bằng một khóa mới hoặc ai đó đang giả mạo danh tính của máy chủ. Do mức độ nghiêm trọng của một cuộc tấn công trung gian, nó cảnh báo bạn về khả năng.

Dù bằng cách nào, bạn có một kênh được mã hóa an toàn cho ai đó . Không ai không có khóa riêng tương ứng với dấu vân tay 97:8c:1b:f2:6f:14:6b:5c:3b:ec:aa:46:46:74:7c:40có thể giải mã những gì bạn gửi.

Khóa bạn sử dụng để xác thực bản thân không liên quan ... bạn sẽ không muốn gửi thông tin xác thực đến máy chủ lừa đảo có thể đánh cắp thông tin đó và vì vậy bạn không nên mong đợi bất kỳ thay đổi nào tùy thuộc vào việc bạn sẽ sử dụng cụm mật khẩu hay khóa riêng để đăng nhập. Bạn chỉ đơn giản là chưa đạt được điều đó trong quá trình này.


Vì vậy, ngay cả khi có một bên thứ ba độc hại và tôi bỏ qua tin nhắn, tất cả những gì tôi sẽ làm là gửi cho anh ấy khóa công khai của mình và anh ấy vẫn sẽ không thể giải mã dữ liệu của tôi? Vì vậy, bây giờ cách duy nhất để dữ liệu của tôi có thể bị xâm phạm là nếu (1) khóa riêng của tôi bị xâm phạm hoặc (2) máy chủ của bitbucket bị xâm phạm hoặc (3) tài khoản bitbucket của tôi bị xâm phạm. Chừng nào họ còn hạn chế các lần thử đăng nhập (điều mà tôi thực sự ngạc nhiên nếu họ không làm) thực sự không có nhiều lý do để bị hoang tưởng vào thời điểm này, nhỉ?
Steven Lu

10
@Steven: Bạn không gửi cho anh ấy khóa công khai của bạn, anh ấy đã có nó. Những gì bạn đang làm là sử dụng khóa riêng của bạn để xác thực thử thách ... nếu anh ta kết nối với bitbucket.org thực sự tự xưng là bạn, nhận thử thách thực sự và sử dụng thử thách đó khi thách thức bạn, anh ta có thể lừa bạn gửi cho anh ấy một phản hồi hợp lệ mà sau đó anh ấy sử dụng để có quyền truy cập vào tài khoản của bạn trên bitbucket.org thực. Anh ấy vẫn không có khóa riêng của bạn, vì vậy anh ấy không thể đăng nhập bất kỳ lúc nào trong tương lai hoặc bất kỳ tài nguyên nào khác mở khóa, nhưng anh ấy có một phiên đăng nhập.
Ben Voigt

Đó là những gì tôi muốn nói trong câu trả lời của mình khi tôi nói "bạn sẽ không muốn gửi thông tin xác thực đến một máy chủ lừa đảo".
Ben Voigt

2
"Nếu bạn bị hoang tưởng, hãy xác minh tổng kiểm tra / dấu vân tay của khóa bằng kênh thay thế." Đối với sự hoang tưởng (và cho bản ghi), dấu vân tay của github là trên help.github.com/articles/generating-ssh-keys và bitbucket được đề cập trong confluence.atlassian.com/display/BITBucksET/ của
sundar

1
@BenVoigt Vâng, tôi hiểu rằng, thật sự hoang tưởng của khóa học sẽ có được những trang thông qua một mạng không liên quan khác nhau, hoặc có thể bay đến github trụ sở và lấy dấu vân tay ở người :)
Sundar

21

Hãy để chúng tôi nói bạn gặp ai đó để trao đổi một số bí mật kinh doanh. Cố vấn của bạn nói với bạn rằng bạn chưa bao giờ gặp người đó trước đây và đó có thể là một kẻ mạo danh. Hơn nữa, đối với các cuộc họp tiếp theo với anh ta, cố vấn của bạn sẽ không cảnh báo bạn nữa. Đó là những gì thông điệp có nghĩa. Người này là máy chủ từ xa và cố vấn của bạn là máy khách ssh.

Tôi không nghĩ việc kiểm tra kỹ danh tính của người đó trước khi chia sẻ bí mật với cô ấy là điều hoang tưởng. Chẳng hạn, bạn có thể mở một trang web với hình ảnh của cô ấy và so sánh nó với khuôn mặt trước mặt bạn. Hoặc kiểm tra chứng minh thư của cô ấy.

Đối với máy chủ bitbucket, bạn có thể sử dụng một máy tính khác, đáng tin cậy hơn và lấy hình ảnh khuôn mặt của nó từ đó, sau đó so sánh nó với máy tính bạn đang sử dụng trong máy tính bạn đang sử dụng. Sử dụng:

 ssh-keyscan -t rsa bitbucket.org | ssh-keygen -lv -f -

Nếu các mặt khớp nhau, bạn có thể thêm khóa vào tệp, ví dụ: ~/.ssh/known_hosts(vị trí chuẩn trong nhiều bản phân phối Linux) với:

ssh-keyscan -t rsa -H bitbucket.org >> ~/.ssh/known_hosts

và khách hàng ssh sẽ không cảnh báo bạn vì nó đã biết mặt cô ấy . Nó sẽ so sánh các khuôn mặt bất cứ lúc nào bạn kết nối. Điều đó rất quan trọng. Trong trường hợp kẻ mạo danh (ví dụ như một cuộc tấn công giữa chừng), khách hàng ssh sẽ từ chối kết nối vì khuôn mặt sẽ thay đổi.


Câu trả lời này rất hữu ích
010110110101

4
Đây phải là câu trả lời được chấp nhận: ssh-keyscan -t rsa -H bitbucket.org >> ~/.ssh/known_hosts Cảm ơn Ivan!
Rod

1
@Rod: Bạn sẽ chọn câu trả lời được chấp nhận dựa trên một lệnh hoàn toàn không cần thiết (bạn có thể sửa đổi known_hostsbằng cách chỉ gõ "có" cho cảnh báo ban đầu, như đã được hiển thị trong câu hỏi) và nguy hiểm (khóa bạn đã thêm vào tập tin không nhất thiết phải giống với cái bạn đã xem, bởi vì bạn đã tải nó hai lần!)?
Ben Voigt

@BenVoigt giải pháp này cung cấp rằng gõ "có" không phải là giải pháp này hoàn toàn có thể viết được. Tôi cho rằng hầu hết mọi người có thể tìm ra cách trả lời "(có / không)?" lời nhắc. Tôi đã xem qua Hỏi & Đáp này trong khi cố gắng tìm ra cách giải quyết vấn đề này mà không cần sự can thiệp của con người (đối với tập lệnh thiết lập máy chủ). Trong sự phấn khích của tôi, tôi đoán rằng tôi đã không nhận thấy rằng câu hỏi của OP hơi khác so với tôi, nhưng IMO đây vẫn là câu trả lời hữu ích / không rõ ràng nhất trong chuỗi.
Rod

1
@Rod: Không, nó không hữu ích. Hạ thấp bảo mật của bạn là xấu. Tìm cách nhanh hơn để giảm bảo mật của bạn là hoàn toàn ngược lại với hữu ích.
Ben Voigt

5

Tôi chỉ đơn giản là phải tạo known_hoststập tin văn bản trong~/.ssh

sudo vim ~/.ssh/known_hosts
sudo chmod 777 ~/.ssh/known_hosts

Sau khi làm điều này, nó đã thêm máy chủ và tôi không bao giờ thấy tin nhắn nữa.


Tôi không nghĩ rằng điều đó thực sự thay đổi bất cứ điều gì. Cảnh báo được hiển thị khi chính máy chủ đã thay đổi. Ví dụ: nếu bạn cung cấp một máy ảo mới mà bạn kết nối lần đầu tiên. Cho dù bạn có known_hoststệp (có quyền chính xác hay không) sẽ không ngăn bạn hỏi về tính xác thực của máy chủ mới ... Trừ khi bạn đã lấy chữ ký khóa pub cho máy chủ này và đặt nó vào known_hosts, đó là một cách thông thường để bỏ qua séc (mặc dù chỉ nói "có" với séc thường nhanh hơn để đạt được điều tương tự)
Steven Lu

Cảm ơn. Tôi đã biết_hosts, nhưng tiếp tục nhận được cảnh báo. Tôi chỉ phải thay đổi quyền trên know_host để cảnh báo dừng lại.
ArcaneDominion

6
Xin đừng làm điều này. Có thể là một mối nguy hiểm an ninh nghiêm trọng. Tập tin máy chủ của bạn chỉ nên được ghi bởi bạn. Lệnh thứ hai về cơ bản là cho phép bất kỳ ai trong máy tính của bạn giả mạo danh tính máy chủ.
Stolz

"Cảnh báo được hiển thị khi chính máy chủ đã thay đổi." Hoặc khi máy chủ chưa bao giờ được truy cập trước đây.
Rod

2

Có một cách dễ dàng khác Chỉ cần chạm vào tệp "config" trong /root/.ssh và thêm tham số StricthostKeyChecking no Lần tới khi bạn đăng nhập vào máy chủ, khóa rsa sẽ được thêm vào know_hosts và sẽ không hỏi "có" để xác nhận tính xác thực


3
Điều này không được khuyến khích. Nó là dễ dàng nhưng không phải là cách chính xác để đối phó với tình huống.
Vikas

1

Thông báo này chỉ là SSH cho bạn biết rằng chưa bao giờ thấy khóa máy chủ cụ thể này trước đây, vì vậy không thể xác minh thực sự rằng bạn đang kết nối với máy chủ mà bạn nghĩ là bạn. Khi bạn nói "Có", nó sẽ đặt khóa ssh vào tệp know_hosts của bạn, và sau đó trên các kết nối tiếp theo sẽ so sánh khóa mà nó nhận được từ máy chủ lưu trữ với khóa trong tệp đã biết.

Có một bài viết liên quan về tràn ngăn xếp cho thấy cách vô hiệu hóa cảnh báo này, https://stackoverflow.com/questions/3663895/ssh-the-authenticity-of-host-hostname-cant-be-est Thiết lập .


10
Nhưng vô hiệu hóa cảnh báo không được khuyến khích - nó có mục đích, cung cấp thông tin bảo mật rất hữu ích.
Rory Alsop

0

Ngoài các câu trả lời đã được đưa ra (bạn chưa bao giờ kết nối với máy chủ này trước đây), còn có khả năng khác biệt là bạn chưa bao giờ kết nối TỪ máy chủ hiện tại trước đó (với máy chủ đó); Điều này chỉ khác về mặt tâm lý; bạn nghĩ rằng bạn đang kết nối từ máy chủ A (đến B), trong khi thực sự bạn đang cố gắng kết nối từ máy chủ X (đến B). Ví dụ, điều này có thể xảy ra khi bạn lần đầu tiên ssh-ed từ A đến X và sau đó từ cùng một thiết bị cố gắng ssh đến B nghĩ rằng bạn vẫn ở trên A.


Tôi tự hỏi nếu sử dụng chuyển tiếp tác nhân ssh cũng có thể chặn cảnh báo nếu máy chủ A biết về B nhưng X không, nhưng chuyển tiếp tác nhân diễn ra giữa A và X. Hầu hết các môi trường (cung cấp ssh) và chuyển tiếp tác nhân hỗ trợ chuyển tiếp đại lý, nó giúp cắt giảm số lượng khóa ssh bạn phải quản lý để chỉ các thiết bị cuối của bạn.
Steven Lu

0

Trong trường hợp của tôi, mật khẩu đăng nhập ít hơn không hoạt động vì quyền của thư mục nhà vì tôi đã thay đổi cài đặt mặc định. Cuối cùng, đây là những gì làm việc cho tôi. quyền thư mục nhà của tôi là

/ nhà / tên người dùng

drwxr----x. 18 username     groupname  4096 May 11 11:52 username

/home/username/.ssh

268823097 drwx------   2 username groupname     29 May 11 11:53 .ssh

/home/username/.ssh/authorized_keys

-rw-r----- 1 username groupname 402 May 11 11:53 authorized_keys
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.