Không thêm hostkey vào know

111

Tôi muốn kết nối với máy chủ thông qua SSH nhưng tôi không muốn thêm tên máy chủ vào ~/.ssh/known_hosts.

Làm thế nào tôi có thể làm điều đó?

ssh hosts

— Albert
nguồn

99

-o "UserKnownHostsFile /dev/null"

nên làm việc.

— Albert
nguồn

3

Hoạt động như dự định, nhưng nó sẽ luôn báo cáo: "Cảnh báo: Đã thêm vĩnh viễn 'tên máy chủ, ip' (RSA) vào danh sách các máy chủ đã biết." Tôi đã biến nó đi với: 2> & 1 | grep -v "^Warning: Permanently added"

— Guillaume Boudreau

3

thêm -o "LogLevel ERROR" và nó sẽ không phàn nàn với Cảnh báo nữa

— John

1

Lưu ý: yêu cầu chặn thông báo đó "Cảnh báo: Đã thêm vĩnh viễn 'tên máy chủ, ip' (RSA) vào danh sách các máy chủ đã biết." đã được báo cáo cho các nhà bảo trì bugzilla.mindrot.org/show_bug.cgi?id=2413

— Bến nhàu

2

Đường ống grepsẽ hợp nhất thiết bị xuất chuẩn và thiết bị xuất chuẩn; tình trạng thoát cũng có thể thay đổi. Nếu sử dụng bash, sẽ tốt hơn nếu sử dụng thay thế quy trình để loại bỏ thông báo : ssh 2> >( egrep >&2 -v '^Warning: Permanently added') -o "UserKnownHostsFile /dev/null" [...]. Nó sẽ tránh đường ống và do đó thay đổi tương ứng trong xử lý trạng thái thoát.

— Alex O

1

@ John Tốt hơn là sử dụng một trong những phương pháp khác trong các nhận xét này, nếu không, bạn đang đưa ra một lỗ hổng bảo mật do khả năng che giấu các cảnh báo khác, không liên quan

— Jon Bentley

97

Nếu bạn muốn hành vi này vì bạn đang làm việc với các máy chủ đám mây (AWS EC2, Rackspace CloudServers, v.v.) hoặc bạn liên tục cung cấp hình ảnh mới trong Vagrant, bạn có thể muốn cập nhật cấu hình SSH thay vì thêm bí danh bash hoặc thêm tùy chọn trên dòng lệnh.

Xem xét thêm một cái gì đó như:

Host *.mydomain.com 
  StrictHostKeyChecking no
  UserKnownHostsFile /dev/null
  User foo
  LogLevel QUIET

Sử dụng nghiêm ngặt như regex cho máy chủ càng tốt để được an toàn.
Đặt LogLevel thành QUIET sẽ giữ Cảnh báo mà Guillaume đã đề cập không hiển thị

— cclark
nguồn

Bạn thực sự nên cố gắng không vô hiệu hóa hoàn toàn StricthostKeyChecking, vì vậy câu trả lời của cclark là một sự thỏa hiệp tuyệt vời khi làm việc với các máy chủ đám mây.

— Alex Recarey

Điều này tỏ ra rất hữu ích với tôi khi tôi đang sử dụng Shipit (một công cụ triển khai JavaScript) chống lại Vagrant. Tôi không thể dễ dàng nhận được các thông số mà Shipit đã chuyển sang SSH vì vậy điều này cho phép tôi vượt qua công cụ và nói với nó những gì tôi đã làm và không muốn nó nhớ.

— John Munsch

1

LogLevel là những gì tôi đang tìm kiếm. Nó có thêm lợi thế là không hiển thị thông báo được cấu hình của công ty khi chạy tập lệnh! (Tôi hiện đang chạy w / loglevel ERROR)

— Anshu Prateek

Trong tập tin nào tôi thêm cái này?

— Wim Deblauwe

Đây là tập tin cấu hình SSH của bạn. Trong Linux hoặc macOS, tệp thường nằm trong một thư mục có tên .ssh trong thư mục chính của bạn và có tên config - ~ / .ssh / config

