এসএসএইচ টানেলিং ত্রুটি: "চ্যানেল 1: ওপেন ব্যর্থ হয়েছে: প্রশাসনিকভাবে নিষিদ্ধ: ওপেন ব্যর্থ হয়েছে"

184

যখন আমি এই এসএস টানেলটি খুলি:

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

লোকালহোস্টে চলমান এইচটিটিপি সার্ভারটি অ্যাক্সেস করার চেষ্টা করার সময় আমি এই ত্রুটিটি পেয়েছি: 8984:

channel 1: open failed: administratively prohibited: open failed

এই ত্রুটিটির অর্থ কী এবং আপনি কোন মেশিনে সমস্যাটি সমাধান করতে পারেন?

ssh ssh-tunneling port-forwarding

— নিল
সূত্র

হতে পারে আমি কিছু মিস করছি তবে আপনি কেন একটি এসএসএস ক্লায়েন্ট ব্যবহার করে একটি ওয়েব সার্ভার অ্যাক্সেস করার চেষ্টা করছেন?

— ফাহিম মিঠা

আপনি এখানে কেন X11 (-X বিকল্প) ফরওয়ার্ড করছেন? আপনি যদি কেবল এইচটিটিপি ফরওয়ার্ড করতে চান তবে এটি প্রয়োজনীয় নয়। এবং সাইড নোট হিসাবে আইএমএইচও ssh একাধিক পোর্টে ওয়েবসার্ভের উপলব্ধ করার জন্য ভুল সমাধান হতে পারে।

— মার্সেল জি

29

remoteআমার ক্ষেত্রে এটি " হোস্টনাম সমাধান করতে পারে না" বোঝার অর্থ পেয়েছি ।

— রবএম

3

আপনি নীচের কয়েক ডজন উত্তর থেকে দেখতে পাচ্ছেন, ত্রুটি বার্তাটি খুব সুনির্দিষ্ট সত্ত্বেও, সাধারণ ত্রুটি হিসাবে বোঝা উচিত। সাধারণত, সমাধানটি হ'ল রিমোটে একটি শেল খোলার এবং একই সংযোগের চেষ্টা করা, আসল কারণটি দেখার জন্য। আপনি সর্বাধিক সাধারণ বাস্তব কারণগুলির নীচে উত্তরগুলিতে পাবেন।

— স্টাফেন গৌরিচন

একটি DNS রেজল্যুশন ব্যর্থতা এই ত্রুটি হতে পারে প্লাস সংযোগ পর্যন্ত বরফে পরিণত করা হতে পারে এটা বার আউট: superuser.com/a/700677

— user423430

122

চ্যানেল 1: খোলা ব্যর্থ: প্রশাসনিকভাবে নিষিদ্ধ: খোলা ব্যর্থ

উপরের বার্তাটি আপনার এসএসএইচ সার্ভারকে পাশের চ্যানেল খোলার জন্য আপনার এসএসএইচ ক্লায়েন্টের অনুরোধ প্রত্যাখ্যান করে to এটি বিশেষভাবে থেকে আসে -D, -Lঅথবা -w, যেমন, SSH প্রবাহে পৃথক চ্যানেল জুড়ে ফরওয়ার্ড তথ্য ফেরি করার প্রয়োজন হয়।

যেহেতু আপনি ব্যবহার করছেন -L(এটিও প্রযোজ্য -D), সেখানে দুটি বিকল্প প্রশ্ন রয়েছে যা আপনার এসএসএইচ সার্ভারকে এই অনুরোধটি প্রত্যাখ্যান করে:

AllowTcpForwarding (স্টিভ বুজোনাস যেমন উল্লেখ করেছেন)
PermitOpen

এই বিকল্পগুলি পাওয়া যাবে /etc/ssh/sshd_config। আপনার এটি নিশ্চিত করা উচিত:

AllowTCPForwarding হয় উপস্থিত নেই, মন্তব্য করা হয়, বা সেট করা হয় yes
PermitOpenহয় উপস্থিত নেই, মন্তব্য করা হয়, বা সেট করা হয়েছে any[1]

অতিরিক্ত হিসাবে আপনি যদি সংযোগের জন্য কোনও এসএসএইচ কী ব্যবহার করেন তবে আপনার এসএসএইচ কী-এর সাথে সম্পর্কিত এন্ট্রি বা বিবৃতি [2] ~/.ssh/authorized_keysনেই কিনা তা পরীক্ষা করে দেখতে হবে ।no-port-forwardingpermitopen

