ssh: Tính xác thực của máy chủ 'tên máy chủ' không thể được thiết lập


153

Khi tôi ssh đến một máy, đôi khi tôi nhận được cảnh báo lỗi này và nó sẽ nhắc "có" hoặc "không". Điều này gây ra một số rắc rối khi chạy từ các tập lệnh tự động ssh sang các máy khác.

Tin nhắn cảnh báo:

The authenticity of host '<host>' can't be established.
ECDSA key fingerprint is    SHA256:TER0dEslggzS/BROmiE/s70WqcYy6bk52fs+MLTIptM.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'pc' (ECDSA) to the list of known hosts.

Có cách nào để tự động nói "có" hoặc bỏ qua điều này không?


27
Tôi khuyên bạn nên chống lại điều này. Bạn cần tìm ra lý do tại sao bạn mắc phải những lỗi này, nếu không, bạn sẽ tự mở lòng với một người đàn ông trong cuộc tấn công trung gian, đó là những gì những lỗi này đang cố gắng bảo vệ bạn khỏi.
Peter Bagnall

3
Điều này có thể do thay đổi máy chủ sử dụng khóa ssh đó hoặc có thể do ai đó ngồi giữa bạn và máy chủ lắng nghe mọi thứ bạn gửi / nhận.
derekdreery

Điều gì có thể là lý do cho lỗi này?
AiU

Tôi không đồng ý với quan điểm của Peter. Trong một tổ chức lớn cố gắng nhờ người khác sửa chữa những vấn đề như vậy khi bạn chỉ cố gắng hoàn thành công việc của mình là không thực tế.
Sridhar Sarnobat

Nhiều tổ chức lớn hoàn toàn trái ngược với những gì @SridharSarnobat đang đề xuất. Bạn phải đảm bảo đúng người giải quyết các loại vấn đề đó và cố gắng giải quyết chúng chỉ khiến mọi việc tồi tệ hơn.
James Moore

Câu trả lời:


135

Tùy thuộc vào ứng dụng khách ssh của bạn, bạn có thể đặt tùy chọn StricthostKeyChecking thành không trên dòng lệnh và / hoặc gửi khóa tới tệp null know_hosts. Bạn cũng có thể đặt các tùy chọn này trong tệp cấu hình của mình, cho tất cả các máy chủ hoặc cho một bộ địa chỉ IP hoặc tên máy chủ nhất định.

ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no

BIÊN TẬP

Như @IanDunn lưu ý, có những rủi ro bảo mật khi thực hiện việc này. Nếu tài nguyên bạn đang kết nối bị kẻ tấn công giả mạo, chúng có khả năng phát lại thách thức của máy chủ đích cho bạn, khiến bạn nghĩ rằng bạn đang kết nối với tài nguyên từ xa trong khi thực tế họ đang kết nối với tài nguyên đó thông tin của bạn. Bạn nên xem xét cẩn thận liệu đó có phải là rủi ro thích hợp hay không trước khi thay đổi cơ chế kết nối của bạn để bỏ qua HostKeyChecking.

Tham khảo .


40
Tôi nghĩ rằng thật vô trách nhiệm khi đề xuất điều này mà không cảnh báo về ý nghĩa bảo mật. superuser.com/a/421084/121091 là một câu trả lời tốt hơn IMO.
Ian Dunn

5
@IanDunn Tôi sẽ đồng ý với bạn trong tình huống máy khách SSH chung, nhưng cho rằng OP nói rõ rằng anh ta gặp phải vấn đề này trong khi chạy tập lệnh thay thế là phá vỡ tập lệnh mỗi khi khóa máy chủ thay đổi (và có một số lý do tại sao đó có thể là trường hợp) mà câu trả lời bạn đề cập không giải quyết. Điều đó nói rằng, đó là một bài phê bình hợp lệ, vì vậy tôi đã cập nhật câu trả lời của mình để chỉ ra rủi ro.
cori

6
Tôi không thể tin rằng rất nhiều người đã đưa ra câu trả lời này và nó cũng được người hỏi chấp nhận. Cách tiếp cận này bỏ qua kiểm tra bảo mật và kết nối nó với máy chủ từ xa. Kiểm tra xem tệp đã biết_hosts trong thư mục ~ / .ssh / có quyền ghi hay không. Nếu không, sau đó sử dụng câu trả lời stackoverflow.com/a/35045005/2809294
ARK

Miễn là bạn biết những gì bạn đang làm, đây là giải pháp tốt nhất. Tôi có một trang web nội bộ mà chúng tôi tự động kết nối với đó có NHIỀU, cập nhật (có hiệu quả ngẫu nhiên) địa chỉ IP. Tôi đã thêm nó vào ~ / .ssh / config và nó chỉ hoạt động. Nhắc bạn, tôi BIẾT rằng trang web này là những gì tôi nghĩ và nếu không, kẻ xấu không có lợi thế, vì tôi biết dữ liệu nào đang được chuyển.
user1683793

75

Câu hỏi cũ mà xứng đáng có một câu trả lời tốt hơn.

