ssh-agent chuyển tiếp và sudo cho người dùng khác

Nếu tôi có máy chủ A để tôi có thể đăng nhập bằng khóa ssh của mình và tôi có khả năng "sudo su - otheruser", tôi sẽ mất chuyển tiếp khóa, vì các biến env bị loại bỏ và người dùng ban đầu chỉ có thể đọc được ổ cắm. Có cách nào để tôi có thể chuyển tiếp khóa chuyển tiếp thông qua "sudo su - otheruser", vì vậy tôi có thể thực hiện công cụ trên máy chủ B bằng khóa được chuyển tiếp của mình (git clone và rsync trong trường hợp của tôi)?

Cách duy nhất tôi có thể nghĩ đến là thêm khóa của mình vào ủy quyền của người dùng khác và "ssh otheruser @ localhost", nhưng đó là điều khó thực hiện đối với mọi kết hợp người dùng và máy chủ mà tôi có thể có.

Nói ngắn gọn:

$ sudo -HE ssh user@host
(success)
$ sudo -HE -u otheruser ssh user@host
Permission denied (publickey). 

Như bạn đã đề cập, các biến môi trường được loại bỏ bởi sudo, vì lý do bảo mật.

Nhưng may mắn thay sudolà khá cấu hình: bạn có thể nói chính xác biến môi trường nào bạn muốn giữ nhờ vào env_keeptùy chọn cấu hình /etc/sudoers.

Để chuyển tiếp đại lý, bạn cần giữ SSH_AUTH_SOCKbiến môi trường. Để làm như vậy, chỉ cần chỉnh sửa /etc/sudoerstệp cấu hình của bạn (luôn luôn sử dụng visudo) và đặt env_keeptùy chọn cho người dùng phù hợp. Nếu bạn muốn tùy chọn này được đặt cho tất cả người dùng, hãy sử dụng Defaultsdòng như thế này:

Defaults    env_keep+=SSH_AUTH_SOCK

man sudoers để biết thêm chi tiết.

Bây giờ bạn có thể làm một cái gì đó như thế này (với điều kiện user1của khóa công khai có mặt ở ~/.ssh/authorized_keystrong user1@serverAvà user2@serverB, và serverA's /etc/sudoerstập tin được thiết lập như đã nêu ở trên):

user1@mymachine> eval `ssh-agent`  # starts ssh-agent
user1@mymachine> ssh-add           # add user1's key to agent (requires pwd)
user1@mymachine> ssh -A serverA    # no pwd required + agent forwarding activated
user1@serverA> sudo su - user2     # sudo keeps agent forwarding active :-)
user2@serverA> ssh serverB         # goto user2@serverB w/o typing pwd again...
user2@serverB>                     # ...because forwarding still works

sudo -E -s

• -E sẽ bảo vệ môi trường
• -s chạy một lệnh, mặc định là shell

Điều này sẽ cung cấp cho bạn một vỏ gốc với các khóa gốc vẫn được tải.

Cho phép otheruser để truy cập $SSH_AUTH_SOCKtập tin và đó là thư mục, ví dụ bằng ACL đúng, trước khi chuyển sang họ. Ví dụ giả định Defaults:user env_keep += SSH_AUTH_SOCKở /etc/sudoerstrên máy chủ:

$ ssh -A user@host
user@host$ setfacl -m otheruser:x   $(dirname "$SSH_AUTH_SOCK")
user@host$ setfacl -m otheruser:rwx "$SSH_AUTH_SOCK"
user@host$ sudo su - otheruser
otheruser@host$ ssh server
otheruser@server$

An toàn hơn và cũng hoạt động cho người dùng không root ;-)

Tôi đã tìm thấy rằng điều này cũng hoạt động.

sudo su -l -c "export SSH_AUTH_SOCK=$SSH_AUTH_SOCK; bash"

Như những người khác đã lưu ý, điều này sẽ không hoạt động nếu người dùng mà bạn đang chuyển sang không có quyền đọc trên $ SSH_AUTH_SOCK (gần như bất kỳ người dùng nào ngoài root). Bạn có thể khắc phục điều này bằng cách đặt $ SSH_AUTH_SOCK và thư mục chứa trong đó để có quyền 777.