আপনার নির্দিষ্ট কমান্ডের সাথে প্রাসঙ্গিক নয়, তবে এই বিষয়টির সাথে কিছুটা প্রাসঙ্গিক হ'ল PermitTunnelবিকল্পটি যদি আপনি -w বিকল্পটি ব্যবহার করার চেষ্টা করছেন।

[1] sshd_config(5)ম্যানপেজে সম্পূর্ণ সিনট্যাক্স ।

[2] authorized_keys(5)ম্যানপেজে সম্পূর্ণ সিনট্যাক্স ।

— hyperair
সূত্র

এখানে কাজ করার জন্য আমি বিশেষত sshd_config এ যা যুক্ত করব: টিসিপিকিপএলাইভ হ্যাঁ অনুমতি দিন টিসিপি ফরওয়ার্ডিং হ্যা পারমিট ওপেন আমার কয়েকটা "ওপেন ব্যর্থ" আছে তবে এটি একটি সাধারণ জিনিস বলে মনে হয়। জিনিসগুলি খুব ভাল কাজ করে।

— পিয়েরে থিবল্ট

4

লক্ষণীয় একটি কোণ: আপনি এসএসএইচ দিয়ে ট্যাপ / টুন ডিভাইস তৈরি করার চেষ্টা করার সময় এই ত্রুটিটি পেতে পারেন এবং এসএসএইচ এটির অনুমতি দেয় তবে কার্নেলটি তা দেয় না। এটি এলএক্সসি পাত্রে হতে পারে। সঠিক বিশদ জানতে ব্লগ.ফেলিক্সব্বার.কম / ২০১৫ / ১১ / ২০১১ / দেখুন দেখুন , তবে সেক্ষেত্রে আপনি আপনার ধারকটিরlxc.cgroup.devices.allow = c 10:200 rwm কনফিগারেশনে যুক্ত করতে চাইতে পারেন এবং নিশ্চিত /dev/net/tunনা mknod /dev/net/tun c 10 200; chmod 666 /dev/net/tunকরে থাকেন যে কনটেইনারটিতে বুটআপ চালানো হচ্ছে।

— আজেন্ডালে

@ আজেন্দে, এটি আকর্ষণীয়, ধন্যবাদ এটি কি একই একই ত্রুটি বার্তা, বা কিছু অন্যরকম দেয়?

— হাইপায়ার

1

@ সেন্ট অ্যান্টারিও, AllowTcpForwardingআপনাকে এসএসএইচে টিসিপি বন্দরগুলি ফরোয়ার্ড করার অনুমতি দেয়, যা -L 0.0.0.0:8984:remote:8983প্যারামিটারটি অনুরোধ করছে। যদি AllowTcpForwardingসেট করা থাকে no, এসএসএইচ পোর্ট ফরোয়ার্ডিংয়ের অনুরোধটিকে প্রত্যাখ্যান করবে, যার ফলে আপনি সেই ত্রুটিটি দেখছেন।

— হাইপায়ার

2

উপরের ক্ষেত্রে এটি সম্পাদনা করার চেষ্টা করা AllowTCPForwardingহয়েছে AllowTcpForwarding, তবে এসই কমপক্ষে 6 টি অক্ষর পরিবর্তন করতে চায়। সুতরাং শুধু লক্ষণীয় যে সঠিক ক্ষেত্রেটি হ'ল Tcpসংস্করণ, যেমন প্রথমবার সঠিকভাবে ব্যবহৃত হয়েছিল।

— dbreaux

51

খুব অদ্ভুত ক্ষেত্রে, একটি স্থানীয় টানেল তৈরি করার চেষ্টা করার সময় আমি এই ত্রুটিটিও অনুভব করেছি। আমার আদেশটি ছিল এরকম কিছু:

ssh -L 1234:localhost:1234 user@remote

সমস্যাটি ছিল, দূরবর্তী হোস্টে, /etc/hosts"লোকালহোস্ট" -র জন্য কোনও প্রবেশ নেই তাই ssh সার্ভারটি কীভাবে টানেলটি সেটআপ করতে হয় তা জানত না। এই ক্ষেত্রে একটি খুব বন্ধুত্বপূর্ণ ত্রুটি বার্তা; খুশি আমি অবশেষে এটি বুঝতে পেরেছি।

পাঠ: নিশ্চিত করুন যে আপনার সুড়ঙ্গ লক্ষ্য হোস্টনাম, দূরবর্তী হোস্ট দ্বারা সমাধানযোগ্য হয় ডিএনএস বা মাধ্যমে করা /etc/hosts।

— cobbzilla
সূত্র

2

ধন্যবাদ, এটি আমার জন্য সমস্যা ছিল। আমি স্থানীয়ভাবে আইপিটির জন্য হোস্টের নাম তৈরি করেছি তবে রিমোট এসএস সার্ভারে নেই।

