SSH टनलिंग त्रुटि: "चैनल 1: ओपन फेल: प्रशासनिक रूप से निषिद्ध: ओपन फेल"

184

जब मैं इस ssh सुरंग को खोलता हूं:

ssh -nXNT -p 22 localhost -L 0.0.0.0:8984:remote:8983

स्थानीयहोस्ट पर चल रहे HTTP सर्वर: 8984 पर पहुँचने की कोशिश करने पर मुझे यह त्रुटि मिलती है:

channel 1: open failed: administratively prohibited: open failed

इस त्रुटि का क्या मतलब है, और आप किस मशीन पर समस्या को ठीक कर सकते हैं?

ssh ssh-tunneling port-forwarding

— नील
स्रोत

शायद मुझे कुछ याद आ रहा है, लेकिन आप ssh क्लाइंट का उपयोग करके वेब सर्वर तक पहुंचने की कोशिश क्यों कर रहे हैं?

— फहीम मीठा

आप यहां X11 (-X विकल्प) को क्यों अग्रेषित कर रहे हैं? यदि आप केवल HTTP को अग्रेषित करना चाहते हैं तो यह आवश्यक नहीं है। और एक साइड नोट के रूप में IMHO ssh एक वेबसर्वर को कई पोर्ट पर उपलब्ध कराने के लिए गलत समाधान हो सकता है।

— मार्सेल जी

29

मैंने remoteअपने मामले में " होस्टनाम हल नहीं कर सकता" का यह अर्थ पाया ।

— रॉबॉम

3

जैसा कि आप नीचे दिए गए उत्तर के दर्जनों से देख सकते हैं, त्रुटि संदेश, बहुत विशिष्ट दिखने के बावजूद, सामान्य त्रुटि के रूप में समझा जाना चाहिए। आम तौर पर, समाधान रिमोट पर एक खोल खोलना और वास्तविक कारण को देखने के लिए बहुत ही कनेक्शन की कोशिश करना है। आपको सबसे सामान्य वास्तविक कारणों के नीचे उत्तर मिलेंगे।

— स्टीफन गौरिचोन

DNS रिज़ॉल्यूशन की विफलता के कारण यह त्रुटि हो सकती है, साथ ही कनेक्शन तब तक फ्रीज हो सकता है जब तक कि यह समाप्त न हो जाए: superuser.com/a/700677

— user423430

122

चैनल 1: ओपन फेल: प्रशासनिक रूप से निषिद्ध: ओपन फेल

उपरोक्त संदेश आपके एसएसएच सर्वर को संदर्भित करता है कि साइड चैनल खोलने के लिए आपके एसएसएच क्लाइंट के अनुरोध को अस्वीकार कर दिया जाए। यह आमतौर पर से आता है -D, -Lया -w, के रूप में SSH धारा में अलग चैनलों में अग्रेषित डेटा नौका लिए आवश्यक हैं।

चूंकि आप उपयोग कर रहे हैं -L(यह भी लागू है -D), प्रश्न में दो विकल्प हैं जो आपके SSH सर्वर के इस अनुरोध को अस्वीकार करने का कारण बन रहे हैं:

AllowTcpForwarding (जैसा कि स्टीव बुज़ोनस ने उल्लेख किया है)
PermitOpen

इन विकल्पों में पाया जा सकता है /etc/ssh/sshd_config। आपको यह सुनिश्चित करना चाहिए:

AllowTCPForwarding या तो मौजूद नहीं है, टिप्पणी की गई है, या करने के लिए सेट है yes
PermitOpenया तो मौजूद नहीं है, टिप्पणी की गई है, या any[1] पर सेट है

इसके अतिरिक्त, यदि आप कनेक्ट करने के लिए SSH कुंजी का उपयोग कर रहे हैं, तो आपको यह जांचना चाहिए कि आपके SSH कुंजी के अनुरूप प्रविष्टि में या कथन ~/.ssh/authorized_keysनहीं है [2]।no-port-forwardingpermitopen

अपने विशेष आदेश के लिए प्रासंगिक नहीं है, लेकिन इस विषय के लिए भी कुछ हद तक प्रासंगिक है, PermitTunnelविकल्प है यदि आप -w विकल्प का उपयोग करने का प्रयास कर रहे हैं।

[१] sshd_config(5)मैनपेज में पूर्ण वाक्य रचना ।

[२] authorized_keys(5)मेनपेज में पूर्ण सिंटैक्स ।

— hyperair
स्रोत

यहाँ मैं विशेष रूप से इसे काम करने के लिए sshd_config में क्या जोड़ता हूँ: TCPKeepAlive Yes AllowTCPForwarding हाँ PermitOpen किसी भी मेरे पास कुछ "ओपन फेल" है, लेकिन यह एक सामान्य बात लगती है। चीजें बहुत अच्छी तरह से काम करती हैं।

— पियरे थिबॉल्ट

4

