SCP की अनुमति दें लेकिन SSH का उपयोग करके वास्तविक लॉगिन नहीं

62

क्या किसी उपयोगकर्ता को लिनक्स बॉक्स (इस मामले में सेंटोस 5.2) पर कॉन्फ़िगर करने का कोई तरीका है ताकि वे फ़ाइलों को पुनः प्राप्त करने के लिए scp का उपयोग कर सकें, लेकिन वास्तव में SSH का उपयोग करके सर्वर पर प्रवेश नहीं कर सकते हैं?

linux ssh scp

— DrStalker
स्रोत

मैंने लॉगिन शेल को / बिन / झूठे सेट करने की कोशिश की, लेकिन यह पूरी तरह से काम करना बंद कर देता है।

— DrStalker

44

rssh खोल ( http://pizzashack.org/rssh/ ) ठीक इसी उद्देश्य के लिए बनाया गया है।

चूंकि RHEL / CentOS 5.2 में rssh के लिए एक पैकेज शामिल नहीं है, आप RPM प्राप्त करने के लिए यहाँ देख सकते हैं: http://dag.wieers.com/rpm/packages/rssh/

इसका उपयोग करने के लिए इसे इस तरह से एक नए उपयोगकर्ता के लिए एक शेल के रूप में सेट करें:

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

.. इस तरह से मौजूदा के लिए शेल बदलें:

chsh -s /usr/bin/rssh scpuser1

..और /etc/rssh.confrssh शेल को कॉन्फ़िगर करने के लिए संपादित करें - विशेष रूप से allowscpसभी rssh उपयोगकर्ताओं के लिए SCP पहुँच को सक्षम करने के लिए अनचाही लाइन।

(आप अपने घरों में मौजूद उपयोगकर्ताओं को रखने के लिए चेरोट का उपयोग करना चाह सकते हैं लेकिन यह एक और कहानी है।)

— गुमनाम
स्रोत

यह भयानक है - मैं थोड़ी देर के लिए कुछ इस तरह की तलाश कर रहा हूं, वह भी

— वॉरेन

6

rssh के पीछे का विचार अच्छा है, लेकिन iirc rshsh प्रोग्रामिंग शब्दों में सुरक्षा का चमत्कार नहीं था। Sh rssh शोषण ’पर एक साधारण Google अधिक परिणाम देता है क्योंकि मैं इसके साथ सहज हूं ...

— wzzrd

7

स्कूपली कमोबेश एक ही चीज है और जाहिर तौर पर कम शोषण-प्रवण: sublimation.org/scponly/wiki/index.php/Main_Page

— फ्रैंकोइस फगेस

मितव्ययी रूप से गीथब में चले गए प्रतीत होते हैं। वशीकरण लिंक मृत है। github.com/scponly/scponly/wiki

— spazm

38

मुझे इसमें देरी हो रही है, लेकिन आप ssh कुंजियों का उपयोग कर सकते हैं और उनके ~ / .shsh / अधिकृत_keys फ़ाइल में अनुमत सटीक कमांड निर्दिष्ट कर सकते हैं।

no-port-अग्रेषण, no-pty, कमांड = "scp source target" ssh-dss ...

सही कमांड सेटिंग्स सेट करने के लिए आपको लक्ष्य पर ps का उपयोग करने की आवश्यकता हो सकती है।

पुनश्च: यदि आप "-v" के साथ एक टेस्ट स्केप कमांड चलाते हैं, तो आप कुछ इस तरह देख सकते हैं

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

आप ध्यान देंगे कि "-t" एक अनकम्फर्टेबल scp ऑप्शन है, जिसका उपयोग प्रोग्राम के द्वारा सबसे अंत में किया जाता है। इससे आपको यह पता चलता है कि आपको अधिकृत_की में क्या करने की आवश्यकता है।

EDIT: आप इस StackOverflow प्रश्न में अधिक जानकारी (कई लिंक के साथ) पा सकते हैं ।

यहाँ इसका एक कार्यशील उदाहरण है, backup_userसर्वर साइड पर नामित उपयोगकर्ता के लिए ।

~backup_user/.ssh/authorized_keys सर्वर साइड की सामग्री (कुछ और सुरक्षा प्रतिबंधों के साथ):

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

~ Backup_user / में एक लिंक बनाएँ जो उस निर्देशिका के लिए लिंक हो जहाँ सामग्री पहुँच योग्य होनी चाहिए।

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

अब, ग्राहक की ओर से, निम्नलिखित कमांड काम करना चाहिए:

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

यह कमांड क्या करती है:

यह क्रियात्मक जानकारी प्रदर्शित करता है ( विकल्प : आप -vकमांड और अधिकृत_की फाइल दोनों से हटा सकते हैं )
यह पुनरावर्ती पथ / / डेटा की सामग्री की प्रतिलिपि बनाता है। ( विकल्प : -rयदि आप पुनरावर्ती प्रतिलिपि नहीं बनाना चाहते हैं तो आप कमांड और अधिकृत_की फ़ाइल दोनों से निकाल सकते हैं )
यह सर्वर से कनेक्ट करने के लिए पोर्ट 2222 का उपयोग करता है ( विकल्प : आप -P 2222कमांड से हटा सकते हैं )
यह कनेक्शन को स्वचालित करने के लिए उपयोग करता है और पहचान फ़ाइल ( विकल्प : आप निकाल सकते हैं-i .ssh/id_rsa_key_file
की सामग्री को path/to/dataकॉपी किया जाएगा/path/to/directory/with/accessible/content/

सर्वर से क्लाइंट के लिए फ़ाइल (या कई) की एक प्रतिलिपि बनाने के लिए, आपको एक शेल स्क्रिप्ट बनानी चाहिए जो इसे यहां बताए अनुसार संभालती है

— समुदाय
स्रोत

1

उपयोगकर्ता को उनकी अधिकृत_की फ़ाइल पर स्कैप करने से रोकने के लिए क्या है? क्या इसे स्वयं उपयोगकर्ता के स्वामित्व में प्रतिबंधित नहीं किया जा सकता है?

— दान

1

@ डान - अधिकृत_की फाइल पर रीड-ओनली परमिशन सेट करना संभव होना चाहिए, अर्थात। chmod 400 ~/.ssh/authorized_keys।

— रोजर ड्यूक 15

इसके अलावा आपको ~/.bashrc(और जो भी बाश निष्पादित होता है) बनाना चाहिए और ~/.ssh/rcकेवल-पढ़ने के लिए। लेकिन अगर दुर्भावनापूर्ण उपयोगकर्ता के पास rsync या sftp तक पहुंच है, तो वह अभी भी हटा सकता है ~/.bashrc, और एक नया अपलोड कर सकता है । चूंकि इसे संरक्षित करना कठिन है, इसलिए मैं इस पद्धति के खिलाफ सलाह देता हूं ( command="...")।

— अंक

31

मुझे पार्टी में थोड़ी देर हो गई है, हालांकि मैं आपको ForceCommandओपनएसएसएच के निर्देश पर एक नज़र डालने का सुझाव दूंगा ।

Subsystem sftp internal-sftp

Match group sftponly
         ForceCommand internal-sftp

दी, यह एसएफटीपी है और एससीपी नहीं है, लेकिन यह एक ही लक्ष्य तक पहुंचता है, एक प्रतिबंधित शेल की तुलना में अधिक सुरक्षित रूप से। इसके अतिरिक्त, यदि आप चाहें तो उपयोगकर्ता को हटा सकते हैं।

— फ्रांकोइस फुगेस
स्रोत

2

मैच अनुभाग के बाद chrootDirectory %hऔर जोड़ने के AllowTcpForwarding noलिए sftponly उपयोगकर्ताओं को अपने घर में घूमने के लिए मजबूर करने के लिए। कृपया ध्यान दें कि मैच ssh कॉन्फिग पर अंतिम सेक्शन (होना चाहिए) और उसके बाद के विकल्प

— मैच्योर

4

ForceCommand internal-sftp -u 0077 -d /uploaddirअपलोड निर्देशिका पर एक umask मजबूर करके इसे दूर कर सकते हैं। 'चेरोटडायरेरी' के संयोजन में यह एक बहुत ही नियंत्रित, पृथक अपलोड वातावरण बनाता है। बोनस नोट: यदि आप चाहते हैं कि काम करना हो तो डिफॉल्ट डायर और ओम्स्क को निर्देश ForceCommandमें निर्धारित किया जाना चाहिए Subsystem।

— मार्सिन

यह समझाने वाला एक लंबा लेख debian-administration.org/article/590/…

— koppor

7

मैं स्कल्प्ली का उपयोग करने की सलाह दूंगा।

यह एक प्रतिबंधित शेल है जो उपयोगकर्ताओं को केवल ऐसा करने की अनुमति देता है जो उसे लगता है, सर्वर पर एससीपी फाइलें, लेकिन वास्तव में लॉग इन नहीं है। सॉफ्टवेयर के लिए सूचना और स्रोत कोड डाउनलोड यहां उपलब्ध हैं और पूर्व संकलित आरपीएम पैकेज के माध्यम से उपलब्ध हैं। EPEL YUM रिपोजिटरी ।

एक बार स्थापित होने के बाद, आपको प्रत्येक उपयोगकर्ता खाते को कॉन्फ़िगर करने की आवश्यकता होगी, जिसे आप नए स्थापित प्रतिबंधित शेल का उपयोग करने के लिए उपयोग को प्रतिबंधित करना चाहते हैं। आप इसे मैन्युअल रूप से / etc / passwd या निम्न कमांड का उपयोग कर सकते हैं: usermod -s /usr/bin/scponly USERNAME

— syn-
स्रोत

मैं इसके समर्थन में हूं। scponlyइस उद्देश्य के लिए डिज़ाइन किया गया है।

— यूटाहजहेड सेप

1

बुरी तरह से मरा हुआ प्रतीत होता है। डेबियन ने इसे हटा दिया लगता है: package.debian.org/search?keywords=scponly और github पर कोड भी मृत है। अनुवर्ती चर्चा: serverfault.com/questions/726519/…

— koppor

6

मैं ऐसा करने के लिए MySecureShell का उपयोग करता हूं। आप अन्य प्रतिबंधों को भी कॉन्फ़िगर कर सकते हैं।

https://github.com/mysecureshell/mysecureshell

केवल SFTP / SCP से कनेक्शन सीमित करता है। कोई शेल एक्सेस नहीं।

— J.Zimmerman
स्रोत

3

पार्टी के लिए बहुत देर हो चुकी है, लेकिन सिर्फ git उपयोगकर्ता के शेल को usr / bin / git-shell होना चाहिए। यह एक प्रतिबंधित शेल है जो इंटरैक्टिव लॉगिन की अनुमति नहीं देता है। आप अभी भी उपयोगकर्ता के साथ 'su -s / bin / bash git' या जो भी आपका उपयोगकर्ता नाम है, पर मुकदमा कर सकते हैं।

— इयान एलिस
स्रोत

2

हम अपने सुरक्षित ftp सर्वरों पर स्कूपली नामक एक छद्म शेल का उपयोग करते हैं जो हम केवल उन फ़ाइलों को स्कैन करने में सक्षम होना चाहते हैं लेकिन लॉग इन नहीं करते हैं।

— Zypher
स्रोत

2

मैंने पाया है कि एक अच्छा तरीका कमांड = "..." सुविधा का उपयोग करना है। ( इस पृष्ठ द्वारा मुझे सुझाव दिया गया )

आपके द्वारा चलाया जाने वाला कमांड एक ऐसा तर्क होगा जो scp (और rsync) से शुरू होने वाले तर्कों के लिए परीक्षण करता है।

यहाँ अधिकृत_की फ़ाइल है:

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

यहां दूरस्थ- 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

मुझे लगता है कि आपको अभी भी उपयोगकर्ता की अधिकृत_की फ़ाइल को संरक्षित करने की आवश्यकता होगी, लेकिन मेरा उद्देश्य एक पासवर्ड-कम कुंजी था जिसे मैं बैकअप के लिए उपयोग कर सकता था, एक नया उपयोगकर्ता बनाने के बिना, और कुंजी को एक शेल नहीं देना होगा (ठीक है, आसानी से)

— फिल
स्रोत

3

यह बहुत अच्छा है - लेकिन मुझे लगता है कि इसे एक कमांड जारी करके विकृत किया जा सकता है जो एक स्कैप करता है, फिर बाद में एक स्क्रिप्ट चलाएं!

— दाविगो 18

@davidgo को क्रियान्वित करने के साथ $ SSH_ORIGINAL_COMMAND का उपयोग करने से पता चल सकता है कि भेद्यता, स्केप और rsync मानकर स्वयं कई कार्यक्रम चलाने की कोशिश नहीं करते हैं (जिस स्थिति में, यह टूट जाएगा)

— Phil

इसके अलावा, आप बनाना चाहिए ~/.ssh/authorized_keys, ~/.bashrc(और जो कुछ भी बाकी बैश कार्यान्वित) और ~/.ssh/rcकेवल पढ़ने के लिए उपयोगकर्ता के लिए। लेकिन अगर दुर्भावनापूर्ण उपयोगकर्ता के पास rsync या sftp तक पहुंच है, तो वह अभी भी हटा सकता है ~/.bashrc, और एक नया अपलोड कर सकता है । चूंकि इसे संरक्षित करना कठिन है, इसलिए मैं इस पद्धति के खिलाफ सलाह देता हूं ( command="...")।

— अंक

1

@ आपके द्वारा दोनों आरसी फाइलें बनाई जा सकती हैं, और उनमें मौजूद डायरियों को उपयोगकर्ता के अलावा किसी और के पास होना चाहिए (उपयोगकर्ता?) और उपयोगकर्ता द्वारा लिखित नहीं। लेकिन इस समय आप rssh की तरह समर्पित कुछ का उपयोग कर बेहतर कर रहे हैं। वाह, मुझे एहसास हुआ कि यह मेरा जवाब है! ये पुराना है! Haha!

— फिल

उस scp -S को न भूलें ... और rsync -e ... उपयोगकर्ता को मनमाना कमांड निष्पादित करने देता है। इसलिए आपको इसे निष्पादित करने से पहले $ SSH_ORIGINAL_COMMAND में तर्कों की जांच करनी चाहिए । यहां अधिक जानकारी: शोषण- db.com/exploits/24795

— pts

1

उपयोगकर्ता के लॉगिन शेल को कुछ प्रतिबंधक में बदलें, जो उपयोगकर्ता को केवल scp , sftp-server और rsync को चलाने देता है , और यह भी जाँचता है कि असुरक्षित तर्क की अनुमति नहीं है (उदाहरण के लिए sc -S ... और rsync -com ..) । असुरक्षित हैं, यहाँ देखें: http://exploit-db.com/exploits/24795 )। इस तरह के प्रतिबंधात्मक लॉगिन शेल के लिए उदाहरण:

rssh
scponly (न केवल scp, sftp, svn आदि को भी अनुमति देता है, अगर यह विन्यस्त है)
transfer_shell

आप इनमें से एक को चेरोट में या किसी अन्य प्रतिबंधित वातावरण में (जैसे लिनक्स पर nsjail ), नेटवर्क एक्सेस को निष्क्रिय करने के लिए और आसान (श्वेतसूचीबद्ध) नियंत्रण के लिए चलाना चाह सकते हैं जिसके लिए निर्देशिकाओं को पढ़ा और / या लिखा जा सकता है।

मैं उपयोग करने की सलाह नहीं command="..."देता ~/.ssh/authorized_keys, क्योंकि अतिरिक्त सुरक्षा के बिना (जैसे chmod -R u-w ~कि उपयोगकर्ता के लिए) एक दुर्भावनापूर्ण उपयोगकर्ता एक नया संस्करण अपलोड कर सकता है ~/.ssh/authorized_keys, ~/.ssh/rcया ~/.bashrcइस तरह मनमाने आदेशों को शामिल और निष्पादित कर सकता है।

— अंक
स्रोत

0

इसका सबसे सुंदर समाधान नहीं है, लेकिन आप उपयोगकर्ताओं में कुछ ऐसा फेंक सकते हैं

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

मैंने पाया है कि एससीपी उपयोगकर्ताओं को 'गूंगा' का एक शब्द मिलता है, और अन्य को आमतौर पर vt100 मिलेगा।

मुझे लगता है कि उपयोगकर्ता शायद एक नए .bashrc पर scp कर सकता है, जो इसे सबसे अच्छा समाधान नहीं बनाता है, लेकिन एक त्वरित और गंदे समाधान के लिए, यह काम करेगा

— jizaymes
स्रोत

1

मैं इस प्रस्तावित समाधान के खिलाफ दृढ़ता से सलाह देता हूं, दुर्भावनापूर्ण उपयोगकर्ता के लिए यह आसान है कि वह चक्कर काटे (जैसे कि दूसरे को अपलोड करके ~/.bashrc)। यह इस अर्थ में भी भयावह है कि शायद ओपनएसएसएच के नए संस्करण TERMचर को अलग तरीके से सेट करेंगे , या कुछ sshd config सेटिंग्स प्रभावित हो सकती हैं TERM।

— अंक

1

एह… ssh -o SetEnv TERM=dumb yourserver bash??

— ulidtko