— ডেভ_ফিড

2

"আপনার টানেলের টার্গেট হোস্টনাম" ডিক্সার করা কিছুটা শক্ত is আপনি কি একটি দৃ concrete় কার্যক্ষম উদাহরণ দিতে পারেন যা আমাকে আপনার উদাহরণটি গ্রহণ করতে এবং আপনার টার্গেটের "টার্গেট হোস্টনাম "টিকে আমার টার্গেটের হোস্টনামের সাথে প্রতিস্থাপন করতে অনুমতি দেবে (একবার আমি বুঝতে পারছি যে আপনি এর অর্থ কী) এবং এই কাজটি করতে চান?

— টেরেন্স ব্র্যানন

1

আপনার মন্তব্যটি অর্থবোধ করে তা আমি নিশ্চিত নই। আপনি বলেছেন যে দূরবর্তী মেশিনটির লোকালহোস্টের জন্য কোনও প্রবেশ ছিল না। তবে তারপরে বলুন যে দূরবর্তী হোস্টকে স্থানীয় হোস্ট-নেম নয় লক্ষ্য হোস্টনামটি সমাধান করতে হবে । আবার পরিস্থিতিগুলির পূর্বে এবং পরে একটি সম্পূর্ণ দৃ concrete় উদাহরণ সহায়ক হবে।

— টেরেন্স ব্র্যানন

1

উপরের কমান্ডে @ টেরেন্স ব্র্যানন, "লোকালহোস্ট" হ'ল টানেলের টার্গেট হোস্টনাম । এসএসএইচ টানেল তৈরি করার সময়, ssh কমান্ড প্রথমে রিমোট সিস্টেমে লগইন করে ( user@remote), তারপরে দূরবর্তী প্রান্ত থেকে, এটি তালিকাভুক্ত লক্ষ্য হোস্টগুলিতে টানেল স্থাপন করে (উপরের কমান্ডটিতে এটি হ'ল localhost)। এটি করার সময়, এটি দূরবর্তী হোস্টের হোস্টনাম রেজোলিউশন স্কিম ব্যবহার করে । সুতরাং আপনি যে মেশিনটি SSH করতে চান তা যদি সমাধান না করতে পারে তবে localhostআপনি এই ত্রুটি বার্তাটি পাবেন।

— কোবজিলা

1

আমার ক্ষেত্রে এটি টার্গেটের হোস্টনামটি ভুল টাইপ করার মতোই সহজ, অবশ্যই এটি সমাধান হয়নি, তবে আমার চোখ টাইপোটি দেখতে খুব বেশিদিন মিস করেছিল।

— র্যান্ডাল

25

কমপক্ষে একটি উত্তর হ'ল মেশিন "রিমোট" কোনও কারণে এসএসএসের সাথে অ্যাক্সেসযোগ্য। ত্রুটি বার্তাটি কেবল অযৌক্তিক।

— নিল
সূত্র

2

না তা নয়; আমি ফায়ারওয়াল কনফিগারেশনে সমস্ত সময় প্রত্যাখাত পতাকা হিসাবে আইসিএমপি-অ্যাডমিন-নিষিদ্ধ ব্যবহার করি।

— শাদুর

9

+1, প্রশাসনিকভাবে নিষিদ্ধ বার্তাটি একজনকে বিশ্বাস করতে বাধ্য করে যে এটি ফায়ারওয়াল ব্লকেজ, যদিও আপনি একই বার্তাটি পান যখন কোনও ফায়ারওয়াল বাধা নেই তবে খোলা ব্যর্থ হয় কারণ দূরবর্তী হোস্টের কোনও রুট নেই।

— স্টিভ বুজনস

1

আমি এই সমস্যাটি শিকারে সবে বেশ কয়েক মিনিট সময় কাটিয়েছি, যার বার্তাটি আমার প্রসঙ্গে কোনও ধারণা দেয় না। ধন্যবাদ, মিডল স্টেশন লগ ফাইলগুলি পরীক্ষা করার পরে এটি বেশ পরিষ্কার।

— ইয়্যাকজ

প্রকৃতপক্ষে যদি "রিমোট" অ্যাক্সেসযোগ্য হয় - কারণ এটি ডাউন, অফলাইন, অস্তিত্বহীন, হোস্টনাম সমাধান করে না - তবে আপনি এই ত্রুটি বার্তাটি দেখতে পাবেন।

— মাইকেল মার্টিনেজ

18