नोट करने के लिए एक कोने का मामला: एसएसएच और एसएसएच के साथ एक टैप / ट्यून डिवाइस बनाने की कोशिश करते समय आप यह त्रुटि प्राप्त कर सकते हैं, लेकिन कर्नेल ऐसा नहीं करता है। यह एलएक्ससी कंटेनरों में हो सकता है। सटीक विवरणों के लिए blog.felixbrucker.com/2015/10/01/… देखें , लेकिन उस स्थिति में आप lxc.cgroup.devices.allow = c 10:200 rwmअपने कंटेनर के कॉन्फ़िगरेशन में जोड़ना चाहते हैं , और सुनिश्चित करें कि यदि /dev/net/tunमौजूद नहीं है, mknod /dev/net/tun c 10 200; chmod 666 /dev/net/tunतो कंटेनर में बूटअप पर चलाया जाता है।

— अजेन्डेल

@Azendale, यह दिलचस्प है, धन्यवाद। क्या यह ठीक उसी त्रुटि संदेश, या कुछ अलग तरह से उपज देता है?

— हाइपरएयर

1

@ सेंटऑनारियो, AllowTcpForwardingआपको एसएसएच पर टीसीपी बंदरगाहों को अग्रेषित करने की अनुमति देता है, जो कि -L 0.0.0.0:8984:remote:8983पैरामीटर अनुरोध कर रहा है। यदि AllowTcpForwardingसेट किया गया है no, तो SSH पोर्ट अग्रेषण अनुरोध को अस्वीकार कर देगा, जिससे आपको वह त्रुटि दिखाई देगी।

— हाइपरएयर

2

के ऊपरी मामले को संपादित करने की कोशिश की AllowTCPForwardingगई AllowTcpForwarding, लेकिन एसई चाहता है कि कम से कम 6 अक्षर बदले जाएं। तो सिर्फ यह देखते हुए कि सही मामला Tcpसंस्करण है, जैसा कि पहली बार सही ढंग से उपयोग किया गया है।

— dbreaux

51

एक बहुत ही अजीब मामले में, मैंने एक स्थानीय सुरंग बनाने की कोशिश करते समय इस त्रुटि का भी अनुभव किया। मेरी आज्ञा कुछ इस प्रकार थी:

ssh -L 1234:localhost:1234 user@remote

समस्या यह थी कि रिमोट होस्ट पर, /etc/hosts"लोकलहोस्ट" के लिए कोई प्रविष्टि नहीं थी , इसलिए ssh सर्वर को पता नहीं था कि सुरंग को कैसे सेटअप किया जाए। इस मामले के लिए एक बहुत ही मैत्रीपूर्ण त्रुटि संदेश; मुझे खुशी है कि आखिरकार मैंने इसका पता लगा लिया।

सबक: सुनिश्चित करें कि आपकी टनल का टारगेट होस्टनाम रिमोट होस्ट द्वारा या तो DNS या के माध्यम से रिजॉल्व करने योग्य है /etc/hosts।

— cobbzilla
स्रोत

2

धन्यवाद, यह मेरे लिए मुद्दा था। मैंने IP के लिए होस्ट नाम स्थानीय रूप से बनाया था, लेकिन दूरस्थ ssh सर्वर पर नहीं।

— dev_feed

2

"आपकी टनल का टारगेट होस्टनाम" को समझना थोड़ा कठिन है। क्या आप एक ठोस व्यावहारिक उदाहरण दे सकते हैं जो मुझे आपके उदाहरण को लेने की अनुमति देगा और आपके लक्ष्य होस्टनाम के साथ आपके उदाहरण में "लक्ष्य होस्टनाम" को बदल देगा (एक बार मैं समझता हूं कि आपके द्वारा इसका क्या मतलब है) और यह काम है?

— टेरेंस ब्रैनोन

1

मुझे यकीन भी नहीं है कि आपकी टिप्पणी समझ में आती है। आप कहते हैं कि रिमोट मशीन में लोकलहोस्ट के लिए कोई प्रविष्टि नहीं थी। लेकिन फिर कहते हैं कि दूरस्थ होस्ट को लक्ष्य होस्टनाम को हल करना होगा न कि स्थानीय होस्टनाम को। पहले और बाद की स्थिति का एक पूर्ण ठोस उदाहरण सहायक होगा।

— टेरेंस ब्रानोन

1

@TerrenceBrannon ऊपर की कमांड में, "लोकलहोस्ट" सुरंग का लक्ष्य होस्टनाम है । SSH टनल बनाते समय, ssh कमांड पहले रिमोट सिस्टम ( user@remote) में लॉग होता है , फिर रिमोट एंड से, यह टनल को होस्ट किए गए टारगेट मेजबानों (उपरोक्त कमांड में यह है localhost) पर सेट करता है। ऐसा करते समय, यह दूरस्थ होस्ट पर होस्टनाम रिज़ॉल्यूशन स्कीम का उपयोग करता है। तो अगर आप जिस मशीन में SSH'd का समाधान नहीं कर सकते localhost, आपको यह त्रुटि संदेश मिल जाएगा।

— cobbzilla

1

मेरे मामले में, यह लक्ष्य होस्टनाम के गलत होने के रूप में सरल था, इसलिए निश्चित रूप से यह हल नहीं हुआ, लेकिन मेरी आँखें टाइपो को बहुत लंबे समय तक देखने से चूक गईं।

— रान्डेल

25

कम से कम एक उत्तर यह है कि मशीन "रिमोट" किसी कारण के लिए ssh के साथ अगम्य है। त्रुटि संदेश बस बेतुका है।

