Sshfs का उपयोग कर सहकर्मी द्वारा कनेक्शन रीसेट

Question

मैं फ्यूज / sshfs माउंट का उपयोग कर रहा हूं जो अब तक ठीक काम करता है। अब मुझे सर्वर सिस्टम को फिर से स्थापित करना पड़ा और अचानक क्लासिक read: Connection reset by peerत्रुटि मिल रही थी । मैं सार्वजनिक कुंजी प्रमाणीकरण का उपयोग कर रहा हूं और अपनी कुंजी को नए इंस्टॉल किए गए सिस्टम में कॉपी कर रहा हूं। सामान्य ssh लॉगिन ठीक काम करता है। मैंने लॉग को डीबग में बदल दिया, लेकिन दुख की बात है कि इससे मुझे कोई उपयोगी जानकारी नहीं मिली:

sshd[2077]: debug1: Forked child 2198.
sshd[2198]: Set /proc/self/oom_score_adj to 0
sshd[2198]: debug1: rexec start in 5 out 5 newsock 5 pipe 7 sock 8
sshd[2198]: debug1: inetd sockets after dupping: 3, 3
sshd[2198]: Connection from 192.168.1.6 port 47991
sshd[2198]: debug1: Client protocol version 2.0; client software version OpenSSH_6.1p1 Debian-4
sshd[2198]: debug1: match: OpenSSH_6.1p1 Debian-4 pat OpenSSH*
sshd[2198]: debug1: Enabling compatibility mode for protocol 2.0
sshd[2198]: debug1: Local version string SSH-2.0-OpenSSH_6.1p1 Debian-4
sshd[2198]: debug1: permanently_set_uid: 103/65534 [preauth]
sshd[2198]: debug1: list_hostkey_types: ssh-rsa,ssh-dss,ecdsa-sha2-nistp256 [preauth]
sshd[2198]: debug1: SSH2_MSG_KEXINIT sent [preauth]
sshd[2198]: debug1: SSH2_MSG_KEXINIT received [preauth]
sshd[2198]: debug1: kex: client->server aes128-ctr hmac-md5 none [preauth]
sshd[2198]: debug1: kex: server->client aes128-ctr hmac-md5 none [preauth]
sshd[2198]: debug1: expecting SSH2_MSG_KEX_ECDH_INIT [preauth]
sshd[2198]: debug1: SSH2_MSG_NEWKEYS sent [preauth]
sshd[2198]: debug1: expecting SSH2_MSG_NEWKEYS [preauth]
sshd[2198]: Connection closed by 192.168.1.6 [preauth]
sshd[2198]: debug1: do_cleanup [preauth]
sshd[2198]: debug1: monitor_read_log: child log fd closed
sshd[2198]: debug1: do_cleanup
sshd[2198]: debug1: Killing privsep child 2199

क्या किसी को इस बात का अंदाजा है कि मैं यहां क्या याद कर रहा हूं?

अद्यतन करें

auth.logडिबग स्तर 3 के साथ:

