Uzaktaki bir makineyi yedeklemek için bu komutu kullanıyorum. Sorun şu ki, tüm dosyaları okumak ve kopyalamak için kök haklarına ihtiyacım var. Güvenlik nedeniyle etkin bir kök kullanıcım yok ve sudoUbuntu yöntemini kullanıyorum. Bunu yapmak için biraz soğuk boruya mı ihtiyacım var?
rsync -chavzP --stats user@192.168.1.2:/ /media/backupdisk/myserverbackup/
Yanıtlar:
İlk önce sadece root hesabını kullanmanızı öneririm. Eğer böyle ayarladıysanız:
sshd_configHedef makinede ayarlarınızı yapın PermitRootLogin without-password.ssh-keygenBir SSH özel anahtarı oluşturmak için yedeği çeken makinede kullanın (yalnızca bir SSH anahtarınız yoksa). Bir şifre ayarlamayın. Google’la ilgili bir öğreticiye bunun için detaylar gerekiyorsa, bol miktarda olması gerekir./root/.ssh/id_rsa.pubYedekleme makinesinin içeriğini /root/.ssh/authorized_keyshedef makinenize ekleyin.o zaman ortaya çıkan kurulum oldukça güvenli olmalıdır.
sudoözellikle NOPASSWDyorumlarda önerildiği şekilde birleştirildiğinde, yalnızca root hesabını kullanmanın hiçbir güvenlik avantajı yoktur. Örneğin, bu öneri:
aşağıdakileri
/etc/sudoersdosyanıza ekleyin :rsyncuser ALL= NOPASSWD:/usr/bin/rsync
temelde rsyncuserzaten kök izinleri verir . Sen sor:
Çünkü @MartinvonWittich Kolay tam kök kabuğu kazanmak için
rsyncbirlikte yürütülensudo? Lütfen [m] e [ile] arasında yürüyün.
Peki, basit. Önerilen yapılandırma ile, rsyncuserşimdi rsyncbir şifre sorulmadan root olarak çalışabilir. rsyncdosyaları işlemek için çok güçlü bir araçtır, bu yüzden şimdi rsyncuserkök izinleri ile dosyaları işlemek için çok güçlü bir araç var. Bundan yararlanmanın bir yolunu bulmak sadece birkaç dakikamı aldı (Ubuntu 13.04'te test edildi, gerektirir dash, bashişe yaramadı):
martin@martin ~ % sudo rsync --perms --chmod u+s /bin/dash /bin/rootdash
martin@martin ~ % rootdash
# whoami
root
# touch /etc/evil
# tail -n1 /etc/shadow
dnsmasq:*:15942:0:99999:7:::
Gördüğünüz gibi kendime bir kök kabuğu yarattım; whoamihesabımı root olarak tanımlar, dosya oluşturabilir /etcve okuyabilirim /etc/shadow. Benim istismarım setuid bitini ikiliye koymaktıdash ; Linux'un bu ikiliyi her zaman sahibinin izinleriyle çalıştırmasına neden olur, bu durumda root.
Gerçek bir köke sahip olmak, iyi nedenlerden dolayı [tavsiye edilmez]. - redanimalwar 15 saat önce
Hayır, kök hesabın etrafında gizlice çalışmak, onu kullanmanın kesinlikle uygun olduğu durumlarda işe yaramaz. Bu, kargo kültü programlamasının sadece bir başka şeklidir - sudo-root'un arkasındaki kavramı gerçekten anlamıyorsunuz, sadece “root kötü, sudo iyi” inancını kör bir şekilde uyguladığınız için bir yerde okudunuz.
Bir yandan, sudokesinlikle iş için doğru aracın olduğu durumlar var . Örneğin, etkileşimli bir grafik Linux masaüstünde çalışırken, Ubuntu diyelim, o zaman kullanmak zorunda sudokalmanız, bazen kök erişimine ihtiyaç duyduğunuz nadir durumlarda iyidir. Ubuntu kasıtlı olarak devre dışı bırakılmış bir kök hesaba sahip ve sudokullanıcıların giriş yapmak için sadece her zaman root hesabını kullanmalarını önlemek için varsayılan olarak kullanmaya zorlar . ve bu nedenle, varsayılan olarak bir kök hesaba sahip olmamak, aptal insanların bunu yapmasını önler.
Öte yandan, otomatik bir betiğin bir şey için kök izinleri gerektiren, örneğin bir yedekleme yapmak için sizinki gibi durumlar vardır. Şimdi sudoroot hesabı etrafında çalışmak sadece anlamsız değil, aynı zamanda tehlikelidir: ilk bakışta rsyncusersıradan imtiyazsız bir hesap gibi gözüküyor. Ancak, daha önce de açıkladığım gibi, daha önce rsyncusererişim kazanmış olsaydı, bir saldırganın tam erişim hakkı kazanması çok kolay olurdu . Bu yüzden, temel olarak, artık hiç bir kök hesabına benzemeyen bir ek kök hesabınız var, ki bu iyi bir şey değil.
/root/.ssh/authorized_keys, hatta farklı evlerde birden fazla kök hesap oluşturabilir, böylece her kullanıcının kendi kabuğuna, evine ve başkalarına sahip olabilir .ssh/authorized_keys:)
sshdgenel olarak gelmez değil anahtar bir hesaba bağlanmak için kullanılan yetkili olan giriş yaptığınız olarak bağlarsanız bobo zaman sudo, size giriş bağlamanız durumunda daha iyi bir denetim izi olsun rootdoğrudan bob'ın tuşu.
--rsync-pathRemote rsynckomutu sudoayrıcalıklarla çalıştırmak için bu seçeneği kullanın . Öyleyse emriniz, örneğin:
rsync -chavzP --rsync-path="sudo rsync" --stats user@192.168.1.2:/ .
Sizden sudobir şifre NOPASSWDisterse, uzak kullanıcı hesabına bir ayrıcalık kullanarak (root için anlamsız, diğer kullanım durumlarında anlam ifade edebilir) veya bunu yapmak istemiyorsanız, bundan kaçınmanız gerekir.
Kullandığınız tty_ticketskullanıcı için, örneğin çalıştırıp sudo visudo -f /etc/sudoers.d/local-rsync
girerek seçeneğin devre dışı bırakıldığından emin olun :
Defaults:your.username.for.rsync !tty_tickets
Kullandığınız requirettykullanıcı için seçeneğin devre dışı bırakıldığından emin olun - varsayılan olarak kapalı olabilir. Yöntem yukarıdaki ile aynıdır.
Tohum sudoörneğin çalıştırarak, uzaktan makinede şifreyi
ssh -t user@192.168.1.2 sudo
sudoşifre, şifre değil büyük olasılıkla sshşifredir
sudo /usr/bin/rsyncbir şifre sormadan kullanıcıya izin verir ; man sudoersbunun nasıl yapılacağını kontrol edin ; bunun için fazladan bir yedekleme kullanıcısı oluşturmak isteyebilirsiniz.
sudo /usr/bin/rsyncŞifre gerektirmeden çalışmasına izin vermek için /etc/sudoersdosyanızı aşağıdakilere ekleyin : rsyncuser ALL= NOPASSWD:/usr/bin/rsyncBu, kullanıcı adının bulunduğu rsyncuser kullanıcısına izin verir (yukarıda belirtildiği gibi özel bir yedekleme kullanıcısı oluşturmak en iyisidir).
rsyncher zaman temel olarak kök izinlerine sahip; Bu hesapta tam bir kök kabuğu elde etmek muhtemelen çok kolaydır. Bence ilk önce gerçek kök hesabı kullanmak daha iyi.
echo "password" | somethingaslında bunu hiç kullanmadım ve rsync'in (burada da önerilmemiştir) aniden infaz edilmesine izin vermenin getirdiği güvenlik sorunlarına katılıyorum. Ne tty_ticketsAslında hiçbir fikrim var, gerekli görünüyor ve bir güvenlik sorunu. Bu sadece ssh üzerinde sodo çalıştırarak ve sonra da komutu doğru çalıştırarak hiçbir şey tweak olmadan güvenli bir şekilde çalışırdı? Ancak bu senaryoyu kodlama amaçları için sorduğumdan, pw'siz anahtar tabanlı ssh'nin güvenli ve doğru yapmak olduğuna tamamen katılıyorum. Bunun yerine Martins cevabını kabul ettim.
Bunu yapmanın basit bir yolu, grafiksel ssh-askpassprogramın kullanılmasıdır; sudobu sudo, terminale bağlı olmayan bir gerçeği ortaya çıkarır ve şifreyi güvenli bir şekilde girmenize izin verir:
rsync -chavzPe 'ssh -X' --stats \
--rsync-path='SUDO_ASKPASS=/usr/lib/ssh/x11-ssh-askpass sudo -A rsync' \
user@192.168.1.2:/ .
Elbette ssh-askpassprogram verilen yere kurulmalı ve üzerinde çalıştığınız makinede bir X oturumu çalıştırıyor olmalısınız. ssh-askpassProgramda da çalışması gereken birkaç değişiklik var (Gnome / KDE versiyonları). Ayrıca bir grafik sudodeğiştirme programı gibi gksuya kdesudoda çalışması gerekir.
rsync --rsh='ssh -X' --rsync-path='gksudo -- rsync' user@host:/ .çalışmıyor rsync error: syntax or usage error (code 1) at main.c(1634) [server=3.1.1]. Oh, Ubuntu gnome-ssh-askpass gemisini kullanıyor, ama onun /usr/bin/ssh-askpassyerine /usr/lib/ssh/x11.... Öyleyse işe yaradı :)
ssh-askpass. Sadece anlamını aramak zorunda kaldım -chavzPe, bunları uzun seçenekler olarak dile getirmek harika olurdu.
xeyesSSH kullanarak çalıştırarak doğruladığım, beklenen bir çalışma .
Eğer kullanıcı zaten bir parola ile korunmuş sudo ayrıcalıklarına sahipse, onları olduğu gibi tutacağım ve sadece parola olmadan rsync kullanmak için bir stanza ekleyeceğim:
%admin ALL=(ALL) ALL
%admin ALL= NOPASSWD:/usr/bin/rsync
Bugün bu soruna rastladım ve yapılandırma dosyalarını değiştirmeden veya kullanıcı hesaplarına kök düzeyinde izinler vermeden bu sorunu çözdüm. Özel kurulumum A, makinedeki kullanıcının , footüm kullanıcı dizinlerini foomakineye , kullanıcının sahip olduğu barbir backupdizinde kopyalaması gerektiğiydi A. (Kullanıcının Aüzerinde sudo ayrıcalıkları var foo.)
Kullandığım komut aşağıda. Bu kullanıcı tarafından başlatıldığı Aiçinde /homedizine foo.
sudo rsync -avu -e "ssh -i /home/A/.ssh/id_rsa -l A" * B:/home/backup
Bu, rsync komutunu sudo olarak çalıştırır, böylece açık olan tüm kullanıcı dizinlerine fooerişilebilir, ancak barkullanıcının Akimlik bilgilerini kullanarak makineye erişmek için ssh kullanmasını söyler . İhtiyaçlarım yukarıdaki sorudan biraz farklıydı ancak bu, sistem konfigürasyonuna uymadan yönettiğim belirli bir makinedeki tüm kullanıcı dizinlerini hızlıca yedeklememe izin verdi.
-iseçeneği için unuttum ssh. --rsync-path="sudo /usr/bin/rsync" Makinede sudo varsa kullanabilirsiniz bar. Bu daha sonra okuma root@foove yazma yapar root@bar, ancak A@foo-> ile aktarma yapar B@bar. Teşekkürler!
Hedef makinede rsync'i daemon olarak çalıştırmak, istediğiniz şeyi yapmanıza olanak sağlar.
Benim çözümüm kullanmaktır, --rsync-path="sudo rsync"ancak geçici çözüm için parola ister:
rsync -chavzP --stats --rsync-path="echo <SUDOPASS> | sudo -Sv && sudo rsync" user@192.168.1.2:/ .
$( cat my_password.txt )biraz daha iyi olan bu tür bir ifadede değiştiririm , ancak genellikle her iki uçtaki izinleri yapılandırmak ve / veya SSH anahtarlarını kullanmak, şifreleri CLI'da gerekmeyecek şekilde kullanmak tercih edilir.
rootilk önce hesabı kullanın .sudoözellikleNOPASSWDyorumlarda önerildiği şekilde bir araya geldiğinde, makinenizin güvenliğini gerçekten iyileştirmiyor.