— cclark

8

Tôi cảm thấy muốn thêm khóa máy chủ vào know_hosts của mình (những người chạy các dịch vụ này, theo kinh nghiệm của tôi, ít nhất là đủ thông minh để giữ các khóa máy chủ của họ nhất quán giữa các máy phục vụ cùng tên máy chủ) và sau đó bật StricthostKeyChecking, tắt CheckhostIP và tắt đăng nhập bằng LogLevel ERROR sẽ cho bạn trải nghiệm tốt nhất mà không mất bảo mật. (Ok, không có CheckhostIP, bạn cần phải tin tưởng DNS, đây là một lỗ hổng lớn mà không có DNSSEC rộng rãi hoặc một cái gì đó tương tự; nhưng chúng ta sẽ chỉ quét nó dưới tấm thảm ngay bây giờ.)

Tôi sử dụng tệp know_hosts chỉ đọc, vì vậy tôi phải làm gì đó hoặc tôi nhận được cảnh báo vô tận về việc không thể thêm các mục vào know_hosts.

Những gì tôi sử dụng:

Host github.com *.github.com
StrictHostKeyChecking yes
CheckHostIP no
LogLevel ERROR

Tôi muốn các dịch vụ này xuất bản khóa máy chủ SSH của họ trên trang web của họ thông qua HTTPS, vì vậy tôi có thể sao chép chúng một cách rõ ràng mà không phải kết nối trước và có khả năng phơi bày bản thân trước một cuộc tấn công MITM.

— Hoa hồng Kyle
nguồn

7

Đối với một phiên ssh duy nhất, sử dụng này

ssh -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null user@host

— Quanlong
nguồn

4

Điều này không có gì mới đối với câu trả lời được chấp nhận cho câu hỏi đã 5 tuổi.

— JakeGould

5

Tôi đề nghị

LogLevel ERROR

kết thúc

LogLevel QUIET

do đó bạn vẫn nhận được "Không thể giải quyết tên máy chủ" và các lỗi khác như vậy

— kiloforce
nguồn

bạn sẽ có thể tin tưởng các kết nối SSH của mình, imho. Không chỉ làm cho nó im lặng về rủi ro của bạn.

— sylvainulg

3

Phụ thuộc thực sự. Chúng tôi có các môi trường phát triển bị phá hủy mỗi tuần và được xây dựng lại, các bản ghi A của chúng vẫn giữ nguyên nhưng khóa máy chủ của chúng được tạo ra mỗi khi nó được tạo. Chúng tôi không thể duy trì các khóa máy chủ vì bản ghi A chỉ được xác định trong cơ sở dữ liệu dựa trên tên môi trường và tên môi trường có thể được loại bỏ hoặc tên mới được tạo bất cứ lúc nào, vì vậy cách giải quyết trên thực sự hữu ích.

— Alex Berry

2

Bạn đã thử vô hiệu hóa StrictHostKeyChecking? Bạn có thể làm điều đó với -otùy chọn hoặc trong tệp cấu hình ~/.ssh/config.

— jneves
nguồn

Tôi đã sử dụng nó. Nhưng nó có một hiệu ứng khác: Nó làm giảm sự nghiêm ngặt đối với việc kiểm tra khóa máy chủ. Tức là khi máy chủ không xác định, nó vẫn kết nối khi bạn tắt tùy chọn đó. Như vậy, nó vẫn cứu được chủ nhà. Nhưng tôi nghĩ rằng tôi đã tìm thấy giải pháp phù hợp (xem câu trả lời của tôi).

— Albert

0

Tôi thấy các mục .ssh / config sau đây hữu ích (LAN với DHCP và DNS):

 CheckHostIP no

 Host *.*
 CheckHostIP yes

Kết quả là tên máy cục bộ "zora" hoặc "goron" sẽ không kiểm tra đối với các địa chỉ IP được gán động, nhưng www.mycompany.com hoặc node42.planetlab.com vẫn sẽ xác nhận IP tĩnh của chúng.

— sylvainulg
nguồn

Không thêm hostkey vào know_hosts cho SSH