যদি সার্ভারে 'রিমোট' সমাধান করা যায় না তবে আপনি ত্রুটি পাবেন। কোনও আইপি ঠিকানা দিয়ে প্রতিস্থাপন করুন এবং দেখুন এটি আপনার সমস্যার সমাধান করে কিনা ...

(মূলত নীলের মতো একই উত্তর - তবে আমি অবশ্যই আমার পক্ষে এই সমস্যাটি খুঁজে পেয়েছি) [আমার ~/.ssh/configফাইলে মেশিনের নামের জন্য আমার একটি নাম ছিল - এবং রিমোট মেশিনটি ওই ওরফে কিছুই জানত না ...

— jacquesjtheron
সূত্র

আপনি -Dব্রাউজারে (ডায়নামিক ফরোয়ার্ড) এসওকেএসএস প্রক্সি হিসাবে ব্যবহার করার সময়ও একই ত্রুটি দেখতে পাবেন । অর্থাৎ এমন কোনও ওয়েবসাইট অ্যাক্সেস করার চেষ্টা করছেন যা টানেল হোস্ট সমাধান করতে পারে না।

— টিমাস

10

আপনি যখন ssh বিকল্পগুলি ব্যবহার করেন ControlPathএবং ControlMasterবেশ কয়েকটি ক্লায়েন্ট সংযোগের মধ্যে (একটি ক্লায়েন্ট থেকে একই ব্যবহারকারী @ সার্ভারে) পুনরায় ব্যবহার করতে একটি সকেট সংযোগ ভাগ করে নেওয়ার জন্য এই ত্রুটিটি স্পষ্টতই পপ আপ হয় । অনেকগুলি খোলার (এটির অর্থ যাই হোক না কেন, আমার ক্ষেত্রে ~ 20 সংযোগ) এই বার্তাটি দেয়। পূর্ববর্তী কোনও সংযোগ বন্ধ করে দেওয়া আমাকে আরও নতুন সীমাবদ্ধ করতে দেয়।

— মতেজ কোভাক
সূত্র

আমি এই কন্ট্রোলমাস্টার মাল্টিপ্লেক্স সীমাটি কোথায় সেট করবেন তা সন্ধান করতে এখানে এসেছি। যদি কেউ জানে, তারা ভাগ করে নেওয়ার চেয়ে বেশি স্বাগত।

— ক্লেক

1

ক্লেক: bugs.debian.org/cgi-bin/bugreport.cgi?bug=546854 অনুসারে আপনি এটি সেট করতে / etc / ssh / sshd_config ফাইলটিতে একটি ম্যাক্সেশন পরামিতি যুক্ত করতে পারেন। ম্যান পৃষ্ঠা অনুসারে, এটি ডিফল্ট হিসাবে 10 এ সেট করা আছে।

— অলিভার

@ অলিভার: নিশ্চিতকরণ, ম্যাক্সসেশন কাজ করে, ধন্যবাদ। আমার ওয়ার্কবুকটিতে to৪ তে বাম্পড

— মতেজ কোভাক

2

সাবধান, এটা MaxSessionকিন্তু না MaxSessions। যদিও কিছু সুরক্ষা রয়েছে, আপনার

— এসএসএস

8

"প্রশাসনিকভাবে নিষিদ্ধ" হ'ল একটি নির্দিষ্ট আইসিএমপি বার্তা পতাকা যা "প্রশাসক স্পষ্টতই এই সংযোগটি অবরুদ্ধ করতে চায়" -এ ফোটে।

আপনার iptables সেটিংস পরীক্ষা করে দেখুন।

— Shadur
সূত্র

5

অগত্যা। বার্তাটি উত্পন্ন হয় যখন হোস্ট অনুরোধটি পরিবেশন করতে পারে না। কেসটি সাধারণত এজন্য যে অ্যাডমিন সংযোগটি অবরুদ্ধ করেছে, তবে এটি এমনও হতে পারে যে এটি স্পষ্টভাবে অবরুদ্ধ করা হয়নি তবে কাঙ্ক্ষিত হোস্টের কোনও রুট নেই। sshসংযোগ কেন ব্যর্থ হয়েছে তা নির্ধারণের জন্য আফাইকের কোনও যুক্তি নেই, এটি কেবল ধরেই নিয়েছে যে আপনি যদি সংযোগের চেষ্টা করছেন তবে এটি বিদ্যমান এবং আপনি যদি সেখানে না পেতে পারেন তবে অবশ্যই সংযোগটি ইচ্ছাকৃতভাবে অবরুদ্ধ করা হয়েছে।

— স্টিভ বুজোনাস

2

আহ, না। আইসিএমপি প্রতিক্রিয়া ধরণের "হোস্ট করার কোনও রাস্তা নেই" এবং "প্রশাসনিকভাবে নিষিদ্ধ" বলে অভিহিত করার ধরণের মধ্যে একটি আলাদা পার্থক্য রয়েছে এবং যদি না কেউ ইচ্ছাকৃতভাবে কোনও রাউটারের ভুল কনফিগারেশন না করে, তবে দ্বিতীয়টির অর্থ হ'ল টিনের উপরে কী বলে।

— শাদুর

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...

মনে হচ্ছে যে, SSH বোঝে না যে localhostএকটি শর্টকাট হয় 127.0.0.1, অত বার্তা auth.logএবং শাসন ব্যবস্থার নিষিদ্ধ বার্তা।

আমি যা এখানে বুঝতে পারি তা প্রশাসনিকভাবে "সার্ভারের পাশে একটি নির্দিষ্ট কনফিগারেশনের কারণে" মানে means

— lauhub
সূত্র

লোকালহোস্ট সম্ভবত ম্যাপ করেছেন :: 1 (আইপিভি 6) এবং আপনি কোনও কারণে সেখানে শুনছিলেন না

— জো রেট্ট

4

এটাও ঘটে যখন /etc/sshd_configহয়েছে

AllowTcpForwarding no

সেট। yesটিসিপি ফরোয়ার্ডিংয়ের অনুমতি দিতে এটিতে স্যুইচ করুন ।

— user578125
সূত্র

4

আমার ক্ষেত্রে, আমার সাথে প্রতিস্থাপন localhostকরতে 127.0.0.1হয়েছিল:

ssh -L 1234:localhost:3389 user@remote

এটা কাজ করতে.

আমি এসএসএইচ টানেলিংয়ের মাধ্যমে অ্যাডাব্লুএস ইসি 2 এর সাথে সংযোগ স্থাপনের জন্যrdesktop -L localhost:1234 অ্যামাজনের নির্দেশাবলী অনুসরণ করার চেষ্টা করছিলাম । আমি /etc/ssh/sshd_configসর্বোচ্চ ভোট প্রাপ্ত উত্তর প্রতি (ক্লায়েন্ট এবং সার্ভার উভয় উবুন্টু 16.04 এলটিএস) পরিবর্তন করার চেষ্টা করেছি । আমি এটিও উভয় পক্ষের localhostমধ্যে যাচাই করেছিলাম /etc/hosts।

sshকমান্ডটি নিজের মধ্যে পরিবর্তন না করা পর্যন্ত কিছুই কাজ করেনি:

ssh -L 1234:127.0.0.1:3389 user@remote

— tinlyx
সূত্র

তোমাকে অনেক ধন্যবাদ!

— থাইবাট ব্যারারে

3

একটি নির্দিষ্ট উত্তর খুঁজে পেতে কিছু সমস্যা সমাধানের কার্যকলাপ প্রয়োজন:

পোর্ট ফরওয়ার্ডিং ব্যবহারকারীর এসএসএ কনফিগারেশনে সক্ষম হয়েছে কিনা তা দেখুন,
ssh (-v) এর ভারবোসিটি সক্ষম করুন,
স্থানীয় হোস্টে ssh লগ এবং দূরবর্তী একে সুরক্ষিত লগগুলি পরীক্ষা করুন,
বিভিন্ন দূরবর্তী বন্দর পরীক্ষা করুন,
আপনার iptables সেটিংস পরীক্ষা করুন (যেমন শাদুর বলেছিলেন)।

— মার্কো সলিয়েরি
সূত্র

3

রি-রিমোটটি -L প্যারামিটারে রাখার জন্য আমি এই ত্রুটিটি একবার পেয়েছি, এছাড়াও 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.

— Marciano
সূত্র

3

এটি স্থানীয় পাশের বন্দরে বাঁধতে না পারার কারণেও হতে পারে।

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

এই কমান্ডটি স্থানীয় মেশিনে একটি শ্রবণ পোর্ট 1234 বাঁধতে চেষ্টা করছে, যা দূরবর্তী মেশিনে 5678 পোর্টের কোনও পরিষেবাতে মানচিত্র করে।

যদি স্থানীয় মেশিনে 1234 পোর্টটি ইতিমধ্যে অন্য কোনও প্রক্রিয়া দ্বারা ব্যবহৃত হয়, (সম্ভবত কোনও পটভূমি ssh -f সেশন), তবে ssh সেই বন্দরে শুনতে সক্ষম হবে না এবং টানেলটি ব্যর্থ হবে।

সমস্যাটি হ'ল এই ত্রুটি বার্তাটি বেশ কয়েকটি জিনিসকে বোঝাতে পারে এবং "প্রশাসনিকভাবে নিষিদ্ধ" কখনও কখনও ভুল ধারণা দেয়। সুতরাং ডিএনএস, স্থানীয় এবং দূরবর্তীগুলির মধ্যে ফায়ারওয়ালগুলি এবং sshd_config পরীক্ষা করার পাশাপাশি স্থানীয় বন্দরটি ইতিমধ্যে ব্যবহৃত হয়েছে কিনা তা পরীক্ষা করে দেখুন। ব্যবহার

lsof -ti:1234

1234-এ কী প্রক্রিয়া চলছে তা নির্ধারণ করার জন্য। অন্যান্য ব্যবহারকারীর মালিকানাধীন প্রক্রিয়াগুলির তালিকাতে আপনার জন্য সূডোর প্রয়োজন হতে পারে su তারপরে আপনি ব্যবহার করতে পারেন

ps aux | grep <pid>

সেই প্রক্রিয়াটি কী তা খুঁজে বের করতে।

এই সমস্ত এক কমান্ডে পেতে:

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

— Mnebuerquo
সূত্র

2

টানেল দেওয়ার সময় আমারও একই বার্তা ছিল। রিমোট সাইডে ডিএনএস সার্ভারে একটি সমস্যা ছিল। কাজটি ফিরে এসে সমস্যাটি সমাধান করা হয়েছিল।

— লিওনার্দো ব্রুননেট
সূত্র

2

আমি অত্যন্ত অবাক হয়েছি যে কেউ এটি উল্লেখ করেনি যে এটি ডিএনএস সমস্যা হতে পারে।

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

এসএসএইচ এর মাধ্যমে এমন কোনও ব্যবহারকারীর সাথে সংযোগ দেওয়ার চেষ্টা করার সময় আমার এই সমস্যা হয়েছিল যা কেবলমাত্র এসএফটিপি ব্যবহার করে সংযোগ করার জন্য অনুমোদিত ছিল।

উদাহরণস্বরূপ, এটি সার্ভারের মধ্যে ছিল /etc/ssh/sshd_config:

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

সুতরাং এই ক্ষেত্রে, এসএসএইচ ব্যবহার করতে, আপনাকে হয় সমতুল্য sftponlyগোষ্ঠী থেকে ব্যবহারকারীকে সরাতে হবে বা এসএফটিপিতে সীমাবদ্ধ নয় এমন একটি ব্যবহারকারী ব্যবহার করে সংযোগ করতে হবে।

— মাইক
সূত্র

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খালি কেন পরীক্ষা করা উচিত (এটি প্রযোজ্য ক্ষেত্রে সার্ভারে ডিএইচসিপি ক্লায়েন্টের দ্বারা নামধারক রেকর্ডগুলির সাথে সাধারণত রচিত হয়)।

— বাড়ি হইতে বাহিরে
সূত্র

1

এসএসএইচ দেবিয়ানকে সুর দেওয়ার সময় আমি একই বার্তা পাচ্ছিলাম। দেখা গেল রিমোট সিস্টেমে কোনও খালি জায়গা নেই had কিছু ডিস্ক স্থান খালি করা এবং পুনরায় বুট করার পরে, টানেলটি কাজ শুরু করে।

— 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
সূত্র

আফাইক টানেলিংটি ডিফল্টরূপে সক্ষম করা হয় কারণ অক্ষম করা সুরক্ষার কোনও স্তর যোগ করে না, প্রাথমিকভাবে কেবল তৃতীয় পক্ষের টানেল যোগ করার অসুবিধা। কোনও অফ সাইটের অবস্থান থেকে অভ্যন্তরীণ সার্ভারগুলিতে প্রক্সি দেওয়ার চেষ্টা করতে আমার একইরকম সমস্যা হচ্ছে এবং টানেলিং সক্ষম হয়েছে + ডিফল্ট ক্রিয়াকলাপের সাথে আইপটিবলগুলি ফ্লাশ করা হয়েছে ACCEPT।

— স্টিভ বুজনস

@ স্টিভ বুজোনাস আমি এটিকে / etc / sshd_config এ দেখছি সুতরাং ক) এটি টানেলিং অক্ষম করে না খ) আমার উত্তর সম্পর্কে, সমাধানটি সম্ভবত ভাল ধারণা নাও থাকতে পারে। এখানে sshd_config সেই বিকল্পটি সম্পর্কে কী বলেছে # টানেলযুক্ত পরিষ্কার টেক্সট পাসওয়ার্ড অক্ষম করতে এখানে কোনও পরিবর্তন করুন! # পারমিটুনাল নং