sshd[2455]: debug3: fd 5 is not O_NONBLOCK
sshd[2455]: debug1: Forked child 2456.
sshd[2455]: debug3: send_rexec_state: entering fd = 8 config len 751
sshd[2455]: debug3: ssh_msg_send: type 0
sshd[2455]: debug3: send_rexec_state: done
sshd[2456]: debug3: oom_adjust_restore
sshd[2456]: Set /proc/self/oom_score_adj to 0
sshd[2456]: debug1: rexec start in 5 out 5 newsock 5 pipe 7 sock 8
sshd[2456]: debug1: inetd sockets after dupping: 3, 3
sshd[2456]: Connection from 192.168.1.6 port 50037
sshd[2456]: debug1: Client protocol version 2.0; client software version OpenSSH_6.1p1 Debian-4
sshd[2456]: debug1: match: OpenSSH_6.1p1 Debian-4 pat OpenSSH*
sshd[2456]: debug1: Enabling compatibility mode for protocol 2.0
sshd[2456]: debug1: Local version string SSH-2.0-OpenSSH_6.1p1 Debian-4
sshd[2456]: debug2: fd 3 setting O_NONBLOCK
sshd[2456]: debug2: Network child is on pid 2457
sshd[2456]: debug3: preauth child monitor started
sshd[2456]: debug3: privsep user:group 103:65534 [preauth]
sshd[2456]: debug1: permanently_set_uid: 103/65534 [preauth]
sshd[2456]: debug1: list_hostkey_types: ssh-rsa,ssh-dss,ecdsa-sha2-nistp256 [preauth]
sshd[2456]: debug1: SSH2_MSG_KEXINIT sent [preauth]
sshd[2456]: debug1: SSH2_MSG_KEXINIT received [preauth]
sshd[2456]: debug2: kex_parse_kexinit: ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1 [preauth]
sshd[2456]: debug2: kex_parse_kexinit: ssh-rsa,ssh-dss,ecdsa-sha2-nistp256 [preauth]
sshd[2456]: debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,[e-mail] [preauth]
sshd[2456]: debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,[e-mail] [preauth]
sshd[2456]: debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,[e-mail],hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,[e-mail],hmac-sha1-96,hmac-md5-96 [preauth]
sshd[2456]: debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,[e-mail],hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,[e-mail],hmac-sha1-96,hmac-md5-96 [preauth]
sshd[2456]: debug2: kex_parse_kexinit: none,[e-mail] [preauth]
sshd[2456]: debug2: kex_parse_kexinit: none,[e-mail] [preauth]
sshd[2456]: debug2: kex_parse_kexinit:  [preauth]
sshd[2456]: debug2: kex_parse_kexinit:  [preauth]
sshd[2456]: debug2: kex_parse_kexinit: first_kex_follows 0  [preauth]
sshd[2456]: debug2: kex_parse_kexinit: reserved 0  [preauth]
sshd[2456]: debug2: kex_parse_kexinit: ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1 [preauth]
sshd[2456]: debug2: kex_parse_kexinit: [e-mail],[e-mail],[e-mail],ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,[e-mail],[e-mail],[e-mail],[e-mail],ssh-rsa,ssh-dss [preauth]
sshd[2456]: debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,[e-mail] [preauth]
sshd[2456]: debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,[e-mail] [preauth]
sshd[2456]: debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,[e-mail],hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,[e-mail],hmac-sha1-96,hmac-md5-96 [preauth]
sshd[2456]: debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,[e-mail],hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,[e-mail],hmac-sha1-96,hmac-md5-96 [preauth]
sshd[2456]: debug2: kex_parse_kexinit: none,[e-mail],zlib [preauth]
sshd[2456]: debug2: kex_parse_kexinit: none,[e-mail],zlib [preauth]
sshd[2456]: debug2: kex_parse_kexinit:  [preauth]
sshd[2456]: debug2: kex_parse_kexinit:  [preauth]
sshd[2456]: debug2: kex_parse_kexinit: first_kex_follows 0  [preauth]
sshd[2456]: debug2: kex_parse_kexinit: reserved 0  [preauth]
sshd[2456]: debug2: mac_setup: found hmac-md5 [preauth]
sshd[2456]: debug1: kex: client->server aes128-ctr hmac-md5 none [preauth]
sshd[2456]: debug2: mac_setup: found hmac-md5 [preauth]
sshd[2456]: debug1: kex: server->client aes128-ctr hmac-md5 none [preauth]
sshd[2456]: debug1: expecting SSH2_MSG_KEX_ECDH_INIT [preauth]
sshd[2456]: debug3: mm_key_sign entering [preauth]
sshd[2456]: debug3: mm_request_send entering: type 5 [preauth]
sshd[2456]: debug3: mm_key_sign: waiting for MONITOR_ANS_SIGN [preauth]
sshd[2456]: debug3: mm_request_receive_expect entering: type 6 [preauth]
sshd[2456]: debug3: mm_request_receive entering [preauth]
sshd[2456]: debug3: mm_request_receive entering
sshd[2456]: debug3: monitor_read: checking request 5
sshd[2456]: debug3: mm_answer_sign
sshd[2456]: debug3: mm_answer_sign: signature 0x7f9b687c7680(100)
sshd[2456]: debug3: mm_request_send entering: type 6
sshd[2456]: debug2: monitor_read: 5 used once, disabling now
sshd[2456]: debug2: kex_derive_keys [preauth]
sshd[2456]: debug2: set_newkeys: mode 1 [preauth]
sshd[2456]: debug1: SSH2_MSG_NEWKEYS sent [preauth]
sshd[2456]: debug1: expecting SSH2_MSG_NEWKEYS [preauth]
sshd[2456]: Connection closed by 192.168.1.6 [preauth]
sshd[2456]: debug1: do_cleanup [preauth]
sshd[2456]: debug3: PAM: sshpam_thread_cleanup entering [preauth]
sshd[2456]: debug1: monitor_read_log: child log fd closed
sshd[2456]: debug3: mm_request_receive entering
sshd[2456]: debug1: do_cleanup
sshd[2456]: debug3: PAM: sshpam_thread_cleanup entering
sshd[2456]: debug1: Killing privsep child 2457