— नील
स्रोत

2

नहीं, यह नहीं है; मैं icmp-admin-निषिद्ध का उपयोग करता हूं क्योंकि फ़ायरवॉल में अस्वीकार ध्वज हर समय कॉन्फ़िगर होता है।

— शादुर

9

+1, प्रशासनिक रूप से निषिद्ध संदेश यह मानने का कारण होगा कि यह एक फ़ायरवॉल ब्लॉकेज है, हालाँकि आपको एक ही संदेश प्राप्त होता है जब कोई फ़ायरवॉल ब्लॉकेज नहीं होता है लेकिन ओपन फेल हो जाता है क्योंकि रिमोट होस्ट का कोई मार्ग नहीं होता है।

— स्टीव बुजोनस

1

मैंने इस समस्या का शिकार होने में सिर्फ कई मिनट बिताए हैं, जिसका संदेश मेरे संदर्भ में कोई मायने नहीं रखता है। शुक्र है कि यह मध्य स्टेशन लॉग फ़ाइलों की जाँच करने पर बहुत स्पष्ट है।

— yaccz

वास्तव में अगर "रिमोट" अगम्य है - क्योंकि यह नीचे है, ऑफ़लाइन है, मौजूद नहीं है, होस्टनाम हल नहीं करता है - तब आपको यह त्रुटि संदेश दिखाई देगा।

— माइकल मार्टिनेज

18

यदि सर्वर पर 'रिमोट' को हल नहीं किया जा सकता है, तो आपको वह त्रुटि मिलेगी। एक आईपी पते के साथ बदलें और देखें कि क्या यह आपके मुद्दे को हल करता है ...

