ssh-agent yönlendirme ve başka bir kullanıcıya sudo

Eğer ssh anahtarımla giriş yapabileceğim bir A sunucusuna sahipsem ve "sudo su - otheruser" yeteneğine sahipsem, anahtar yönlendirme özelliğini kaybediyorum, çünkü env değişkenleri kaldırılmış ve soket sadece orijinal kullanıcı tarafından okunabiliyor. Anahtar iletmeyi "sudo su - otheruser" üzerinden köprüleme yapmamın bir yolu var, bu yüzden bir sunucu B'de iletilen anahtarımla (durum klonumda git klonu ve rsync) bir şeyler yapabilirim?

Düşünebilmemin tek yolu, anahtarımı diğer kullanıcı ve "ssh otheruser @ localhost" 'nin anahtarlarına eklemektir, ancak sahip olduğum her kullanıcı ve sunucu birleşimi için yapması zor.

Kısacası:

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

Bahsettiğiniz gibi, ortam değişkenleri sudogüvenlik nedeniyle kaldırılmıştır .

Ancak neyse ki sudooldukça yapılandırılabilir: env_keepYapılandırma seçeneği sayesinde hangi ortam değişkenlerini korumak istediğinizi tam olarak söyleyebilirsiniz /etc/sudoers.

Aracı iletme için, SSH_AUTH_SOCKortamı değişken tutmanız gerekir . Bunu yapmak için, /etc/sudoersyapılandırma dosyanızı düzenleyin (her zaman kullanıyorsanız visudo) ve env_keepseçeneği uygun kullanıcılara ayarlayın. Bu seçeneğin tüm kullanıcılar için ayarlanmasını istiyorsanız, aşağıdaki Defaultsgibi satırı kullanın :

Defaults    env_keep+=SSH_AUTH_SOCK

man sudoers daha fazla ayrıntı için.

Artık (sağlanan böyle bir şey yapmak gerekir user1'mevcuttur ler genel anahtarını ~/.ssh/authorized_keysiçinde user1@serverAve user2@serverBve serverA' nin /etc/sudoersdosya yukarıda belirtildiği gibi kurulduğundan):

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 çevreyi koruyacak
• -s bir komutu çalıştırır, varsayılan olarak bir kabuğa

Bu, orijinal anahtarlar hala yüklü olan bir kök kabuğu verecektir.

Diğer kullanıcılara$SSH_AUTH_SOCK dosyaya ve dizinine, örneğin doğru ACL'ye, onlara geçmeden önce erişmesine izin verin . Örnek varsayar Defaults:user env_keep += SSH_AUTH_SOCKiçinde /etc/sudoersana makinede:

$ 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$

Kök olmayan kullanıcılar için de daha güvenli ve çalışır ;-)

Bunun da işe yaradığını buldum.

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

Diğerlerinin de belirttiği gibi, geçiş yaptığınız kullanıcı $ SSH_AUTH_SOCK (kökten başka bir kullanıcı değil) üzerinde okuma izinlerine sahip değilse bu işe yaramaz. Bunu $ SSH_AUTH_SOCK ve izinleri almak için bulunduğu dizinde 777 ayarlayarak halledebilirsiniz.

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

Bu olsa oldukça riskli. Temel olarak, diğer tüm kullanıcılara, SSH Temsilcinizi kullanmak için sistemden izin verin (çıkış yapana kadar). Ayrıca grubu ayarlayabilir ve izinleri 770 olarak değiştirebilirsiniz; bu daha güvenli olabilir. Ancak grubu değiştirmeyi denediğimde "İşleme izin verilmedi" aldım.

Yetkili olursanız sudo su - $USER, o zaman ssh -AY $USER@localhost$ USER'ın ana dizinindeki geçerli ortak anahtarınızla, bunun yerine izin verildiğine dair iyi bir argümanınız olur . Ardından, kimlik doğrulama iletmeniz sizinle birlikte gerçekleştirilir.

Sudo kullanmak yerine her zaman aracı yönlendirme ile localhost öğesine ekleyebilirsiniz:

ssh -A otheruser@localhost

Dezavantajı, tekrar giriş yapmanız gerekmesidir, ancak eğer bir ekran / tmux sekmesinde kullanıyorsanız, bu sadece bir kerelik bir çabadır, ancak sunucudan ayrılırsanız soket tekrar kırılır . Bu nedenle, ekran / tmux oturumunuzu her zaman açık tutamazsanız ideal değildir (ancak, SSH_AUTH_SOCKeğer env var cihazınızı manüel olarak güncelleyebilirsiniz ).

Ayrıca, ssh yönlendirme kullanıldığında, root her zaman soketinize erişebilir ve ssh kimlik doğrulamanızı kullanabilir (ssh yönlendirme ile giriş yapmış olduğunuz sürece). Öyleyse köküne güvenebileceğinden emin ol.

Kullanmayın sudo su - USER, aksine sudo -i -u USER. Benim için çalışıyor!

Bununla karşılaştığım diğer cevaplardan gelen bilgileri birleştirerek:

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

Bunu beğendim çünkü sudoersdosyayı düzenlememe gerek yok .

Ubuntu 14.04 üzerinde test edildi ( aclpaketi kurmak zorunda kaldı ).

Komutunuzdan -sonra (tire) seçeneğinde bir sorun olduğunu düşünüyorum su:

sudo su - otheruser

Su man sayfasını okursanız, seçeneğin -, -l, --loginkabuk ortamını giriş kabuğu olarak başlattığını görebilirsiniz. Bu, otheruserkoştuğunuz env değişkenleri ne olursa olsun çevrede olacak su.

Basitçe söylemek gerekirse, çizgi sizin geçtiğiniz her şeyi baltalayacaktır sudo.

Bunun yerine, bu komutu denemelisiniz:

sudo -E su otheruser

@ Joao-costa'nın işaret -Eettiği gibi, koştuğunuz ortamdaki tüm değişkenleri koruyacaktır sudo. Daha sonra kısa çizgi olmadan, subu ortamı doğrudan kullanacaktır.

Maalesef başka bir kullanıcıya dava açtığınızda (hatta sudo kullanıyorsanız) yönlendirme tuşlarınızı kullanma yeteneğinizi kaybedersiniz. Bu bir güvenlik özelliğidir: Rasgele kullanıcıların ssh-ajanınıza bağlanmalarını ve anahtarlarınızı kullanmalarını istemezsiniz :)

"Ssh -Ay $ {USER} @localhost" yöntemi biraz zahmetlidir (ve David'in kırılmaya yatkın cevabı üzerine yaptığım yorumda da belirtildiği gibi), ancak muhtemelen yapabileceğiniz en iyisidir.