अद्यतन करें

मैंने एक मैनुअल sshfsमाउंट की कोशिश की और मुझे भी मिला read: Connection reset by peer। मैंने तब डिबगिंग विकल्पों को जोड़ा और मिला भी Permission denied (publickey).। यह अजीब है क्योंकि सार्वजनिक कुंजी जगह में है और अन्यथा ठीक काम करती है। मैं ssh कनेक्शन के लिए अपने उपयोगकर्ता का उपयोग करता हूं और निजी कुंजी फ़ाइल को मैन्युअल रूप से निर्दिष्ट करता हूं। क्या यह रूट खाता के साथ एक समस्या हो सकती है जो सर्वर पर सही सार्वजनिक कुंजी तक पहुंचने में सक्षम नहीं है? मैं अमल कर रहा हूं

sudo sshfs myuser@myserver:/mnt/foo /mnt/foo -o IdentityFile=/home/myuser/.ssh/id_rsa

और प्रासंगिक लॉग भाग है

debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /home/myuser/.ssh/id_rsa
debug1: Authentications that can continue: publickey
debug1: No more authentication methods to try.
Permission denied (publickey).
read: Connection reset by peer

Comments

आउटपुट बिल्कुल एक ssh सत्र से एक जैसा दिखता है जो सर्वर कुंजी फिंगरप्रिंट बेमेल (या अज्ञात कुंजी) के कारण कनेक्ट करने से इनकार करता है। क्या sftpसर्वर सही तरीके से काम करता है?

— पेट्रोफ

मैंने Nautilus ( Connect to Server...विकल्प) और Filezilla दोनों के साथ sftp की कोशिश की । यह बढ़िया काम करता है। हालांकि फाइलज़िला ने मुझसे एक अज्ञात होस्ट कुंजी के बारे में पूछा।

— एंड्रे स्टैनक

sftpसीधे कोशिश करें - यही SSHFS उपयोग करता है।

— पीटर ऑक्ट

मुझे वही दिखता है। क्या आपने क्लाइंट से कुछ डिबगिंग जानकारी प्राप्त करने की कोशिश की है? sshfs -odebug,sshfs_debug,loglevel=debug ...चाल कर सकता है ( sourceforge.net/apps/mediawiki/fuse/index.php?title=SshfsFaq से लिया गया )।

— पेट्रोफ

@peterph को पहले ही यह विचार मिल गया था ;-) मेरा दूसरा अपडेट देखें। मैंने यहां पोस्ट की गई कमांड में डिबग पैरामीटर को छोड़ दिया लेकिन मैंने इसे उनके साथ निष्पादित किया।

— एंड्रे स्टैनक

Answer 1

मैं -F /path/to/configविकल्प का उपयोग कर रहा था । जवाब मेरी कॉन्फिग फाइल में था जहां मेरे पास था

IdentityFile ~/.ssh/id_rsa

जो काम नहीं किया। पूर्ण पथ की आवश्यकता है:

IdentityFile /home/user/.ssh/id_rsa

Comments

man ssh-configस्पष्ट रूप IdentityFile

— चार्ल्सबी

@CharlesB मैंने दोनों तरीकों से इसका परीक्षण किया है और मैं आपको विश्वास दिलाता हूं कि मेरा उत्तर मान्य है। और मैं देखता हूं कि आप मैन पेजों में क्या संदर्भित कर रहे हैं। शायद यह एक बग है जब सूडो के साथ चल रहा है? (क्योंकि मैं हूं)

— सांचके दलोदर

यकीन है, अगर आप sudo के साथ sshfs चला रहे हैं, तो tilde रूट यूजर का घर है। फिर आपको पूर्ण पथ निर्दिष्ट करने की आवश्यकता है।

— चार्ल्सबी

यहां तक ​​कि अगर आप अपनी ~/.ssh/configफ़ाइल में पूर्ण पथ का उपयोग करते हैं, तो sudo sshfsडिफ़ॉल्ट रूप से रीड रूट की /root/.ssh/configफ़ाइल (यदि कोई हो) चल रही होगी । आपको अपनी कॉन्फ़िग फ़ाइल के माध्यम से स्पष्ट रास्ता पास करना होगा -F।

— डैन डस्केल्सस्कु

Answer 2