(मूल रूप से नील के समान ही उत्तर - लेकिन मैंने यह निश्चित रूप से पाया है कि मेरी तरफ यह मुद्दा है) [मैं अपनी ~/.ssh/configफ़ाइल में मशीन के नाम के लिए एक उपनाम था - और दूरस्थ मशीन को उस उपनाम के बारे में कुछ भी नहीं पता था ...

— jacquesjtheron
स्रोत

-Dकिसी ब्राउज़र में SOCKS प्रॉक्सी के रूप में (डायनामॉर्फवर्ड) का उपयोग करते समय आपको वही त्रुटि दिखाई दे सकती है। यानी ऐसी वेबसाइट को एक्सेस करने की कोशिश करना, जिसे टनल होस्ट नहीं कर सकती।

— समयसीमा

10

यह त्रुटि निश्चित रूप से तब आती है जब आप ssh विकल्प का उपयोग करते हैं ControlPathऔर ControlMasterएक सॉकेट कनेक्शन को साझा करने के लिए कई क्लाइंट कनेक्शन (एक क्लाइंट से एक ही उपयोगकर्ता @ सर्वर) के बीच पुन: उपयोग किया जाता है। बहुत सारे खोलना (जो भी इसका मतलब है, मेरे मामले में ~ 20 कनेक्शन) यह संदेश देता है। किसी भी पिछले कनेक्शन को बंद करने से मैं नए सिरे से खुल सकता हूं, फिर से सीमा तक।

— मतेज कोवैक
स्रोत

मैं यह देखने के लिए यहाँ आया था कि इस ControlMaster मल्टीप्लेक्स की सीमा को कहाँ स्थापित किया जाए। अगर किसी को पता है, तो वे साझा करने के लिए स्वागत से अधिक हैं।

— क्लैक

1

clacke: के अनुसार bugs.debian.org/cgi-bin/bugreport.cgi?bug=546854 आप / etc / ssh / sshd_config फ़ाइल में एक MaxSession पैरामीटर जोड़ने इस सेट करने के लिए कर सकते हैं। मैन पेज के अनुसार, यह डिफ़ॉल्ट रूप से 10 पर सेट है।

— ओलिवर

@oliver: पुष्टि, MaxSession काम करता है, धन्यवाद। मेरी कार्यपुस्तिका पर 64 से टकराया।

— मतेज कोवैक

2

सावधान रहें, MaxSessionलेकिन ऐसा नहीं है MaxSessions। हालाँकि कुछ सुरक्षाएँ हैं, लेकिन अपने ssh सर्वर विन्यास को न तोड़ें ...

— स्टीफन गौरिचोन

8

"प्रशासनिक रूप से निषिद्ध" एक विशिष्ट ICMP संदेश ध्वज होता है, जो "इस कनेक्शन को अवरुद्ध किए जाने के लिए प्रशासक स्पष्ट रूप से चाहता है"।

अपनी iptables सेटिंग्स जांचें।

— Shadur
स्रोत

5

जरुरी नहीं। संदेश तब उत्पन्न होता है जब होस्ट अनुरोध को पूरा नहीं कर सकता है। मामला आम तौर पर है क्योंकि व्यवस्थापक ने कनेक्शन अवरुद्ध कर दिया है, लेकिन यह भी हो सकता है कि क्या यह स्पष्ट रूप से अवरुद्ध नहीं है, लेकिन वांछित मेजबान के लिए कोई रास्ता नहीं है। AFAIK के sshपास यह निर्धारित करने के लिए कोई तर्क नहीं है कि कोई कनेक्शन विफल क्यों हुआ, यह सिर्फ मानता है कि यदि आप कनेक्ट करने का प्रयास कर रहे हैं, तो यह मौजूद है, और यदि आप वहां नहीं पहुंच सकते हैं तो कनेक्शन जानबूझकर अवरुद्ध किया गया है।

— स्टीव बुज़ोनस

2

उह, नहीं। ICMP प्रतिक्रिया के प्रकार के बीच एक अलग अंतर है जो कहता है "होस्ट करने के लिए कोई मार्ग नहीं" और एक कहता है कि "प्रशासनिक रूप से निषिद्ध" है, और जब तक कि किसी ने जानबूझकर किसी राउटर को गलत तरीके से गलत नहीं किया है, तो बाद का मतलब है कि यह टिन पर क्या कहता है।

— शादुर

1

होस्टनाम का उपयोग करते समय मुझे बस 'प्रशासनिक रूप से निषिद्ध' मिला, जो हल नहीं हुआ, इसलिए यह एक पकड़-सभी प्रतीत होता है। शायद ssh कुछ अनुवाद कर रहा है?

— गणेश सितमपालम

5

एक समान समस्या

एक और संभावित नेतृत्व

मैं का उपयोग कर एक ही समस्या थी ~/.ssh/authorized_keysके साथ permitopen।

जैसा कि मैं autosshएक सुरंग बनाने के लिए उपयोग करता हूं, मुझे दो पोर्ट चाहिए:

कनेक्शन के लिए एक (10000),
निगरानी के लिए एक (10001)।

क्लाइंट की तरफ

इसने मुझे मॉनिटरिंग पोर्ट के साथ एक समान समस्या दी:

autossh -M 10001 -o GatewayPorts=yes -o ServerAliveInterval=60  -o TCPKeepAlive=yes -T -N -R :10000:localhost:22 -i ~/.ssh/id_rsa user@remote

मेरे पास वह संदेश था (10 मिनट के बाद):

channel 2: open failed: administratively prohibited: open failed

दूर की तरफ

मेरा /var/log/auth.logनिहित:

Received request to connect to host 127.0.0.1 port 10001, but the request was denied.

मेरे ~/.ssh/authorized_keys(दूरस्थ पक्ष) में मेरे पास यह था:

command="/home/user/tunnel",no-X11-forwarding,no-pty,permitopen="localhost:10000",permitopen="localhost:10001" ssh-rsa AAAA...

इसे कैसे हल किया जाए

मैंने इसे localhostउदाहरणों से बदलकर हल किया 127.0.0.1:

command="/home/user/tunnel",no-X11-forwarding,no-pty,permitopen="127.0.0.1:10000",permitopen="127.0.0.1:10001" ssh-rsa AAAA...

ऐसा लगता है कि एसएसएच यह नहीं समझता है कि localhostयह एक शॉर्टकट है 127.0.0.1, इसलिए संदेश auth.logऔर प्रशासनिक रूप से निषिद्ध संदेश।

मैं यहाँ समझता हूँ कि प्रशासनिक रूप से इसका मतलब है "सर्वर साइड पर एक विशिष्ट कॉन्फ़िगरेशन के कारण"।

— lauhub
स्रोत

लोकलहोस्ट की संभावना :: # 1 (ipv6) से मैप की गई और आप किसी कारणवश वहां नहीं सुन रहे थे

— Jo Rhett

4

जब होता है तब भी यही होता /etc/sshd_configहै

AllowTcpForwarding no

सेट। yesटीसीपी अग्रेषण की अनुमति देने के लिए इसे स्विच करें।

— user578125
स्रोत

4

मेरे मामले में, मुझे इसके localhostसाथ बदलना पड़ा 127.0.0.1:

ssh -L 1234:localhost:3389 user@remote

यह काम करने के लिए।

मैं SSH टनलिंग के माध्यम से AWS EC2 से जुड़ने परrdesktop -L localhost:1234 अमेज़ॅन के निर्देशों का पालन करने की कोशिश कर रहा था । मैंने /etc/ssh/sshd_configउच्चतम मत वाले उत्तर के अनुसार (दोनों क्लाइंट और Ubuntu 16.04 LTS) चलाने की कोशिश की थी । मैं भी जाँच की है कि localhostमें है /etc/hostsदोनों पक्षों पर।

तब तक कुछ भी काम नहीं किया जब तक कि मैंने sshखुद कमान नहीं बदल ली :

ssh -L 1234:127.0.0.1:3389 user@remote

— tinlyx
स्रोत

आपको बहुत - बहुत धन्यवाद!

— थिबुत बर्रे

3

एक निश्चित उत्तर खोजने के लिए कुछ समस्या निवारण गतिविधि की आवश्यकता है:

जाँचें कि पोर्ट अग्रेषण उपयोगकर्ता के ssh विन्यास में सक्षम है,
ssh (-v) की वर्बोसिटी सक्षम करें,
स्थानीय होस्ट पर ssh लॉग की जाँच करें और रिमोट पर सुरक्षित लॉग्स,
विभिन्न दूरस्थ बंदरगाह का परीक्षण करें,
अपनी iptables सेटिंग जांचें (जैसा कि शादुर ने कहा था)।

— मार्को सोलीरी
स्रोत

3

रिमोट -एल पैरामीटर में डालने के लिए मुझे एक बार यह त्रुटि मिली, यह भी 0.0.0.0 बेमानी है कि आप इसे एक ही परिणाम के साथ छोड़ सकते हैं, और मुझे लगता है कि आपको इसके लिए -g को काम करने के लिए जोड़ना चाहिए।

यह वह रेखा है जिसका उपयोग मैं टनलिंग के लिए करता हूं: ssh -L 8983:locahost:8984 user@remote -4 -g -N

-4 tells to use only ipv4
-g Allows remote hosts to connect to local forwarded ports.
-N Do not execute a remote command.  This is useful for just forwarding ports (protocol version 2 only). I use this to clog the terminal so I don't forget to close it since generally I need the tunnels temporarily.

— मार्सियानो
स्रोत

3

यह भी स्थानीय पक्ष पर बंदरगाह के लिए बाध्य करने में असमर्थ होने के कारण हो सकता है।

ssh -Nn -L 1234:remote:5678 user@remote

यह कमांड स्थानीय मशीन पर एक श्रवण पोर्ट 1234 को बांधने की कोशिश कर रहा है, जो रिमोट मशीन पर पोर्ट 5678 पर एक सेवा के लिए मैप करता है।

यदि स्थानीय मशीन पर पोर्ट 1234 पहले से ही एक अन्य प्रक्रिया के उपयोग में है, (शायद एक पृष्ठभूमि ssh -f सत्र), तो ssh उस बंदरगाह पर नहीं सुन पाएगा और सुरंग विफल हो जाएगी।

समस्या यह है कि यह त्रुटि संदेश किसी भी कई चीजों का मतलब हो सकता है, और "प्रशासनिक रूप से निषिद्ध" कभी-कभी गलत विचार देता है। इसलिए, DNS की जाँच करने के अलावा, स्थानीय और दूरस्थ, और sshd_config के बीच फ़ायरवॉल, यह देखने के लिए जांचें कि क्या स्थानीय पोर्ट पहले से ही उपयोग किया गया है। उपयोग

lsof -ti:1234

यह पता लगाने के लिए कि 1234 में क्या प्रक्रिया चल रही है। अन्य उपयोगकर्ताओं के स्वामित्व वाली प्रक्रियाओं को सूचीबद्ध करने के लिए आपको lsof के लिए sudo की आवश्यकता हो सकती है। तब आप उपयोग कर सकते हैं

ps aux | grep <pid>

यह जानने के लिए कि यह प्रक्रिया क्या है।

यह सब एक आदेश में पाने के लिए:

ps aux | grep "$(sudo lsof -ti:1234)"

— Mnebuerquo
स्रोत

2

सुरंग का प्रयास करते समय मेरे पास एक ही संदेश था। दूरस्थ पक्ष पर dns सर्वर के साथ कोई समस्या थी। समस्या तब हल हुई जब वह वापस काम पर आया।

— लियोनार्डो ब्रूननेट
स्रोत

2

मुझे बेहद आश्चर्य है कि किसी ने भी यह उल्लेख नहीं किया है कि यह एक DNS मुद्दा हो सकता है।

journalctl -f
channel 3: open failed: administratively prohibited: open failed
Mar 10 15:24:57 hostname sshd[30303]: error: connect_to user@example.com: unknown host (Name or service not known)

यह तब प्रस्तुत किया जा सकता है यदि remoteआप को हटाने योग्य नहीं है या आपने अज्ञात वाक्यविन्यास दर्ज किया है जैसे मैंने यहां किया है जहां मैंने user@पोर्ट-फॉर लॉजिक (जो काम नहीं करेगा) में जोड़ा है ।

— Torxed
स्रोत

2

मेरे मामले में, शेल खोल के बिना एक सुरंग का अनुरोध करने के कारण समस्या थी, जबकि सर्वर का उद्देश्य मेरे खाते पर पासवर्ड परिवर्तन के लिए मजबूर करना था। एक शेल की कमी के कारण, मैं यह नहीं देख सका और केवल त्रुटि प्राप्त की

channel 2: open failed: administratively prohibited: open failed

मेरा सुरंग विन्यास इस प्रकार था:

ssh -p [ssh-port] -N -f -L [local-port]:127.0.0.1:[remote-port]
[server-address]

सर्वर से सीधे लॉग-इन करते समय त्रुटि दिखाई गई (बिना -N -f):

WARNING: Your password has expired. You must change your password now
and login again!

मैंने शेल एक्सेस के साथ लॉगिन करके और पासवर्ड बदलकर समस्या का समाधान किया। फिर मैं बस शेल एक्सेस के बिना सुरंगों का उपयोग कर सकता था।

— पीटर वान गॉर्प
स्रोत

1

मुझे यह समस्या तब हुई जब SSH के माध्यम से एक ऐसे उपयोगकर्ता से जुड़ने की कोशिश की गई जो केवल SFTP का उपयोग करने के लिए अधिकृत था।

उदाहरण के लिए, यह सर्वर में था /etc/ssh/sshd_config:

Match group sftponly
    ForceCommand internal-sftp
    ChrootDirectory /usr/chroot/%u
    [...]
Match

तो इस स्थिति में, SSH का उपयोग करने के लिए, आपको या तो उपयोगकर्ता को समतुल्य sftponlyसमूह से निकालना होगा या उस उपयोगकर्ता का उपयोग करके कनेक्ट करना होगा जो SFTP तक सीमित नहीं है।

— माइक
स्रोत

1

जाँच करें कि /etc/resolv.confक्या सर्वर पर खाली है जो आप कर रहे हैं ssh। कई बार मैंने इसे एक खाली /etc/resolv.confफाइल से संबंधित पाया

यदि गैर रूट, आप सार्वजनिक होस्टनाम पर कुछ pingया telnet(80) की कोशिश करके सर्वर पर जांच कर सकते हैं , अर्थात:

root@bananapi ~ # telnet www.google.com 80
telnet: could not resolve www.google.com/80: Name or service not known

नेमसर्वर रिकॉर्ड जोड़ने के बाद /etc/resolv.conf:

root@bananapi ~ # telnet www.google.com 80
Trying 74.125.195.104...
Connected to www.google.com.
Escape character is '^]'.
GET / HTTP/1.0

HTTP/1.0 302 Found
Location: http://www.google.ro/?gws_rd=cr&ei=8fStVZ-hMIv6UvX6iuAK

हालांकि, आपको यह भी जांचना चाहिए कि /etc/resolv.confखाली क्यों था (यह आमतौर पर सर्वर पर dhcp क्लाइंट द्वारा नेमसर्वर रिकॉर्ड के साथ पॉपुलेट किया जाता है, यदि लागू हो।

— Ender
स्रोत

1

मुझे यही संदेश मिल रहा था, जबकि एसएसबी ने डेबियन को ट्यूनिंग दी थी। यह पता चला कि रिमोट सिस्टम में कोई खाली जगह नहीं थी। कुछ डिस्क स्थान खाली करने और रिबूट करने के बाद, सुरंग ने काम करना शुरू कर दिया।

— SlavaSt
स्रोत

0

मैंने साइबरगन पर इस त्रुटि को देखा और यह लिनक्स के लिए भी सही होना चाहिए और मेरे लिए काम किया। मेरे मामले में मैंने ssh -ND किया: * 1234 user@127.0.0.1 और जब मैंने उस कॉम्प-सॉयर्स सर्वर से एक ब्राउज़र कनेक्ट किया, तो वह ब्राउज हो गया, लेकिन उस समय जहां मैंने उस ssh कमांड को चलाया, मुझे वह त्रुटि दिखाई दी प्रत्येक अनुरोध के साथ कंसोल - कम से कम एक साइट के लिए, हालांकि ब्राउज़र ने इसे प्रॉक्सी के माध्यम से पुनर्प्राप्त किया था या ऐसा प्रतीत होता था, कम से कम इस हद तक कि मैंने मुख्य आयु देखी। लेकिन इस बदलाव को विफल संदेश से छुटकारा मिल गया

http://linuxindetails.wordpress.com/2010/02/18/channel-3-open-failed-administratively-prohibited-open-failed/

While trying to do some SSH tunneling, here is the error I got :
channel 3: open failed: administratively prohibited: open failed
To avoid this kind of error, have a look at the SSH daemon configuration file :
/etc/ssh/sshd_config
Add possibly the following line :
root@remote-server:~# echo “PermitTunnel yes” >> /etc/ssh/sshd_config
Then, restart your sshd server :
root@remote-server:~# service ssh restart
or

root@remote-server:~# /etc/init.d/ssh restart

— barlop
स्रोत

AFAIK टनलिंग को डिफ़ॉल्ट रूप से सक्षम किया गया है क्योंकि अक्षम करने से सुरक्षा की कोई परत नहीं जुड़ती है, मुख्य रूप से केवल 3rd पार्टी टनल को जोड़ने में असुविधा होती है। मुझे एक समान समस्या हो रही है कि एक ऑफ साइट स्थान से आंतरिक सर्वर को प्रॉक्सी करने की कोशिश कर रहा है और टनलिंग सक्षम है + डिफ़ॉल्ट कार्रवाई करने के लिए फ्लॉप किए गए iptables ACCEPT।

— स्टीव बुज़ोनास 3

@SteveBuzonas मैं इसे / etc / sshd_config में देख रहा हूं, इसलिए a) यह टनलिंग b को अक्षम नहीं करता है) जैसा कि मेरे उत्तर के संबंध में है, इसका समाधान एक अच्छा विचार नहीं हो सकता है। यहाँ है कि sshd_config उस विकल्प के बारे में क्या कहता है # सुरंगित स्पष्ट पाठ पासवर्ड को निष्क्रिय करने के लिए, यहाँ कोई परिवर्तन न करें! #PermitTunnel नं