— বার্লোপ

@ স্টিভ বুজোনাস আপনার এটি যাচাই করুন এটি সম্ভবত কোনওটি সেট করা আছে এবং আপনি টানেলটি করতে পারেন যেহেতু টানেলটি ডিফল্টরূপে সক্ষম হয়েছে enabled

— বারলপ

আমি ভাবছিলাম AllowTCPForwarding, আপনি যে মন্তব্যটির বিষয়ে কথা বলছেন # To disable tunneled clear textতা PasswordAuthenticationহ'ল সেট করার ক্ষেত্রে, PermitTunnelএটি স্তর 2 বা স্তর 3 নেটওয়ার্কিং টানেলগুলিকে টুন / ট্যাপের মাধ্যমে এবং কোনও ডিফল্টকে অনুমতি দিতে হবে। এল, আর, এবং ডি বিকল্পগুলি টিসিপি ফরোয়ার্ডিং ব্যবহার করে, টানেলের জন্য কোনও ডিভাইস নয়।

— স্টিভ বুজনস

0

অন্য একটি পরিস্থিতি হ'ল আপনি যে পরিষেবাটি অ্যাক্সেস করার চেষ্টা করছেন সেটি চলছে না। আমি অন্য দিন এই সমস্যাটিতে ছুটে এসেছি কেবলমাত্র সেই httpd দৃষ্টান্তটি মনে করার জন্য যা আমি সংযুক্ত হওয়ার চেষ্টা করছিলাম তা বন্ধ হয়ে গিয়েছিল।