बहुत अधिक प्रयास करने के बाद यह पता चला कि मेरा ग्राहक उपयोगकर्ता fuseसमूह में नहीं था । के बाद मैंने इसे sudo usermod -a -G fuse myuserमाउंट के साथ जोड़ा फिर से ठीक काम करता है। सर्वर को फिर से स्थापित करने से पहले यह कैसे काम कर सकता है, मुझे मत पूछो। आपकी सभी मदद के लिए धन्यवाद!

Comments

यह स्थानीय या दूरस्थ फ़ाइल सिस्टम पर उपयोगकर्ता है?

— वुड्रो बारलो

@WoodrowBarlow ईमानदार होने के लिए मैं अब और नहीं जानता: डी मेरा सबसे अच्छा अनुमान स्थानीय होगा, क्योंकि यह वह जगह है जहां आप फ्यूज का उपयोग करते हैं।

— एंड्रे स्टैनक

याgpasswd --add USER fuse

— deceleratedcaviar

मेरे मामले में, मुझे बस पोर्ट नंबर की आवश्यकता थी। यह -pविकल्प के साथ जोड़ा गया था ।

— विरोधाभास २

Answer 3

चूँकि यह त्रुटि संदेश ssh कनेक्शन के विफल होने पर डिफ़ॉल्ट होता है, इसलिए सबसे सामान्य उत्तर (प्रति @ टिप्पणी के अनुसार) कम से कम उपयोग करके जांच करना है -odebug:

sshfs -odebug,sshfs_debug,loglevel=debug ...

उदाहरण के लिए

sshfs -odebug,sshfs_debug,loglevel=debug -o Ciphers=arcfour -o Compression=no -o allow_root -o transform_symlinks localhost:/ /mnt/your_mount_point

के रूप में कहीं और कहा, सामान्य कारणों में लापता शामिल allow_otherमें fuse.confया लापता fuseसमूह सदस्यता (हालांकि कि उबंटू 18.04 पर अब कोई आवश्यकता नहीं किया जा सकता है?)

मेरे मामले में यह छपा:

SSHFS version 2.8 FUSE library version: 2.9.7 nullpath_ok: 0 nopath: 0 utime_omit_ok: 0 executing <ssh> <-x> <-a> <-oClearAllForwardings=yes> <-ologlevel=debug> <-oIdentityFile=~/.ssh/id_rsa> <-oCiphers=arcfour> <-oCompression=no> <-2> <localhost> <-s> <sftp> command-line line 0: Bad SSH2 cipher spec 'arcfour'. read: Connection reset by peer

... एक असमर्थित सिफर विकल्प की ओर इशारा करते हुए (फेडोरा पर काम कर रहे हैं, लेकिन उबंटू नहीं)

Comments

उपयोग करते हुए -o debug, मुझे कमांड-लाइन लाइन 0

— सलाथिल जीनस

Answer 4

मेरा आज भी यही मुद्दा था। sshकनेक्शन ठीक है, sshfsनहीं है। मेरा SSH सर्वर Qnap NAS (TS-228) है।

NAS डिवाइस पर SFTP को सक्षम करके समस्या को ठीक किया गया था ।

अतिरिक्त सेटिंग में दिखाई दिया sshd_config:

Subsystem sftp /usr/libexec/sftp-server

Comments

वह समाधान मेरे काम नहीं आता। इसलिए मैं कोशिश करने के लिए कुछ और होने की सराहना करता हूं।

— हेजहोग

मेरे Synology NAS पर SFTP को सक्षम करने से मेरे लिए त्रुटि का समाधान भी हुआ। माउंट किए गए फ़ोल्डर में प्रदर्शित सामग्री के समान नहीं है, सीधे ssh के माध्यम से कनेक्ट करते समय। फ़ोल्डर अनुपलब्ध हैं और रूट तक पहुँचा नहीं जा सकता। ओह।

— हेनरिक उलब्रिच

Answer 5

मुझे अपनी समस्या मिली, जो कि इसी तरह की थी, फ्यूज विन्यास फाइल के साथ करना था:

/etc/fuse.conf

मुझे अन-कमेंट करना पड़ा:

user_allow_other

Answer 6

बस अगर कोई इस धागे पर ठोकर खाता है: मुझे यह read: Connection reset by peerत्रुटि आई क्योंकि होस्ट नाम रिज़ॉल्वेबल नहीं था (मैं पूरी तरह से योग्य होस्ट का उपयोग नहीं कर रहा था)। सही होस्ट नाम का उपयोग करने से समस्या हल हो गई - त्रुटि संदेश अभी पूरी तरह से भ्रामक है।