— barlop

@SteveBuzonas अपने एक की जांच करें यह संभवतः नहीं पर सेट है और आप सुरंग कर सकते हैं क्योंकि वास्तव में सुरंग डिफ़ॉल्ट रूप से सक्षम है।

— बार्लोप

मैं सोच रहा था AllowTCPForwarding, आप जिस टिप्पणी के बारे # To disable tunneled clear textमें बात कर रहे हैं PasswordAuthentication, PermitTunnelवह सेट न होने के संबंध में है , परत 2 या परत 3 नेटवर्किंग सुरंगों को ट्यून / टैप के माध्यम से अनुमति देने के लिए एक सेटिंग है और नहीं के लिए चूक है। एल, आर, और डी विकल्प टीसीपी अग्रेषण का उपयोग करते हैं न कि टनलिंग के लिए एक उपकरण।

— स्टीव बुज़ोनस

0

एक अन्य परिदृश्य यह है कि आप जिस सेवा तक पहुँचने की कोशिश कर रहे हैं वह नहीं चल रही है। मैं दूसरे दिन केवल इस मुद्दे को याद करने के लिए भागा कि जिस httpd उदाहरण को मैं कनेक्ट करने की कोशिश कर रहा था उसे रोक दिया गया था।

समस्या को हल करने के लिए आपके कदम सबसे सरल से शुरू होने वाले हैं, जो दूसरी मशीन पर जा रहा है और यह देखने के लिए कि क्या आप स्थानीय रूप से कनेक्ट हो सकते हैं और फिर अपने क्लाइंट कंप्यूटर की ओर वापस काम कर रहे हैं। कम से कम यह आपको इस बात पर काम करने की अनुमति देगा कि संचार किस बिंदु पर नहीं हो रहा है। आप अन्य दृष्टिकोण अपना सकते हैं, लेकिन यह वह है जो मेरे लिए काम करता है।