Bạn có thể ngăn lời nhắc tương tác mà không vô hiệu hóa StrictHostKeyChecking(không an toàn).

Kết hợp logic sau vào tập lệnh của bạn:

if [ -z "$(ssh-keygen -F $IP)" ]; then
  ssh-keyscan -H $IP >> ~/.ssh/known_hosts
fi

Nó kiểm tra xem khóa công khai của máy chủ có ở trong không known_hosts. Nếu không, nó yêu cầu khóa công khai từ máy chủ và thêm nó vào known_hosts.

Theo cách này, bạn chỉ tiếp xúc với cuộc tấn công Man-In-The-Middle một lần, điều này có thể được giảm nhẹ bằng cách:

  • đảm bảo rằng tập lệnh kết nối lần đầu tiên qua một kênh an toàn
  • kiểm tra nhật ký hoặc know_host để kiểm tra dấu vân tay một cách thủ công (chỉ được thực hiện một lần)

4
Hoặc chỉ cần quản lý tệp know_hosts cho tất cả các máy như là một phần của thiết lập cấu hình cơ sở hạ tầng của bạn.
Thilo

1
lưu ý rằng ssh-keyscan không hoạt động với ProxyCommand: marc.info/?l=openssh-unix-dev&m=108446567718763&w=2
Richlv

1
nó sẽ không hoạt động như mong đợi. `ssh-keygen -F $IP`nên là "`ssh-keygen -F $IP`"(trong ngoặc kép), trong trường hợp khác, nó sẽ không được hiểu là một chuỗi
avtomaton

Hoặc như một oneliner sử dụng giá trị trả về ssh-kegen:ssh-keygen -F $IP >/dev/null || ssh-keyscan -H $IP >> ~/.ssh/known_hosts
Gohu

38

Để tắt (hoặc điều khiển tắt), hãy thêm các dòng sau vào đầu /etc/ssh/ssh_config...

Host 192.168.0.*
   StrictHostKeyChecking=no
   UserKnownHostsFile=/dev/null

Tùy chọn:

  • Mạng con Máy chủ có thể *cho phép truy cập không hạn chế vào tất cả các IP.
  • Chỉnh sửa /etc/ssh/ssh_configcho cấu hình toàn cầu hoặc ~/.ssh/configcho cấu hình dành riêng cho người dùng.

Xem http://linuxcommando.blogspot.com/2008/10/how-to-disable-ssh-host-key-checking.html

Câu hỏi tương tự trên superuser.com - xem https://superuser.com/a/628801/55163


19

Hãy chắc chắn ~/.ssh/known_hostslà có thể ghi. Điều đó đã sửa nó cho tôi.


4
Có an toàn không khi cho phép mọi người ghi vào know_hosts?
akaRem

2
@akaRem chắc chắn là không. Thông thường bạn muốn nó chỉ có thể ghi đối với người dùng sở hữu .sshthư mục đó .
2rs2ts

quyền 0400là tối ưu (vui lòng sửa cho tôi bất cứ ai) tuy nhiên trong trường hợp của tôi, vấn đề chỉ đơn giản là .sshthư mục cho người dùng của tôi đã thay đổi quyền sở hữu - ergo làm mất hiệu lực 0400 quyền của riêng tôi. sudothay đổi quyền sở hữu trở lại với tôi giải quyết vấn đề của tôi.
Charney Kaye

Điều này đã khắc phục vấn đề cho tôi.
Sivaji

14

Cách tốt nhất để giải quyết vấn đề này là sử dụng 'BatchMode' ngoài 'StricthostKeyChecking'. Bằng cách này, tập lệnh của bạn sẽ chấp nhận tên máy chủ mới và ghi nó vào tệp được biết_hosts, nhưng sẽ không yêu cầu có / không can thiệp.

ssh -o BatchMode=yes -o StrictHostKeyChecking=no user@server.example.com "uptime"

10

Chỉnh sửa tệp cấu hình của bạn thường nằm ở '~ / .ssh / config' và tại phần cầu xin của tệp, thêm các dòng dưới đây

Host *
    User                   your_login_user
    StrictHostKeyChecking  no
    IdentityFile          ~/my_path/id_rsa.pub

Người dùng được thiết lập để your_login_usernói rằng cài đặt này thuộc về your_login_user StricthostKeyChecking
được đặt thành không sẽ tránh dấu nhắc
IdentityFile là đường dẫn đến khóa RSA

Điều này làm việc cho tôi và kịch bản của tôi, chúc may mắn cho bạn.


Cảm ơn bạn nó thực sự tiết kiệm trong ngày. Nhưng dòng cuối cùng IdentityFileđể làm gì? Nó dường như hoạt động mà không có nó ..
supersan

7

Cảnh báo này được đưa ra do các tính năng bảo mật, không vô hiệu hóa tính năng này.

Nó chỉ được hiển thị một lần.

Nếu nó vẫn xuất hiện sau kết nối thứ hai, vấn đề có thể là do ghi vào known_hoststệp. Trong trường hợp này, bạn cũng sẽ nhận được thông báo sau:

Failed to add the host to the list of known hosts 

