scpem mất kết nối, nhưng ssh hoạt động tốt


10

Một máy chủ tôi có thể ssh thành tốt đã bắt đầu từ chối scp.

$ scp ~/tmp/foo user@some.example.com:~/tmp/
lost connection

Với scp -v -vtôi có thể thấy kết nối thành công và chuyển có vẻ thành công, nhưng không có tập tin nào xuất hiện ở phía bên kia.

OpenSSH_5.9p1, OpenSSL 0.9.8r 8 Feb 2011
debug1: Reading configuration data /Users/schwern/.ssh/config
debug1: /Users/schwern/.ssh/config line 1: Applying options for *
debug1: Reading configuration data /etc/ssh_config
debug1: /etc/ssh_config line 20: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to testcurrent01.dev.liquidweb.com [10.30.152.254] port 22.
debug1: Connection established.
debug1: identity file /Users/schwern/.ssh/id_rsa type -1
debug1: identity file /Users/schwern/.ssh/id_rsa-cert type -1
debug1: identity file /Users/schwern/.ssh/id_dsa type -1
debug1: identity file /Users/schwern/.ssh/id_dsa-cert type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_4.3
debug1: match: OpenSSH_4.3 pat OpenSSH_4*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.9
debug2: fd 3 setting O_NONBLOCK
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
...lots of authentication details...
debug1: Enabling compression at level 6.
debug1: Authentication succeeded (publickey).
Authenticated to user@some.example.com ([1.2.3.4]:22).
debug2: fd 5 setting O_NONBLOCK
debug2: fd 6 setting O_NONBLOCK
debug1: channel 0: new [client-session]
debug2: channel 0: send open
debug1: Entering interactive session.
debug2: callback start
debug2: client_session2_setup: id 0
debug2: fd 3 setting TCP_NODELAY
debug1: Sending environment.
debug1: Sending env LANG = en_US.UTF-8
debug2: channel 0: request env confirm 0
debug1: Sending command: scp -v -t -- ~/tmp/
debug2: channel 0: request exec confirm 1
debug2: callback done
debug2: channel 0: open confirm rwindow 0 rmax 32768
debug2: channel 0: rcvd adjust 2097152
debug2: channel_input_status_confirm: type 99 id 0
debug2: exec request accepted on channel 0
debug2: channel 0: rcvd eof
debug2: channel 0: output open -> drain
debug2: channel 0: obuf empty
debug2: channel 0: close_write
debug2: channel 0: output drain -> closed
debug1: client_input_channel_req: channel 0 rtype exit-status reply 0
debug2: channel 0: rcvd close
debug2: channel 0: close_read
debug2: channel 0: input open -> closed
debug2: channel 0: almost dead
debug2: channel 0: gc: notify user
debug2: channel 0: gc: user detached
debug2: channel 0: send close
debug2: channel 0: is dead
debug2: channel 0: garbage collecting
debug1: channel 0: free: client-session, nchannels 1
debug1: fd 0 clearing O_NONBLOCK
debug1: fd 1 clearing O_NONBLOCK
Transferred: sent 4576, received 2520 bytes, in 0.0 seconds
Bytes per second: sent 167737.0, received 92372.6
debug1: Exit status 0
debug1: compress outgoing: raw data 135, compressed 121, factor 0.90
debug1: compress incoming: raw data 66, compressed 52, factor 0.79
lost connection

Đó là máy CentOS 5.9.

Những điều tôi đã kiểm tra ...

  • Tôi được phép viết vào thư mục đó.
  • Người dùng có vỏ hợp lý (/ bin / bash).
  • Tôi đã cố gắng di chuyển ~/.ssh/configra khỏi đường đi.
  • Việc lấy máy đó từ những người khác có hệ điều hành hoàn toàn khác cũng bị lỗi.
  • Đĩa không đầy.
  • Khởi động lại sshd.

/ var / log / safe chứa ...

Apr  4 14:23:22 some sshd[12576]: Postponed publickey for user from 1.2.3.4 port 33581 ssh2
Apr  4 14:23:22 some sshd[12575]: Accepted publickey for user from 1.2.3.4 port 33581 ssh2
Apr  4 14:23:22 some sshd[12575]: pam_unix(sshd:session): session opened for user user by (uid=0)
Apr  4 14:23:22 some sshd[12575]: pam_unix(sshd:session): session closed for user user

Tôi có thể kiểm tra cái gì tiếp theo?


2
Không phải là lỗi tôi mong đợi, nhưng chỉ trong trường hợp, làm bạn ~/.bashrchay ~/.profilehay /etc/bash.bashrchay /etc/profilein bất cứ điều gì để STDOUT? bugzilla.redhat.com/show_orms.cgi?id=20527 . Và tôi giả sử bạn đang sử dụng Linux?
terdon

Không. Tôi chỉ nhận được bình thường Last login: Thu Apr 4 10:15:28 2013 from 1.2.3.4.
Schwern

Bất cứ điều gì trong bất kỳ hệ thống nào đăng nhập vào máy chủ đích?
Flup

@Flup Trông bình thường. Tôi đã đăng những gì hiển thị trong nhật ký khi tôi kết nối.
Schwern

Bạn có thể bắt đầu strace -f -o /tmp/sshd.strace -p [pid of sshd]trên máy chủ, thử lại, sau đó đăng bất cứ thứ gì từ tệp đó có vẻ phù hợp không?
Flup

Câu trả lời:


1

Có cùng một vấn đề.

Nếu bạn đã cài đặt tối thiểu Centos, nó chỉ cài đặt opensshopenssh-servercác gói chứ không cài đặt openssh-clients. sudo yum install openssh-clientssẽ khắc phục vấn đề của bạn.


Tôi không có quyền truy cập vào máy đó nữa, nhưng đó dường như là một câu trả lời.
Schwern

4

scphoạt động bằng cách tạo sshkết nối đến máy chủ từ xa, sau đó khởi chạy một bản sao khác của scpchương trình trên máy chủ đó. Hai trường hợp scp giao tiếp thông qua kết nối ssh để thực hiện chuyển tập tin.

"Mất kết nối" được in bởi scpchương trình cục bộ khi kết nối ssh giảm sớm. Lý do thông thường cho đó là scpchương trình trên máy chủ từ xa hoặc thất bại trong việc bắt đầu hoặc nếu không nó đã thoát sớm. Điều này có thể xảy ra vì chương trình scp không tồn tại trên máy chủ từ xa hoặc nó không có trong lệnh PATH của bạn hoặc không được đánh dấu là có thể thực thi được hoặc bị lỗi sau khi bắt đầu hoặc một cái gì đó dọc theo các dòng đó.


0

Gần đây chúng tôi đã có vấn đề này trên một trong các hệ thống của chúng tôi.

Chúng tôi có thể ssh một cách thích hợp vào máy chủ, nhưng phát hiện ra chúng tôi không thể ssh từ máy chủ trở lại máy. Đây là một nơi tốt để điều tra, nếu bạn không thể làm điều này thì bạn sẽ không thể sử dụng SCP.

Trong trường hợp của chúng tôi, bằng cách nào đó (có lẽ là cài đặt đã khắc phục) đã thay thế các tệp nhị phân ssh của chúng tôi bằng các tệp trống 0 byte. Bất cứ khi nào "ssh" được thực thi, không có gì xảy ra.

Bằng cách cài đặt lại openssh-client, chúng tôi đã sửa lỗi nhị phân và scp bắt đầu hoạt động.

yum reinstall openssh-clients

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.