— आंद्रे एम
स्रोत

एक उपयोगी सामान्य टिप लेकिन सवाल का जवाब नहीं।

— काइल जोंस

0

DNS रबाइंडिंग सुरक्षा के लिए अपने राउटर की जांच करें । मेरे राउटर (pfsense) में DNS रिबाइंडिंग सुरक्षा डिफ़ॉल्ट रूप से सक्षम है। यह SSH के साथ 'चैनल ओपन: असफल प्रशासनिक रूप से निषिद्ध: ओपन फेल' त्रुटि पैदा कर रहा था

— meffect
स्रोत

0

मेरे पास एक ही मुद्दा था और मुझे एहसास हुआ कि यह डीएनएस था। ट्रैफिक को टनल किया गया है लेकिन DNS रिक्वेस्ट नं। DNS होस्ट फ़ाइल को मैन्युअल रूप से संपादित करने का प्रयास करें और उस सेवा को जोड़ें जिसे आप एक्सेस करना चाहते हैं।

— डेटा
स्रोत

0

मेरा मामला:

$ssh -D 8081 localhost >>log1.txt 2>&1 &

----wait for 3 days

$tail -f log1.txt
channel 963: open failed: connect failed: Connection refused
channel 963: open failed: connect failed: Connection refused
channel 971: open failed: connect failed: Connection reset by peer
channel 982: open failed: connect failed: Connection timed out
channel 979: open failed: connect failed: Connection timed out
channel 1019: open failed: administratively prohibited: open failed
accept: Too many open files
channel 1019: open failed: administratively prohibited: open failed
accept: Too many open files
channel 1019: open failed: administratively prohibited: open failed

