SCP'ye izin ver ancak SSH kullanarak gerçek giriş yapmama

Linux kutusundaki bir kullanıcıyı (bu durumda Centos 5.2) yapılandırmak için herhangi bir yol var mı, böylece dosyaları almak için scp kullanabilirler, ancak SSH kullanarak sunucuya giriş yapamazlar mı?

rssh kabuğu ( http://pizzashack.org/rssh/ ) tam olarak bu amaç için tasarlanmıştır.

RHEL / CentOS 5.2 rssh için bir paket içermediğinden, burada bir RPM elde etmek için bakabilirsiniz: http://dag.wieers.com/rpm/packages/rssh/

Kullanmak için, sadece bunun gibi yeni bir kullanıcı için bir kabuk olarak ayarlayın:

useradd -m -d /home/scpuser1 -s /usr/bin/rssh scpuser1
passwd scpuser1

..veya bunun gibi bir tane için kabuğu değiştirin:

chsh -s /usr/bin/rssh scpuser1

.. ve /etc/rssh.confrssh kabuğunu yapılandırmak için düzenleme yapın - özellikle allowscptüm rssh kullanıcıları için SCP erişimini etkinleştirmek için uncomment satırı.

(Kullanıcıları evlerinde bulundurmak için chroot kullanmak isteyebilirsiniz, ancak bu başka bir hikaye.)

Buna çok geç kaldım ancak ssh anahtarlarını kullanabilir ve ~ / .ssh / approved_keys dosyasında izin verilen tam komutu belirleyebilirsiniz.

bağlantı noktası iletme, no-pty, command = "scp kaynak hedefi" ssh-dss ...

Doğru komut ayarlarını yapmak için ps üzerinde hedefe gitmeniz gerekebilir.

Not: "-v" ile bir test scp komutu çalıştırırsanız, bunun gibi bir şey görebilirsiniz.

debug1: Sending command: scp -v -t myfile.txt

"-T" nin, program tarafından uzak uçta kullanılan belgesiz bir scp seçeneği olduğunu not edeceksiniz. Bu, size hangi yetkililerin içine girmeniz gerektiğinin fikrini verir.

EDIT: Bu StackOverflow sorusunda daha fazla bilgi bulabilirsiniz (birkaç bağlantı ile) .

İşte backup_usersunucu tarafında adlandırılmış bir kullanıcı için bunun çalışan bir örneği .

~backup_user/.ssh/authorized_keys Sunucu tarafında içerik (daha fazla güvenlik kısıtlamasıyla):

no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty,command="scp -v -r -d -t ~/CONTENT" ssh-rsa AAAAMYRSAKEY...

~ Backup_user / 'da, içeriğin erişilebilir olması gereken dizine bağlanan bir bağlantı oluşturun.

$ ln -s /path/to/directory/with/accessible/content ~backup_user/CONTENT

Şimdi, müşteri tarafında, aşağıdaki komut çalışmalıdır:

scp -v  -r  -P 2222 -i .ssh/id_rsa_key_file path/to/data backup_user@SERVER:~/CONTENT

Bu komut ne yapar:

• Ayrıntılı bilgileri görüntüler ( isteğe bağlı : -vhem komuttan hem de yetkili_keys dosyasını kaldırabilirsiniz )
• Bu / to / data yolunun içeriğini yinelemeli olarak kopyalar. ( isteğe bağlı : -rözyinelemeli bir kopya yapmak istemiyorsanız, hem komut hem de yetkili_ anahtarlar dosyasından kaldırabilirsiniz )
• Sunucuya bağlanmak için 2222 numaralı bağlantı noktasını kullanır ( isteğe bağlı : -P 2222komuttan kaldırabilirsiniz )
• Bağlantıyı otomatikleştirmek için kullanır ve kimlik dosyasını kullanır ( isteğe bağlı : kaldırabilirsiniz).-i .ssh/id_rsa_key_file
• İçeriği path/to/datakopyalanacak/path/to/directory/with/accessible/content/

Bir dosyanın (veya birkaçının) sunucudan istemciye bir kopyasını çıkarmak için, burada açıklanan şekilde işleyen bir kabuk betiği oluşturmanız gerekir.

Partiye biraz geç kaldım, ancak ForceCommandOpenSSH direktifine bir göz atmanızı öneririm .

Subsystem sftp internal-sftp

Match group sftponly
         ForceCommand internal-sftp

Verilen, bu SFTP'dir ve SCP değildir, ancak aynı amaca, sınırlı bir kabuktan daha güvenli bir şekilde ulaşır. Ek olarak, isterseniz kullanıcıyı chroot edebilirsiniz.

Scponly kullanmanızı tavsiye ederim.

Kullanıcıların, sunucuya SCP dosyaları gibi seslerini çıkardıklarını, ancak gerçekte giriş yapmadıklarını, ancak giriş yapmalarını sağlayan sınırlı bir kabuktur. Yazılım için bilgi ve kaynak kodu indirmeleri burada mevcuttur ve önceden derlenmiş RPM paketleri EPEL YUM Depoları .

Kurulduktan sonra, yeni kurulan kısıtlanmış kabuğu kullanmak için erişimi sınırlandırmak istediğiniz her kullanıcı hesabını yapılandırmanız gerekir. Bunu / etc / passwd üzerinden manuel olarak yapabilir veya aşağıdaki komutu kullanabilirsiniz: usermod -s /usr/bin/scponly USERNAME

Bunu yapmak için MySecureShell kullanıyorum. Diğer kısıtlamaları da yapılandırabilirsiniz.

https://github.com/mysecureshell/mysecureshell

Bağlantıları yalnızca SFTP / SCP ile sınırlandırır. Kabuk erişimi yok.

Partiye çok geç kaldık, ancak sadece git kullanıcısının kabuklarını / usr / bin / git-shell olarak ayarlayın. Etkileşimli oturum açmaya izin vermeyen kısıtlı bir kabuktur. Kullanıcıya 'su -s / bin / bash git' ya da git kullanıcı adınız ne olursa olsun hala dava açabilirsiniz.

Yalnızca dosyaları kopyalayabilmek, ancak giriş yapmamak istediğimiz kullanıcılar için güvenli ftp sunucularımızda scponly adı verilen psudo kabuğu kullanıyoruz .

Office_keys dosyasının command = "..." özelliğini kullanmanın iyi bir yolunu buldum. ( Bu sayfa bana önerildi )

Çalıştırdığınız komut, scp (ve rsync) ile başlayan değişkenleri test eden komut olacaktır.

Yetkili_keyler dosyası:

# authorized_keys
command="/usr/local/bin/remote-cmd.sh" ssh-rsa.....== user@pewpew

Remote-cmd.sh dosyasının içeriği:

#!/bin/bash
# /usr/local/bin/remote-cmd.sh
case $SSH_ORIGINAL_COMMAND in
 'scp'*)
    $SSH_ORIGINAL_COMMAND
    ;;
 'rsync'*)
    $SSH_ORIGINAL_COMMAND
    ;;
 *)
    echo "Access Denied"
    ;;