সমস্যার সমাধান করার জন্য আপনার পদক্ষেপগুলি হ'ল সহজতমটি দিয়ে শুরু করা, যা অন্য মেশিনে যাচ্ছে এবং আপনি যদি স্থানীয়ভাবে সংযোগ করতে পারেন এবং তারপরে নিজেকে নিজের ক্লায়েন্ট কম্পিউটারের দিকে ফিরে কাজ করতে পারেন তা দেখুন। কমপক্ষে এটি আপনাকে যোগাযোগের কোন পর্যায়ে ঘটছে না তা নিয়ে কাজ করার অনুমতি দেবে। আপনি অন্যান্য পন্থা নিতে পারেন, তবে এটি আমার পক্ষে কাজ করেছে worked

— আন্দ্রে এম
সূত্র

একটি দরকারী সাধারণ টিপ তবে উত্থাপিত প্রশ্নের উত্তর নয়।

— কাইল জোন্স

0

ডিএনএস রিবন্ডিং সুরক্ষার জন্য আপনার রাউটারটি পরীক্ষা করুন । আমার রাউটারে (pfsense) ডিএনএস রিবন্ডিং সুরক্ষা ডিফল্টরূপে সক্ষম হয়েছে। এটি এসএসএইচ সহ 'চ্যানেল উন্মুক্ত: প্রশাসনিকভাবে নিষিদ্ধ: ওপেন ব্যর্থ হয়েছে' ত্রুটির কারণ হয়ে উঠছিল

