SSH không cho phép sử dụng khóa có quyền đọc được theo nhóm


9

Tôi có một máy chủ git phát triển triển khai đến một máy chủ trực tiếp khi livechi nhánh được đẩy tới. Mỗi người dùng có thông tin đăng nhập riêng của họ và do đó, post-receivehook mà việc triển khai trực tiếp được chạy dưới chính người dùng của họ.

Vì tôi không muốn duy trì khóa công khai của người dùng dưới dạng khóa được ủy quyền trên máy chủ trực tiếp từ xa, tôi đã tạo một bộ khóa thuộc hệ thống git để thêm vào máy chủ trực tiếp từ xa (Trong post-receivehook tôi đang sử dụng $GIT_SSHđể đặt khóa riêng với -itùy chọn).


Vấn đề của tôi là bởi vì tất cả người dùng có thể muốn triển khai để tồn tại, khóa riêng của hệ thống git phải có ít nhất là nhóm có thể đọc được và SSH thực sự không thích điều này.

Đây là một mẫu lỗi:

XXXX@XXXX /srv/git/identity % ssh -i id_rsa XXXXX@XXXXX
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@         WARNING: UNPROTECTED PRIVATE KEY FILE!          @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Permissions 0640 for 'id_rsa' are too open.
It is required that your private key files are NOT accessible by others.
This private key will be ignored.
bad permissions: ignore key: id_rsa

Tôi đã nhìn xung quanh để mong tìm thấy thứ gì đó theo cách buộc ssh chỉ đi qua kết nối nhưng tôi không tìm thấy gì ngoài việc mọi người nói một cách mù quáng rằng bạn chỉ không nên cho phép truy cập vào bất cứ thứ gì ngoại trừ một người dùng.

Câu trả lời:


5

Đây là một cách đơn giản và an toàn.

Tạo người dùng mới để chuyển ssh, tôi sẽ gọi nó là git-sync. Tạo một người dùng tương tự trên máy chủ với tư cách thành viên nhóm cho kho git. Thêm khóa chung cho người dùng đồng bộ hóa vào tệp ủy quyền của người dùng đó. Tôi cho rằng người dùng git đều là thành viên của nhóm git. Đảm bảo người dùng đồng bộ git cũng là thành viên của nhóm này.

Bây giờ chỉnh sửa tệp / etc / sudoers của bạn để bao gồm một dòng như:

%gitgroup ALL=(git-sync) NOPASSWD: /usr/bin/git

Điều này sẽ cho phép bất kỳ thành viên nào trong nhóm gitgroup chạy lệnh / usr / bin / bit dưới dạng git-sync mà không cần mật khẩu.

Bây giờ đặt một cái gì đó như thế này trong hook sau nhận của bạn:

sudo -u git-sync /usr/bin/git push origin

Điều này tốt hơn những gì tôi đang tìm kiếm, cảm ơn!
Jessie Ross

11

Bạn CÓ THỂ sử dụng các tệp nhận dạng nhóm có thể đọc được, KHÔNG GIỚI HẠN bạn là chủ sở hữu của khóa. Vì vậy, chỉ cần đặt tệp nhận dạng được sở hữu, ví dụ: người dùng root và sau đó tất cả người dùng kho git của bạn sẽ được đặt.

Một lợi ích tốt cho việc này là bạn không cần sudo - giải pháp sẽ đơn giản hơn.

Lưu ý rằng điều này sẽ gặp lại vấn đề ban đầu nếu bạn đang sử dụng root để chuyển sang repo git của mình.


2
Điều này thật tuyệt vời và tốt hơn nhiều so với câu trả lời "đừng làm vậy". Cảm ơn!
Ian McGowan

2
Permissions 0640 for 'id_rsa' are too open.

Khóa riêng phải được giữ riêng tư. Bạn không nên cho phép bất cứ ai đọc nó.

Vì tôi không muốn duy trì khóa công khai của người dùng dưới dạng khóa được ủy quyền trên máy chủ trực tiếp từ xa, tôi đã tạo một bộ khóa thuộc hệ thống git để thêm vào máy chủ trực tiếp từ xa (Trong post-receivehook tôi đang sử dụng $GIT_SSHđể đặt khóa riêng với -itùy chọn).

  1. thiết lập một cặp khóa để ssh từ nhà phát triển đến máy chủ sản xuất
  2. trong post-receivetập lệnh hook, hãy thử một cái gì đó như thế này:

    if [ "live" == "$branch" ]; then
        ssh -t user@prod "git --work-tree=... --git-dir=... checkout -f"
    fi
    

Làm cách nào tôi có thể "thiết lập một cặp khóa để ssh từ nhà phát triển đến máy chủ sản xuất", đây là điều tôi đang gặp vấn đề. Tôi đã có 2 tại chỗ.
Jessie Ross

1
Trên dev: ssh-keygen, ssh-copy-id user@prod. Trên prod: chmod 700 ~/.ssh, chmod 600 ~/.ssh/authorized_keys.
lượng tử

1
Vấn đề là có nhiều người dùng, do đó tôi phải nhắc lại rằng với mọi người dùng muốn chỉnh sửa thời gian bởi mọi dự án tồn tại trên máy chủ.
Jessie Ross

Không. Bạn chỉ cần thiết lập thêm hai người dùng: một đến ssh từ dev đến prod và một người khác để chạy git checkout...(trên prod).
lượng tử

Các post-receivemóc (dev máy) được điều hành bởi người sử dụng mà đang thúc đẩy một sự thay đổi (do đó dưới sự cho phép người dùng) vì vậy tất cả họ sẽ có các phím khác nhau, tôi không thể giúp đỡ mà người dùng nó sẽ được. Có hai post-receivehook trên hai máy chủ khác nhau đang hoạt động.
Jessie Ross
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.