Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

Improve host key verification

Đang mở
  • Có gì không ổn?
#65 0 bình luận 0 reaction 0 người được giao Xem trên GitHub

Chưa có ai nhận issue này.

Đánh giá

Độ khó
4/5
Thời gian dự kiến
3-5 ngày
Mức phù hợp với người mới
35/100
Loại issue
Tính năng
Độ rõ ràng
Khá rõ ràng
Mức độ hoạt động
Đình trệ
Công nghệ
go
Lĩnh vực
security

Hướng nghiên cứu

Bắt đầu bằng cách lần theo MakeConfig đến crypto/ssh ClientConfig và xem xét cách việc xác minh fingerprint được kết nối với host-key callback. So sánh các tùy chọn cấu hình HostKeyAlgorithms hiện có và các tùy chọn callback FixedHostKey; hoàn tất có nghĩa là các bên gọi có thể giới hạn việc lựa chọn host key hoặc xác minh khóa công khai đầy đủ mà không cần thay đổi các giá trị mặc định.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

Currently host key verification is done by checking if the host key fingerprint matches the expected one. This has a flaw in that it assumes that the server host key type will always be the one we are expecting. Servers can have multiple different host keys of different types. The host key selection is done based on the SSH protocol specification, from RFC4253 section 7.1:

      server_host_key_algorithms
         A name-list of the algorithms supported for the server host
         key.  The server lists the algorithms for which it has host
         keys; the client lists the algorithms that it is willing to
         accept.  There MAY be multiple host keys for a host, possibly
         with different algorithms.

         Some host keys may not support both signatures and encryption
         (this can be determined from the algorithm), and thus not all
         host keys are valid for all key exchange methods.

         Algorithm selection depends on whether the chosen key exchange
         algorithm requires a signature or an encryption-capable host
         key.  It MUST be possible to determine this from the public key
         algorithm name.  The first algorithm on the client's name-list
         that satisfies the requirements and is also supported by the
         server MUST be chosen.  If there is no such algorithm, both
         sides MUST disconnect.

This means that the client can choose which host key will be selected based on the sorted list of host key algorithms it sends to the server. This is also described here: https://www.bitvise.com/ssh-server-guide-host-keys

crypto/ssh has a way to set this list in ClientConfig:

	// HostKeyAlgorithms lists the key types that the client will
	// accept from the server as host key, in order of
	// preference. If empty, a reasonable default is used. Any
	// string returned from PublicKey.Type method may be used, or
	// any of the CertAlgoXxxx and KeyAlgoXxxx constants.
	HostKeyAlgorithms []string

easyssh doesn't set this list so it relies on crypto/ssh defaults which may change in the future. This means a crypto/ssh version update may break existing programs that use easyssh with fingerprint verification.

An easy improvement would be to allow specifying this list via MakeConfig. "Any string returned from PublicKey.Type method may be used", these are probably constant. Thus the host key type would always be guaranteed to match the key fingerprint.

Another improvement would be to be able to use func FixedHostKey as HostKeyCallback to allow specifying the full host public key to verify, not just the fingerprint, which would also be more secure.

Ngôn ngữ chính
Go
Star
349
Fork
64
Merge trung bình
2 giờ 29 phút
Pull request đã merge (30 ngày)
2

Chuẩn bị môi trường

Dự án này không cung cấp dev container, Dockerfile hay hướng dẫn đóng góp, nên bạn cần tự thiết lập môi trường: hãy bắt đầu từ README và xem hướng dẫn đóng góp lần đầu của chúng tôi để biết các bước chung.

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của appleboy/easyssh-proxy

Tất cả issue của appleboy/easyssh-proxy

Issue tương tự

Thêm issue về Go

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.