esac

Sanırım kullanıcının yetkilisini_keys dosyasını yine de korumanız gerekecek, fakat amacım yepyeni bir kullanıcı oluşturmak zorunda kalmadan, yedeklemeler için kullanabileceğim bir şifre içermeyen bir anahtara sahip olmak ve anahtarın bir kabuk vermemesiydi. (tamam, kolayca)

Kullanıcının giriş kabuğunu kısıtlayıcı bir şeyle değiştirin; kullanıcının yalnızca scp , sftp-server ve rsync çalıştırmasına izin verir ve ayrıca güvenli olmayan argümanlara izin verilmediğini de kontrol eder (örneğin, scp -S ... ve rsync -e .. . güvensiz, buraya bakın: http://exploit-db.com/exploits/24795 ). Bu tür kısıtlayıcı giriş kabuğu için örnek:

• rssh
• scponly (sadece scp değil, sftp, svn vb.
• transfer_shell

Bunlardan birini chroot veya başka bir sınırlı ortamda (örneğin Linux'ta nsjail ) çalıştırmak, ağ erişimini devre dışı bırakmak ve hangi dizinlerin okunabileceğini ve / veya yazılabileceğini daha kolay (beyaz listeye alınmış) kontrol etmek isteyebilirsiniz.

Ben kullanmayı önermiyoruz command="..."içinde ~/.ssh/authorized_keysçünkü (örneğin dikkatli ek koruma olmadan, chmod -R u-w ~kötü niyetli bir kullanıcı yeni bir sürümünü yükleyebilir kullanıcı için) ~/.ssh/authorized_keys, ~/.ssh/rcya da ~/.bashrcdahildir ve istenilen komutları yürütebilirsiniz böylece, vb.

Bu en zarif çözüm değil, ama bunun gibi bir şeyi kullanıcılara atabilirsiniz.

if [ "$TERM"  != "dumb" ]; then
  exit
fi

SCP kullanıcılarının bir 'aptal' TERM'si aldıklarını ve diğerlerinin ise genellikle vt100 alacağını buldum.

Kullanıcının büyük olasılıkla yeni bir .bashrc'yi tarayabileceğini ve bunun en iyi çözüm olmadığını, hızlı ve kirli bir çözüm için işe yarayacağını hayal ediyorum.