Apakah ada cara untuk mengonfigurasi pengguna pada kotak Linux (Centos 5.2 dalam kasus ini) sehingga mereka dapat menggunakan scp untuk mengambil file, tetapi tidak dapat benar-benar masuk ke server menggunakan SSH?
Apakah ada cara untuk mengonfigurasi pengguna pada kotak Linux (Centos 5.2 dalam kasus ini) sehingga mereka dapat menggunakan scp untuk mengambil file, tetapi tidak dapat benar-benar masuk ke server menggunakan SSH?
Jawaban:
rssh shell ( http://pizzashack.org/rssh/ ) dirancang untuk tujuan ini.
Karena RHEL / CentOS 5.2 tidak termasuk paket untuk rssh, Anda mungkin mencari di sini untuk mendapatkan RPM: http://dag.wieers.com/rpm/packages/rssh/
Untuk menggunakannya cukup setel sebagai shell untuk pengguna baru seperti ini:
useradd -m -d /home/scpuser1 -s /usr/bin/rssh scpuser1
passwd scpuser1
..atau ganti shell untuk yang sudah ada seperti ini:
chsh -s /usr/bin/rssh scpuser1
..dan edit /etc/rssh.conf
untuk mengonfigurasi rssh shell - terutama allowscp
baris komentar untuk mengaktifkan akses SCP untuk semua pengguna rssh.
(Anda mungkin juga ingin menggunakan chroot untuk menjaga agar pengguna tetap terkandung di rumah mereka, tetapi itu adalah cerita lain.)
Saya sangat terlambat dalam hal ini, tetapi Anda dapat menggunakan kunci ssh dan menentukan perintah persis yang diizinkan dalam file ~ / .ssh / Authorized_key misalnya.
no-port-forwarding, no-pty, command = "target sumber scp" ssh-dss ...
Anda mungkin perlu menggunakan ps to pada target untuk mengatur pengaturan perintah yang benar.
PS: Jika Anda menjalankan perintah test scp dengan "-v" Anda dapat melihat sesuatu seperti ini
debug1: Sending command: scp -v -t myfile.txt
Anda akan mencatat bahwa "-t" adalah opsi scp tidak berdokumen, yang digunakan oleh program di ujung. Ini memberi Anda gagasan tentang apa yang perlu Anda masukkan ke dalam otor_keys.
EDIT: Anda dapat menemukan informasi lebih lanjut (dengan beberapa tautan) di pertanyaan StackOverflow ini .
Berikut adalah contoh yang berfungsi untuk ini, untuk pengguna yang disebutkan backup_user
di sisi server.
~backup_user/.ssh/authorized_keys
konten di sisi server (dengan beberapa batasan keamanan lainnya):
no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty,command="scp -v -r -d -t ~/CONTENT" ssh-rsa AAAAMYRSAKEY...
Buat tautan di ~ backup_user / yang menautkan ke direktori tempat konten dapat diakses.
$ ln -s /path/to/directory/with/accessible/content ~backup_user/CONTENT
Sekarang, dari sisi klien, perintah berikut harus berfungsi:
scp -v -r -P 2222 -i .ssh/id_rsa_key_file path/to/data backup_user@SERVER:~/CONTENT
Apa yang dilakukan perintah ini:
-v
dari perintah dan file otor_keys)-r
dari file command dan otor_keys jika Anda tidak ingin membuat salinan rekursif)-P 2222
dari perintah)-i .ssh/id_rsa_key_file
path/to/data
akan disalin ke/path/to/directory/with/accessible/content/
Untuk membuat salinan file (atau beberapa) dari server ke klien, Anda harus membuat skrip shell yang menangani ini seperti dijelaskan di sini
chmod 400 ~/.ssh/authorized_keys
.
~/.bashrc
(dan apa pun yang dijalankan Bash) dan ~/.ssh/rc
hanya-baca. Tetapi jika pengguna jahat memiliki akses ke rsync atau sftp, ia masih dapat menghapus ~/.bashrc
, dan mengunggah yang baru. Karena sulit untuk dilindungi, saya sarankan terhadap metode ini ( command="..."
).
Saya agak terlambat ke pesta, namun saya akan menyarankan Anda melihat pada ForceCommand
arahan OpenSSH.
Subsystem sftp internal-sftp
Match group sftponly
ForceCommand internal-sftp
Memang, ini SFTP dan bukan SCP, tetapi mencapai tujuan yang sama, lebih aman daripada dengan shell yang dibatasi. Selain itu, Anda dapat chroot pengguna jika Anda mau.
chrootDirectory %h
dan AllowTcpForwarding no
setelah bagian pertandingan untuk memaksa pengguna slopon melakukan chroot ke rumah mereka. harap dicatat bahwa pertandingan harus (harus!) menjadi bagian terakhir pada konfigurasi ssh dan opsi setelah itu adalah opsi hanya untuk pengguna yang cocok
ForceCommand internal-sftp -u 0077 -d /uploaddir
dapat semakin memperkerasnya, dengan memaksa umask pada direktori unggah. Sehubungan dengan 'ChrootDirectory`, ia menciptakan lingkungan unggahan yang sangat terkontrol dan terisolasi. Catatan bonus: dir default dan umask harus diatur dalam ForceCommand
, bukan dalam Subsystem
direktif, jika Anda ingin mereka berfungsi.
Saya akan merekomendasikan menggunakan scponly.
Ini adalah shell terbatas yang memungkinkan pengguna untuk melakukan apa yang terdengar seperti, file SCP ke server, tetapi tidak benar-benar masuk. Informasi dan unduhan kode sumber untuk perangkat lunak tersedia di sini dan paket RPM yang dikompilasi sebelumnya tersedia melalui Repositori EPEL YUM .
Setelah diinstal, Anda harus mengonfigurasi setiap akun pengguna, yang ingin Anda batasi aksesnya, untuk menggunakan shell yang dibatasi yang baru saja diinstal. Anda dapat melakukan ini secara manual melalui / etc / passwd atau menggunakan perintah berikut: usermod -s /usr/bin/scponly USERNAME
scponly
DIRANCANG untuk tujuan ini.
Saya menggunakan MySecureShell untuk melakukan ini. Anda dapat mengkonfigurasi pembatasan lain juga.
https://github.com/mysecureshell/mysecureshell
Batasi koneksi hanya untuk SFTP / SCP. Tidak ada akses shell.
Saya menemukan cara yang bagus adalah dengan menggunakan fitur command = "..." dari file Authorized_key. (Disarankan kepada saya oleh halaman ini )
Perintah yang akan Anda jalankan adalah perintah yang menguji argumen yang dimulai dengan scp (dan rsync).
Ini file yang diotorisasi:
# authorized_keys
command="/usr/local/bin/remote-cmd.sh" ssh-rsa.....== user@pewpew
Inilah isi dari remote-cmd.sh:
#!/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
Saya kira Anda mungkin masih perlu untuk melindungi file yang diotorisasi pengguna, tetapi tujuan saya adalah untuk memiliki kunci tanpa kata sandi yang dapat saya gunakan untuk cadangan, tanpa harus membuat pengguna yang sama sekali baru, dan memiliki kunci tidak memberikan shell (ok, dengan mudah)
~/.ssh/authorized_keys
, ~/.bashrc
(dan apa pun yang dijalankan Bash) dan ~/.ssh/rc
hanya-baca untuk pengguna. Tetapi jika pengguna jahat memiliki akses ke rsync atau sftp, ia masih dapat menghapus ~/.bashrc
, dan mengunggah yang baru. Karena sulit untuk dilindungi, saya sarankan terhadap metode ini ( command="..."
).
Ubah shell login pengguna ke sesuatu yang membatasi, yang memungkinkan pengguna hanya menjalankan scp , sftp-server dan rsync saja, dan juga memeriksa bahwa argumen tidak aman tidak diperbolehkan (misalnya scp -S ... dan rsync -e .. . tidak aman, lihat di sini: http://exploit-db.com/exploits/24795 ). Contoh untuk shell login yang ketat:
Anda mungkin ingin menjalankan salah satunya di chroot atau di lingkungan terbatas lainnya (misalnya nsjail di Linux), untuk menonaktifkan akses jaringan dan untuk kontrol (daftar putih) yang lebih mudah dari direktori mana yang dapat dibaca dan / atau ditulis.
Saya tidak menyarankan menggunakan command="..."
di ~/.ssh/authorized_keys
, karena tanpa perlindungan tambahan hati (seperti chmod -R u-w ~
untuk pengguna) pengguna berbahaya dapat meng-upload versi baru ~/.ssh/authorized_keys
, ~/.ssh/rc
atau ~/.bashrc
, dan dengan demikian dapat mencakup dan mengeksekusi perintah sewenang-wenang.
Ini bukan solusi yang paling anggun, tetapi Anda bisa melempar sesuatu seperti ini ke pengguna .bashrc
if [ "$TERM" != "dumb" ]; then
exit
fi
Saya telah menemukan bahwa pengguna SCP mendapatkan JANGKA 'bodoh', dan yang lain biasanya akan mendapatkan vt100.
Saya membayangkan pengguna mungkin bisa scp lebih baru. Bashrc, yang membuat ini bukan solusi terbaik, tetapi untuk solusi cepat dan kotor, ini akan bekerja
~/.bashrc
). Ini juga tidak jelas dalam arti bahwa mungkin versi yang lebih baru dari OpenSSH akan mengatur TERM
variabel secara berbeda, atau beberapa pengaturan konfigurasi sshd dapat mempengaruhi TERM
.
ssh -o SetEnv TERM=dumb yourserver bash
??