— meffect
সূত্র

0

আমার একই সমস্যা ছিল এবং আমি বুঝতে পেরেছিলাম যে এটি ডিএনএস। ট্র্যাফিক টানেল করা হয়েছে তবে ডিএনএসের অনুরোধ নেই। আপনাকে ডিএনএস হোস্ট ফাইল ম্যানুয়ালি সম্পাদনা করার চেষ্টা করুন এবং আপনি যে পরিষেবাটি অ্যাক্সেস করতে চান তা যুক্ত করুন।

— উপাত্ত
সূত্র

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 এর মধ্যে কেস (মূলধন) এর পার্থক্যটি নোট করুন ।

একবার আমি মামলাটি স্থির করে ফেললাম, আমি আর সমস্যাটি দেখতে পেলাম না।

আমি ব্যবহার করছিলাম:

ওপেনএসএইচ ক্লায়েন্টের সংস্করণ:

ওপেনএসএসএইচ_7.২ পিপি উবুন্টু -4 বুন্টু 2.4, ওপেনএসএসএল 1.0.2 জি 1 মার্চ ২০১ 2016

ওপেনএসএইচ সার্ভারের সংস্করণ:

ওপেনএসএসএইচ_7.6 পি 1 দেবিয়ান -4, ওপেনএসএসএল 1.0.2n 7 ডিসেম্বর 2017

— জ্যাচ ফেফার
সূত্র

1