$ps  axu | grep 8081
root       404  0.0  0.0   4244   592 pts/1    S+   05:44   0:00 grep --color=auto 8081
root       807  0.3  0.6   8596  6192 ?        S    Mar17  76:44 ssh -D 8081 localhost

$lsof -p 807 | grep TCP
ssh     807 root 1013u  sock     0,8      0t0 2076902 protocol: TCP
ssh     807 root 1014u  sock     0,8      0t0 2078751 protocol: TCP
ssh     807 root 1015u  sock     0,8      0t0 2076894 protocol: TCP
.....

$lsof -p 807 | wc -l
1047

$ cat /etc/hosts
127.0.0.1   localhost
127.0.1.1   malcolm-desktop

$ssh localhost
Welcome to Ubuntu 14.04.2 LTS (GNU/Linux 3.13.0-53-generic i686)

----after restart ssh -D 8081 localhost
$ lsof -p 1184 | grep TCP
ssh     1184 root    3u  IPv4 2332193      0t0   TCP localhost:37742->localhost:ssh (ESTABLISHED)
ssh     1184 root    4u  IPv6 2332197      0t0   TCP ip6-localhost:tproxy (LISTEN)
ssh     1184 root    5u  IPv4 2332198      0t0   TCP localhost:tproxy (LISTEN)
ssh     1184 root    6u  IPv4 2332215      0t0   TCP localhost:tproxy->localhost:60136 (ESTABLISHED)
ssh     1184 root    7u  IPv4 2336142      0t0   TCP localhost:tproxy->localhost:32928 (CLOSE_WAIT)
ssh     1184 root    8u  IPv4 2336062      0t0   TCP localhost:tproxy->localhost:32880 (CLOSE_WAIT)

— diyism
स्रोत

0

मेरे ब्लॉग में यह प्रविष्टि लिखते समय मुझे यह त्रुटि मिली :

/etc/ssh/sshd_config कुछ इस तरह था:

Match Group SSHTunnel_RemoteAccessGroup
    AllowTcpForwarding yes
    PermitOpen=sshbeyondremote.server.com:22

लेकिन ~/.ssh/configथा:

