sftp একটি ত্রুটি দেয়: "বার্তাটি খুব দীর্ঘ পেয়েছে" এবং এর কারণ কী?

Question

আমি sftpগতকাল একটি RHEL 5.4 বাক্সে (রেডহ্যাট) করতে পেরেছিলাম এবং আজ আমি পারছি না।

বার্তাটি হ'ল "Received message too long 778199411", এবং কিছু তদন্তের পরে, এটি আমার আরএইচইএল বাক্সটির .bashrcএকটি লাইন থাকার কারণে echo "running .bashrc"- বা কিছুতেই প্রতিধ্বনিত হয়েছে বলে আমি মনে করি।

সুতরাং কেন একটি লাইন মুদ্রণ প্রভাবিত করবে sftp? এটি কিছুটা যেমন ডিজাইন ইস্যুর মতো অনুভূত হয়েছিল .bashrcযেমন লগ ইন বা অন্য পরিস্থিতিতে যেমন কাজ করে তার মধ্যে একটি লাইন ছাপিয়ে দেয় sshএবং যখন sftpএইরকম অদ্ভুত কারণে ব্যর্থ হয় তখন ট্র্যাক ডাউন করা একধরনের কাজ।

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

Comments

stackoverflow.com/questions/12440287/…

— কোয়ান্টা

Answer 1

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

যদি আমি "sftp / scp ব্যর্থ হয় তবে ssh ঠিক আছে" অনুসন্ধান করে থাকি তবে সমাধানের তাড়াতাড়ি মনে করিয়ে দেওয়া হত!

সহজভাবে বলুন, .bashrc এবং .bash_profile ইত্যাদি চুপ করে থাকতে হবে বা তারা sftp / scp সংযোগ প্রোটোকলে হস্তক্ষেপ করবে।

ওপেন-এসএসএইচ এফএকিউ দেখুন:

2.9 - sftp / scp সংযোগে ব্যর্থ হয়, তবে ssh ঠিক আছে।

Comments

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

— এরিক পি।

এর জন্য ধন্যবাদ, আমার বাশার্কে থাকা কিছু ডিবাগিং ইকো স্টেটমেন্টগুলি সরিয়ে আমার পক্ষে এটি সমাধান করেছে ash

— SgtPooki

ভুল .bashrc নিঃশব্দ হওয়া দরকার, .bash_profile কোনও সমস্যা ছাড়াই প্রতিধ্বনিত করতে পারে।

— কুবানচেক

যে কেউ এখানে অবতরণ করছে: যেমন সার্ভারসফল্ট / এ / 30৩০7১ in এ পরামর্শ দেওয়া হয়েছে , আপনি নিজের এসএসএসেরssh yourhost /usr/bin/true আউটপুট অনুসন্ধান করতে ব্যবহার করতে পারেন । আমার ক্ষেত্রে, আমি command / .bashrc এ কিছু কমান্ড পেয়েছি ত্রুটি তৈরি করতে শুরু করেছি।

— ইউভাল আতজমন

Answer 2

কমপক্ষে এসএফটিপি internal-sftp-র ক্ষেত্রে এটি সাবসিস্টেম ব্যবহার করে স্থির করা যেতে পারে , কারণ এটি পড়ে না .bashrcবা /etc/motd।

কেবল /etc/ssh/sshd_configফাইলটি পরিবর্তন করুন এবং এসএফটিপি সাবসিস্টেমটি পরিবর্তন করুন:

#Subsystem sftp /usr/lib/openssh/sftp-server
Subsystem sftp internal-sftp

এবং ত্রুটি চলে গেছে।

Comments

আমি এইটি পছন্দ করি .. একটু ভাবলে এর কোনও সুরক্ষিত প্রভাব আছে কিনা?

— রায়এম

internal-sftpএটি, আইএমও, এসএফটিপি সমর্থন দেওয়ার আরও ভাল উপায়। আপনি এই সম্পর্কিত পোস্টটি দেখতে পারেন: serverfault.com/questions/660160/…

— কেনেথ

আপনার sshd_config পরিবর্তনের পরামর্শের পরে, আমি sshd এবং sftp হত্যা করেছি (নিশ্চিত যে সেখানে কোনও ভূত আছে কিনা)। প্রথম বার প্রাপ্ত বার্তাটি খুব দীর্ঘ ত্রুটি পেয়েছে তবে যাইহোক লগইন হয়েছিল। তারপরে একই সমস্যাটিতে ফিরে আসুন

— অক্টোবর'১৮: ১-০ clear

Answer 3

আমি যে কোনও জায়গায় এই সমস্ত দাবী দেখেছি প্রতিটি দাবী এটি /etc/motd, বা .bashrc, ইত্যাদির মাধ্যমে খুব বেশি মুদ্রিত আউটপুট always সবসময় সত্য নয়। আপনি যদি একটি একাউন্ট আছে যা কোন যদি .bashrc, /etc/motdখালি থাকে, এবং ডিফল্ট .bashrcহল ন্যূনতম কোন মুদ্রিত আউটপুট আপনি এখনও সমস্যা আছে করতে পারেন। যদি আপনার শেল সহ কোনও ব্যবহারকারী অ্যাকাউন্ট থাকে /sbin/nologinবা /bin/falseএই ত্রুটিটি এখনও ঘটবে।