আপনি যদি লিখিত, প্রচার, উদ্ধৃতি বা অন্য কোনও বিষয় যা আপনার সাথে অনুমোদিত তা উল্লেখ করতে চলেছেন তবে আপনাকে অবশ্যই এই অধিভুক্তি স্পষ্টভাবে প্রকাশ করতে হবে। 'লিঙ্ক' করার সময় '' বলাই যথেষ্ট নয় (কারণ আমি বুঝতে পারি না যে আপনি নিজের ব্লগে লিঙ্ক করছেন এই বিষয়টি বোঝার পরেও এর অর্থ কী) আমি বুঝতে পারি নি; আপনার স্ট্যাক এক্সচেঞ্জ ব্যবহারকারীর নামের সাথে মেলে এমন একটি URL থাকা যথেষ্ট নয়। তথ্যসূত্র: কীভাবে স্প্যামার হবেন না , স্ব-প্রচারকে এড়িয়ে চলুন , ... (চালিয়ে যান)

— স্কট

(চালিয়ে যাওয়া) ... এবং আমাদের কখন অনুমোদিতকরণের প্রয়োজনীয়তা প্রয়োগ করা উচিত?    আপনি আপনার ব্লগ, আপনার নিয়োগকর্তা, আপনার বিকাশকারী কোনও সুপরিচিত সফ্টওয়্যার, আপনার লেখা যে কোনও বই, আপনি যে কোনও প্রকল্প বা যার সাথে যুক্ত হয়েছেন ইত্যাদি ইত্যাদি নির্ধারণ করতে পারেন আপনার ব্যবহারকারী প্রোফাইল পৃষ্ঠায় ।

— স্কট

0

অন্যান্য নাম সমাধানের কারণ: আমার / ইত্যাদি / হোস্টগুলির সার্ভারের নাম (লোকালহোস্টের জন্য নয়) এর জন্য একটি ভ্রান্ত আইপি ঠিকানা ছিল, যেমন:

127.0.0.1     localhost
192.168.2.45  server.domain.com server

তবে কনফিগার করা সার্ভার আইপি (এবং হোস্ট / ডিগ কমান্ডগুলির সাথে সমাধান হওয়া ডিএনএস নাম) ছিল 192.168.2.47। পূর্ববর্তী আইপি পুনরায় কনফিগারেশনের কারণে একটি সাধারণ টাইপ। / ইত্যাদি / হোস্টগুলি ঠিক করার পরে টানেল সংযোগটি ত্রুটিহীনভাবে কাজ করেছে:

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

এটি অদ্ভুত যে আমি যখন টানেলের জন্য লোকালহোস্ট আক্ষরিক আইপি ব্যবহার করছিলাম তখন আসল আইপি ব্যর্থতার কারণ হয়েছিল। ডিস্ট্রো: উবুন্টু 16.04 এলটিএস।

— Fjor
সূত্র

0

আমার কেন এই বার্তাটি ছিল তা সর্বাধিক সাধারণ নয়, তবে এটি উল্লেখ করার মতো। আমি স্ক্রিপ্টের মাধ্যমে টানেলের একটি তালিকা তৈরি করেছি এবং একটি কলাম উপস্থাপনা নিশ্চিত করতে আমি প্রতিটি শেষ বাইট দুটি বাইটে মুদ্রণ করেছি। আমি যখন 192.168.66.08 এ টানেলটি ফরোয়ার্ড করার চেষ্টা করেছি তখন এটি সর্বদা ব্যর্থ হয়, কারণ '08' গেথস্টব্যাড্ডার দ্বারা একটি অবৈধ অষ্টাল সংখ্যা হিসাবে ব্যাখ্যা করা হয় :)

— ফিলিপ ডি ময়টার
সূত্র

0

মনে হয় এই বার্তাটির অনেকগুলি সম্ভাব্য মূল কারণ রয়েছে। আমার ক্ষেত্রে এটি রিমোট অ্যাক্সেস করতে অক্ষম ছিল কারণ আমি কীফাইলটি সঠিকভাবে সরবরাহ করিনি ।

-Lবিকল্প কোন অন্তর্নিহিত, SSH লাফ (কার্যকরভাবে ঘাঁটি / লাফ সার্ভার স্পষ্ট, SSH হোস্ট ব্যবহার করে) যোগ করা হয়েছে। স্পষ্টভাবে জাম্পটি সম্পাদন করে এবং "প্রক্সি কম্যান্ড" ব্যবহার করে টার্গেট মেশিনে লগইন শেল তৈরি করে এটি ডিবাগ করা সহজ হতে পারে।

একবার এটি কাজ হয়ে গেলে আপনি লক্ষ্য মেশিনের ভিত্তিতে পোর্টটি ফরোয়ার্ড করতে পারেন localhost(ধরে নিলেন এটি নিজেই লগ ইন করতে পারে):

-N -L 1234:localhost:1234

— nobar
সূত্র