Quy trình làm việc trơn tru nhất để xử lý lỗi xác minh máy chủ SSH?

Đây là một vấn đề đơn giản mà tất cả chúng ta phải đối mặt và có thể giải quyết bằng tay mà không cần suy nghĩ nhiều.

Khi máy chủ thay đổi, được cung cấp lại hoặc địa chỉ IP được phân bổ lại, chúng tôi sẽ nhận được thông báo xác minh máy chủ SSH bên dưới. Tôi quan tâm đến việc hợp lý hóa quy trình làm việc để giải quyết các lỗi nhận dạng ssh này.

Đưa ra thông báo sau, tôi thường vi /root/.ssh/known_hosts +434và xóa ( dd) dòng vi phạm.

Tôi đã thấy các nhà phát triển / người dùng trong các tổ chức khác xóa toàn bộ known_hosts tệp của họ vì thất vọng khi thấy thông báo này. Trong khi tôi không đi xa đến thế, tôi biết có một cách thanh lịch hơn để xử lý việc này.

Lời khuyên?

[root@xt ~]# ssh las-db1

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that the RSA host key has just been changed.
The fingerprint for the RSA key sent by the remote host is
ed:86:a2:c4:cd:9b:c5:7a:b1:2b:cc:42:15:76:8c:56.
Please contact your system administrator.
Add correct host key in /root/.ssh/known_hosts to get rid of this message.
Offending key in /root/.ssh/known_hosts:434
RSA host key for las-db1 has changed and you have requested strict checking.
Host key verification failed.

Bạn có thể sử dụng ssh-keygenlệnh để xóa các mục cụ thể theo máy chủ:

ssh-keygen -R las-db1

Nếu bạn không có lệnh đó, bạn luôn có thể sử dụng sed:

sed -i '/las-db1/d' /root/.ssh/known_hosts

Là một người dùng bù nhìn, phương pháp để giải quyết vấn đề này là thực sự để máy chủ con rối của tôi thu thập các khóa máy chủ SSH của tôi và xuất bản chúng cho tất cả các hệ thống của tôi tạo kết nối SSH.

Bằng cách này, tôi không phải lo lắng về việc loại bỏ chúng. Chín mươi chín phần trăm thời gian con rối đã chạy và cập nhật các khóa cho tôi vì tôi có các đặc vụ của mình chạy cứ sau ba mươi phút. Các trường hợp ngoại lệ đối với tôi là rất hiếm, và vì vậy tôi không ngại chỉnh sửa nhanh hệ thống được biết đến trên toàn hệ thống nếu tôi không sẵn sàng chờ đợi.

class ssh::hostkeys {

  @@sshkey { "${::clientcert}_rsa":
    type => rsa,
    key => $sshrsakey,
    tag => 'rsa_key',
  }

  if 'true' == $common::params::sshclient {
    Sshkey <<| tag == 'rsa_key' |>> {
      ensure => present
    }
  }

  file {'/etc/ssh/ssh_known_hosts':
    ensure => present,
    owner => 'root',
    group => 'root',
    mode => 0644,
  }

}

Tôi muốn thêm một đề nghị có thể giúp bạn trong những trường hợp rất cụ thể mà an ninh ít được quan tâm.

Tôi có một môi trường phòng thí nghiệm với các máy được cài đặt lại thường xuyên. Mỗi khi điều đó xảy ra, các khóa máy chủ mới sẽ được tạo (tôi có thể lưu khóa máy chủ ở đâu đó và đặt nó trong tập lệnh sau khi cài đặt).

Vì bảo mật không phải là vấn đề đối với tôi trong môi trường phòng thí nghiệm này và các khóa thay đổi thường xuyên, nên tôi có các phần sau trong tệp .ssh / config của mình:

Host lab-*
  User kenny
  IdentityFile ~/.ssh/lab_id_rsa
  StrictHostKeyChecking no
  UserKnownHostsFile=/dev/null

Điều này đảm bảo rằng việc kết nối với các máy thí nghiệm của tôi sẽ không bao giờ gây ra lỗi đó nữa và máy khách ssh của tôi sẽ chỉ kết nối mà không kiểm tra khóa máy chủ.

Đây là điều bạn chỉ nên làm nếu an ninh không liên quan gì đến bạn, bởi vì điều này đặt bạn vào vị trí dễ bị tấn công trong một cuộc tấn công trung gian.

Theo ghi chú phát hành openssh 5.6 , bạn không cần phải sử dụng khóa máy chủ nữa:

Xác thực lưu trữ hiện có thể sử dụng khóa máy chủ chứng chỉ. Các khóa CA phải được chỉ định trong tệp đã biết bằng cách sử dụng dấu @ cert-thẩm quyền như được mô tả trong sshd (8).

Cảnh báo : Tôi chưa bao giờ nghe thấy bất cứ ai sử dụng tính năng này trong sản xuất cho đến nay. Sử dụng có nguy cơ của riêng bạn (nhưng tôi tin rằng các nhà phát triển openssh đủ hoang tưởng để không phát hành một tính năng giết người như vậy mà không có nhiều thử nghiệm và kiểm tra mã).

SSHFP DNS ResourceRecord có thể giúp tùy thuộc vào mức độ khách hàng ssh của bạn tận dụng lợi thế của nó. Lưu trữ tất cả dấu vân tay khóa công khai ssh của bạn trên đó với tên máy chủ.

Triển khai DNSSEC hoặc DNS qua SSL trước đó.
http://www.ietf.org/rfc/rfc4255.txt

FreeIPA.org xử lý quản lý khóa máy chủ và người dùng cũng như Chứng chỉ PKI. Nó cũng tự động tải lên các bản ghi DNS SSHFP khi các khóa mới được tạo.

Daemon Dịch vụ bảo mật hệ thống (SSSD) có thể được cấu hình để lưu trữ và truy xuất các khóa SSH của máy chủ để các ứng dụng và dịch vụ chỉ phải tìm ở một vị trí cho các khóa máy chủ. Vì SSSD có thể sử dụng FreeIPA làm một trong những nhà cung cấp thông tin nhận dạng của mình, FreeIPA cung cấp kho lưu trữ khóa phổ biến và tập trung. Quản trị viên không cần phải lo lắng về việc phân phối, cập nhật hoặc xác minh khóa SSH của máy chủ.

http://docs.fedoraproject.org/en-US/Fedora/17/html/FreeIPA_Guide/host-keys.html