Host remote.server.com
  HostName remote.server.com
  Port 10022
  User useronremote
  IdentityFile ~/.ssh/keys/key1/openssh.keyforremote.priv
  LocalForward 2222 SSHBeyondRemote.server.com:22

SSHBeyondRemote.server.com:22 और sshbeyondremote.server.com:22 के बीच मामले (पूंजीकरण) के अंतर पर ध्यान दें ।

एक बार मामला तय करने के बाद, मैंने अब इस मुद्दे को नहीं देखा।

मैं उपयोग कर रहा था:

OpenSSH क्लाइंट का संस्करण:

OpenSSH_7.2p2 Ubuntu-4ubuntu2.4, OpenSSL 1.0.2g 1 Mar 2016

OpenSSH सर्वर का संस्करण:

OpenSSH_7.6p1 डेबियन -4, ओपनएसएसएल 1.0.2 एन 7 दिसंबर 2017

— Zach Pfeffer
स्रोत

1

यदि आप लिंक करने, प्रचार करने, उद्धरण देने या किसी ऐसी चीज़ का संदर्भ देने जा रहे हैं, जिसके साथ आप संबद्ध हैं, तो आपको स्पष्ट रूप से उस संबद्धता का खुलासा करना होगा। एक साथ डालते हुए '' कहना (लिंक) '' पर्याप्त नहीं है (क्योंकि मुझे समझ नहीं आया कि इसका क्या मतलब है जब तक मुझे पता नहीं चला कि आप अपने खुद के ब्लॉग से लिंक कर रहे थे); ऐसा URL होना जो आपके Stack Exchange उपयोगकर्ता नाम से मेल खाता हो, पर्याप्त नहीं है। संदर्भ: कैसे एक स्पैमर नहीं हो सकता है , आत्म-प्रचार से बचें ,… (Cont'd)

— स्कॉट

(Cont'd) ... और हमें संबद्धता आवश्यकता कब लागू करनी चाहिए?    आप अपने ब्लॉग, अपने नियोक्ता, आपके द्वारा विकसित किए गए किसी भी प्रसिद्ध सॉफ़्टवेयर, आपके द्वारा लिखी गई कोई भी पुस्तक, आपके द्वारा की गई कोई भी अन्य परियोजनाएं, जो आपके उपयोगकर्ता प्रोफ़ाइल पृष्ठ पर हैं , आदि के साथ संबद्ध हैं, आदि का उल्लेख करने के लिए स्वतंत्र हैं। ।

— स्कॉट

0

अन्य नाम रिज़ॉल्यूशन कारण: मेरे / etc / मेजबानों के सर्वर के नाम के लिए एक गलत आईपी पता था (स्थानीयहोस्ट के लिए नहीं), जैसे:

127.0.0.1     localhost
192.168.2.45  server.domain.com server

लेकिन कॉन्फ़िगर सर्वर आईपी (और होस्ट / डिग कमांड के साथ हल DNS नाम) 192.168.2.47 था। एक साधारण टाइपो, जो पिछले IP पुन: संयोजन के कारण होता है। फिक्सिंग / आदि / होस्ट करने के बाद सुरंग कनेक्शन ने त्रुटिपूर्ण रूप से काम किया:

ssh user@server.domain.com -L 3456:127.0.0.1:5901

यह अजीब है कि वास्तविक आईपी विफलता का कारण बना जब मैं सुरंग के लिए लोकलहोस्टल शाब्दिक आईपी का उपयोग कर रहा था। डिस्ट्रो: उबंटू 16.04 एलटीएस।

— Fjor
स्रोत

0

मेरे पास उस संदेश का कारण सबसे आम नहीं है, लेकिन यह उल्लेख के लायक है। मैंने स्क्रिप्ट द्वारा सुरंगों की एक सूची तैयार की थी, और एक कॉलम प्रस्तुति सुनिश्चित करने के लिए, मैंने प्रत्येक अंतिम बाइट को दो बाइट्स पर मुद्रित किया था। जब मैंने 192.168.66.08 को अग्रेषित करने वाली सुरंग को खोलने की कोशिश की, तो यह हमेशा विफल रही, क्योंकि '08' की व्याख्या एक अवैध अष्टक संख्या के रूप में gethostbyaddr द्वारा की गई है :)

— फिलिप डी मुइटर
स्रोत

0

ऐसा लगता है कि इस संदेश के कई संभावित कारण हैं। मेरे मामले में यह रिमोट का उपयोग करने में असमर्थता थी क्योंकि मैंने कीफाइल को सही तरीके से प्रदान नहीं किया था ।

-Lविकल्प एक अंतर्निहित SSH कूद (प्रभावी रूप से एक गढ़ / कूद सर्वर के रूप में स्पष्ट SSH मेजबान का प्रयोग करके) कहते हैं। यह स्पष्ट रूप से कूद प्रदर्शन करके और "प्रॉक्सीकॉम" का उपयोग करके लक्ष्य मशीन में एक लॉगिन शेल बनाकर डीबग करना आसान हो सकता है।

एक बार जब यह काम कर रहा है, तो आप लक्ष्य मशीन के आधार पर पोर्ट को आगे कर सकते हैं localhost(यह मानते हुए कि यह स्वयं लॉग इन कर सकता है):

-N -L 1234:localhost:1234

— nobar
स्रोत