Bạn có thể sửa nó bằng cách thay đổi chủ sở hữu thay đổi quyền của tệp để người dùng của bạn có thể ghi.

sudo chown -v $USER ~/.ssh/known_hosts

5

Với tham chiếu câu trả lời của Cori, tôi đã sửa đổi nó và sử dụng lệnh bên dưới, nó đang hoạt động. Không có exit, lệnh còn lại thực sự đăng nhập vào máy từ xa, điều mà tôi không muốn trong kịch bản

ssh -o StrictHostKeyChecking=no user@ip_of_remote_machine "exit"

5

Làm điều này -> chmod +w ~/.ssh/known_hosts. Điều này thêm quyền ghi vào tập tin tại ~/.ssh/known_hosts. Sau đó, máy chủ từ xa sẽ được thêm vào known_hoststệp khi bạn kết nối với nó vào lần tiếp theo.


4

Tốt nhất, bạn nên tạo một cơ quan chứng nhận tự quản lý. Bắt đầu với việc tạo một cặp khóa: ssh-keygen -f cert_signer

Sau đó ký tên khóa máy chủ công cộng của mỗi máy chủ: ssh-keygen -s cert_signer -I cert_signer -h -n www.example.com -V +52w /etc/ssh/ssh_host_rsa_key.pub

Điều này tạo ra một khóa máy chủ công cộng đã ký: /etc/ssh/ssh_host_rsa_key-cert.pub

Trong /etc/ssh/sshd_config, trỏ HostCertificateđến tập tin này: HostCertificate /etc/ssh/ssh_host_rsa_key-cert.pub

Khởi động lại dịch vụ sshd: service sshd restart

Sau đó, trên máy khách SSH, thêm phần sau vào ~/.ssh/known_hosts: @cert-authority *.example.com ssh-rsa AAAAB3Nz...cYwy+1Y2u/

Trên đây có chứa:

  • @cert-authority
  • Lĩnh vực *.example.com
  • Nội dung đầy đủ của khóa công khai cert_signer.pub

Khóa cert_signercông khai sẽ tin tưởng bất kỳ máy chủ nào có khóa máy chủ công cộng được ký bởi cert_signerkhóa riêng.

Mặc dù điều này yêu cầu cấu hình một lần ở phía máy khách, bạn có thể tin tưởng nhiều máy chủ, bao gồm cả những máy chủ chưa được cung cấp (miễn là bạn ký mỗi máy chủ, nghĩa là).

Để biết thêm chi tiết, xem trang wiki này .


2

Nói chung, vấn đề này xảy ra khi bạn sửa đổi các phím rất thường xuyên. Dựa trên máy chủ, có thể mất một chút thời gian để cập nhật khóa mới mà bạn đã tạo và dán trong máy chủ. Vì vậy, sau khi tạo khóa và dán trong máy chủ, hãy đợi 3 đến 4 giờ rồi thử. Vấn đề cần được giải quyết. Nó đã xảy ra với tôi.



0

Chạy cái này trong máy chủ là vấn đề linh cảm

chmod -R 700 ~/.ssh

bạn đang yêu cầu mọi người thay đổi quyền trên ủy quyền và khóa công khai từ 644 thành 700? Và khóa riêng từ 600 đến 700?
Nurettin

0

Tôi có cùng một lỗi và muốn thu hút sự chú ý đến thực tế rằng - như nó vừa xảy ra với tôi - bạn có thể có những đặc quyền sai.
Bạn đã thiết lập .sshthư mục của mình là rootngười dùng thông thường hoặc người dùng và do đó bạn cần phải là người dùng chính xác. Khi lỗi này xuất hiện, tôi đã rootnhưng tôi đã cấu hình .sshnhư người dùng thông thường. Đã thoát rootcố định nó.


-3

Tôi giải quyết vấn đề gây ra lỗi bằng văn bản bên dưới:
Lỗi:
Tính xác thực của máy chủ 'XXX.XXX.XXX' không thể được thiết lập.
Dấu vân tay của khóa RSA là 09: 6c: ef: cd: 55: c4: 4f: ss: 5a: 88: 46: 0a: a9: 27: 83: 89.

Giải pháp:
1. cài đặt bất kỳ công cụ openSSH.
2. chạy lệnh ssh
3. nó sẽ yêu cầu bạn thêm máy chủ này như thế nào. chấp nhận CÓ.
4. Máy chủ này sẽ thêm vào danh sách máy chủ đã biết.
5. Bây giờ bạn có thể kết nối với máy chủ này.

Giải pháp này hiện đang hoạt động ......


Điều này không trả lời câu hỏi. Câu hỏi ban đầu (rất cũ) là về khả năng tự động xác nhận các lời nhắc đó thông qua tập lệnh.
MasterAM

Nếu nó làm việc cho anh ta có lẽ nó làm việc cho người khác. Không cần phải đánh giá thấp thứ gì đó thực sự hữu ích
Mbotet

chạy "ssh" không hoạt động. Nó đang hiển thị cho các tùy chọn sử dụng: ssh [..] [..] [..] [user @] hostname [lệnh]
P Satish Patro
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.