কেন আপনি এই ??? যদি আপনি রুট-কারাগারে কাউকে মঞ্জুরি দেওয়ার চেষ্টা করছেন তবে sftpকোনও সুরক্ষিত শেল অ্যাক্সেস না দিয়ে এটি ঘটবে।

আশেপাশে কাজ করুন: sshএগুলি মঞ্জুরি দিন এবং এটিও একটি মূল কারাগারে রাখুন। এটি এমন একটি সমস্যা যার সমাধান করা দরকার ssh, এটি আসতে খুব বেশি দীর্ঘ।

Comments

আমার .বাশার্কে খুব দীর্ঘ কাস্টম আউটপুট দেওয়ার কারণে আমার ঠিক এই সমস্যা হয়েছিল (আমার সেখানে স্ক্রিনফেট আছে)। তবে আমি কীভাবে এটিকে

— এড়ানো যায়

হ্যাঁ, এটি হতে পারে। আপনি ssh পরিবর্তন করতে হবে। আমাদের ক্ষেত্রে এটি শেলের সাথে সমস্যা ছিল। আমরা প্রকৃতপক্ষে রুট-জেলের জন্য বিশেষত একটি এসফটিপি ক্লায়েন্ট ব্যবহার করেছি সুতরাং সমস্ত রুট-জেল স্টাফ করার দরকার নেই।

— টেকঅপস

মুল বক্তব্যটি হ'ল আমি আমার .bashrc পরিবর্তন করতে চাই না। আমি প্রথম বার্তার যে কোনও দৈর্ঘ্যের সাথে সার্ভারের সাথে সংযোগ করতে চাই। সুতরাং আমার আইডিই সম্ভবত সেটিংস সংশোধন করতে হবে

— ভ্লাদক্রেস

Answer 4

কেবলমাত্র রিমোট মেশিনে আইডি-র ব্যবহারকারীর ব্যবহারের জন্য ~ / .bashrc শীর্ষে রাখুন যদি সেই আইডি ব্যাশ ব্যবহার করে

# If not running interactively, don't do anything and return early
[[ $- == *i* ]] || return  

যা পুরো ফাইলটি সোর্সিংয়ের পরিবর্তে কেবল ~ / .bashrc থেকে প্রারম্ভিকভাবে প্রস্থান করে ... আপনি যখন সেই আইডিতে লগইন করছেন না এবং কেবলমাত্র আপনার স্ক্রিপ বা এসএফটিপিটি সেই ব্যবহারকারীর নাম দিয়ে রিমোট আইডি হিসাবে চালাচ্ছেন ... অন্য উত্তরগুলিতে @ পিটার স্কটকে উদ্ধৃত করার জন্য: "সহজ ভাষায় বলুন, .bashrc এবং .Bash_profile ইত্যাদি চুপ করে থাকতে হবে বা তারা sftp / scp সংযোগ প্রোটোকলে হস্তক্ষেপ করবে।"

বিকল্পভাবে, যদি সেই দূরবর্তী আইডি zsh ব্যবহার করে তবে তার ~ / .zshrc এর উপরে নীচে রাখুন

# If not running interactively, don't do anything and return early
[[ -o interactive ]] || exit 0

যদি আপনার রিমোট মেশিনের শেলটি ~ / .bashrc ব্যবহার না করে তবে remote / .bashrc_profile বা remote /। প্রোফাইলে বা ~ /। প্রোফাইলে বা অনুরূপ যে রিমোট বাক্সে আপনার শেলের সাথে মানানসইভাবে উপরের সম্পাদনা করুন make

Answer 5

এর আরও একটি কারণ থাকতে পারে। ওপেনশ -5.3p1-122.el6.x86_64 সহ আরএইচইএল 6 এ আমরা সন্ধান করেছি, যে লোকাল "সি" এ থাকা অবস্থায় এটি ভুল আচরণ করে। এর সাথে পরিবর্তিত হলে:

export LC_ALL="en_US.UTF-8"

তারপরে sftp সঠিকভাবে আচরণ করে। পূর্ববর্তী ওপেনশ -5.3p1-118 এ আমরা এরকম আচরণ অনুভব করতে পারি নি তাই সম্ভবত এই বিল্ডটিতে এটি কিছু ছোট বাগ রয়েছে।

Comments

এই আপাতদৃষ্টিতে বিজোড় পরামর্শটিই আমার পরিস্থিতির জন্য কাজ করেছিল। ধন্যবাদ!

— jwd630

Answer 6

আমার ক্ষেত্রে এটি কার্যকর করার জন্য আমার উবুন্টুর স্বাগত বার্তাটি অক্ষম করা দরকার।