Sshfs कमांड चलाने से पहले मशीन से एक अच्छा परीक्षण किया जाता है, अगर वह भी काम नहीं करता है तो sshfs काम भी नहीं करेगा।

Comments

sshfs सर्वर-ssh-alias: / some / dir / mnt ने मेरे लिए काम नहीं किया, लेकिन sshfs real.servername.org:/some/dir / mnt ने मेरे लिए काम किया। (user_allow_other के साथ संयुक्त)

— ब्रायन सी।

Answer 7

मुझे यह त्रुटि मिली और उपरोक्त तरीकों की कोशिश की और इसे काम करने में विफल रहा।

समस्या यह थी कि सर्वर 22 पोर्ट पर ssh को स्वीकार नहीं कर रहा था। मैंने इस्तेमाल किया:

$sshfs -p 2222 user@server:/path/to/folder ~/local/path

और इसने इस मुद्दे को हल कर दिया।

Comments

कृपया बिना कहे नीचे न करें। यह जाँच करने के लिए एक उचित बात है।

— हेजहोग

Answer 8

मेरा एरर सर्वराइड था। Sshd के लिए sftp सबसिस्टम जाहिरा तौर पर नए सेंटोस 7.6.xx पर उपलब्ध नहीं है। निम्नलिखित के सामने / etc / ssh / sshd_config से "#" हटाकर तय किया गया

Subsystem sftp /usr/libexec/openssh/sftp-server

इस मुद्दे को खोजने में मदद करने के लिए -odebug नुस्खा के लिए eddygeek के लिए धन्यवाद। ऊपर GEOM के रूप में समान है लेकिन Qnap के लिए विशिष्ट नहीं है।

Answer 9

दौड़ते समय एक ही त्रुटि हुई sudo sshfs [...] myhost: /mnt/myhost, myhostमेरी ~/.ssh/configफाइलों में कहाँ परिभाषित है ।

समस्या यह है कि रनिंग sudo sshfsमेरे होम डायरेक्टरी में नहीं दिख रही है ~/.ssh/config, लेकिन rootएस में। समाधान के माध्यम से विन्यास फाइल को स्पष्ट रूप से पारित करना था -F:

sudo sshfs -F /home/dandv/.ssh/config [...] myhost: /mnt/myhost

Answer 10

मैंने /home/user/.ssh/ogn_hosts से होस्ट के फ़िंगरप्रिंट को मिटा दिया (वास्तव में पूरी फ़ाइल को हटा दिया गया) और उसने इसे ठीक कर दिया ... क्योंकि फिंगरप्रिंट बदल गया था। होस्ट से कनेक्ट करने के लिए ssh का उपयोग करने का स्पष्ट कारण है कि यह कनेक्ट नहीं कर रहा था।

Answer 11

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

स्विच के साथ वर्बोज़ मोड चालू करें:

-o debug

Answer 12

मेरे पास एक समान मुद्दा था, और जब मैंने नेटवर्क कॉन्फ़िगरेशन की जांच की, तो कुछ ने गेटवे पते को कैसे खो दिया, सिस्टम। इसलिए मैंने नीचे की कमांड चलाई

रूट डिफॉल्ट gw 192.169.0.254 जोड़ें

और फिर सिस्टम को रिबूट करें।

रिबूट के बाद समस्या का समाधान किया जाता है।

Comments

आपको एक खराब गेटवे के साथ "कनेक्शन रीसेट पीयर द्वारा" मिला है?

— जेफ स्कालर

Answer 13

मेरे मामले में यह स्टार्टअप पर एक लंबे समय के बाद सर्वर इंटरफ़ेस नहीं था। सर्वर ट्रंक मोड के साथ सिस्को स्विच पोर्ट से जुड़ा है। चूंकि कोई भी ट्रंक पोर्ट वास्तव में यूपी (आमतौर पर 30 सेकंड से अधिक) बनने से पहले विभिन्न चेक करेगा, इसके परिणामस्वरूप उपरोक्त कनेक्शन रीसेट त्रुटि संदेश हो गया है।

मेरा समाधान स्विच पोर्ट को मोड के साथ एक्सेस करने के लिए बदलना था spanning-tree portfast, क्योंकि मेरे वातावरण में ट्रंक मोड इस सर्वर के लिए अनावश्यक है।

मुझे sshfs के डिबगिंग पैरामीटर का उपयोग करते हुए इस मुद्दे के बारे में भी पता चला।