chmod 777 -R `dirname $SSH_AUTH_SOCK`
sudo su otheruser -l -c "export SSH_AUTH_SOCK=$SSH_AUTH_SOCK; bash"

Điều này là khá rủi ro mặc dù. Về cơ bản, bạn đang cấp cho mọi người dùng khác về quyền sử dụng hệ thống SSH (cho đến khi bạn đăng xuất). Bạn cũng có thể đặt nhóm và thay đổi quyền thành 770, điều này có thể an toàn hơn. Tuy nhiên, khi tôi cố gắng thay đổi nhóm, tôi đã nhận được "Hoạt động không được phép".

Nếu bạn được ủy quyền sudo su - $USER, thì có lẽ bạn sẽ có một lý lẽ tốt để được phép ssh -AY $USER@localhostthay thế, với khóa công khai hợp lệ của bạn trong thư mục chính của $ USER. Sau đó, chuyển tiếp xác thực của bạn sẽ được thực hiện với bạn.

Bạn luôn có thể chỉ ssh đến localhost với chuyển tiếp đại lý thay vì sử dụng sudo:

ssh -A otheruser@localhost

Nhược điểm là bạn cần đăng nhập lại, nhưng nếu bạn đang sử dụng nó trong tab màn hình / tmux, thì đó chỉ là một nỗ lực một lần, tuy nhiên, nếu bạn ngắt kết nối với máy chủ, tất nhiên ổ cắm sẽ bị hỏng . Vì vậy, sẽ không lý tưởng nếu bạn không thể mở phiên màn hình / tmux của mình mọi lúc (tuy nhiên, bạn có thể cập nhật thủ công SSH_AUTH_SOCKvar env của mình nếu bạn mát mẻ).

Cũng lưu ý rằng khi sử dụng chuyển tiếp ssh, root luôn có thể truy cập vào ổ cắm của bạn và sử dụng xác thực ssh của bạn (miễn là bạn đã đăng nhập bằng chuyển tiếp ssh). Vì vậy, hãy chắc chắn rằng bạn có thể tin tưởng root.

Đừng sử dụng sudo su - USER, nhưng thay vào đó sudo -i -u USER. Làm việc cho tôi!

Kết hợp thông tin từ các câu trả lời khác tôi đã đưa ra điều này:

user=app
setfacl -m $user:x $(dirname "$SSH_AUTH_SOCK")
setfacl -m $user:rwx "$SSH_AUTH_SOCK"
sudo SSH_AUTH_SOCK="$SSH_AUTH_SOCK" -u $user -i

Tôi thích điều này bởi vì tôi không cần phải chỉnh sửa sudoerstập tin.

Đã thử nghiệm trên Ubuntu 14.04 (phải cài đặt aclgói).

Tôi nghĩ rằng có một vấn đề với -tùy chọn (dấu gạch ngang) sau sutrong lệnh của bạn:

sudo su - otheruser

Nếu bạn đọc trang man của su , bạn có thể thấy rằng tùy chọn -, -l, --loginbắt đầu môi trường shell là shell đăng nhập. Đây sẽ là môi trường cho otheruserbất kể các biến env nơi bạn chạy su.

Nói một cách đơn giản, dấu gạch ngang sẽ làm suy yếu bất cứ thứ gì bạn truyền từ sudo.

Thay vào đó, bạn nên thử lệnh này:

sudo -E su otheruser

Như @ joao-costa đã chỉ ra, -Esẽ bảo toàn tất cả các biến trong môi trường nơi bạn chạy sudo. Sau đó không có dấu gạch ngang, susẽ sử dụng môi trường đó trực tiếp.

Thật không may khi bạn kiện người dùng khác (hoặc thậm chí sử dụng sudo) bạn sẽ mất khả năng sử dụng các phím được chuyển tiếp của mình. Đây là một tính năng bảo mật: Bạn không muốn người dùng ngẫu nhiên kết nối với đại lý ssh của bạn và sử dụng các khóa của bạn :)

Phương thức "ssh -Ay $ {USER} @localhost" hơi cồng kềnh (và như đã lưu ý trong nhận xét của tôi về câu trả lời của David dễ bị phá vỡ), nhưng có lẽ đó là cách tốt nhất bạn có thể làm.