Bug 1204494 - failed to transfer file, connection reset by peer
Summary: failed to transfer file, connection reset by peer
Keywords:
Status: CLOSED DUPLICATE of bug 1203900
Alias: None
Product: Fedora
Classification: Fedora
Component: openssh
Version: rawhide
Hardware: x86_64
OS: Linux
unspecified
medium
Target Milestone: ---
Assignee: Petr Lautrbach
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2015-03-22 16:06 UTC by Elvin Sindrilaru
Modified: 2015-03-23 06:20 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-03-23 06:20:59 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Elvin Sindrilaru 2015-03-22 16:06:54 UTC
Description of problem:
Trying to run anisble against Fedora Rawhide fails as follows:

$ ansible -i stage all  -m ping -vvvv
<esdss002>
<esdss002>
<esdss002> ConnectTimeout=10 PasswordAuthentication=no KbdInteractiveAuthentication=no ControlPath=/home/esindril/.ansible/cp/ansible-ssh-%h-%p-%r PreferredAuthentications=gssapi-with-mic,gssapi-keyex,hostbased,publickey ControlMaster=auto Port=10122 ControlPersist=60s
<esdss002>
esdss002 | FAILED => failed to transfer file to /home/esindril/.ansible/tmp/ansible-tmp-1427039437.27-38173930457998/ping:

Couldn't read packet: Connection reset by peer


I can run without any issues the same command against Fedora 21. 
The machine from which I run the ansible command is a CentOS box:

$ uname -a
Linux host1 3.10.0-123.13.2.el7.x86_64 #1 SMP Thu Dec 18 14:09:13 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux

$ rpm -qa | grep openssh
openssh-6.4p1-8.el7.x86_64
openssh-server-6.4p1-8.el7.x86_64
openssh-clients-6.4p1-8.el7.x86_64

Version-Release number of selected component (if applicable):

The Fedora Rawhide box which fails has the following package version:
$ rpm -qa | grep openssh
openssh-server-6.7p1-11.fc23.x86_64
openssh-6.7p1-11.fc23.x86_64
openssh-clients-6.7p1-11.fc23.x86_64

I have successfully downgraded to package openssh-6.7p1-4.fc23.x86_64.rpm which I can confirm works without any issues.

How reproducible:
Every time.

Steps to Reproduce:
1. Run a simple ansible ping command against a Fedora Rawhide box with openssh version. 6.7p1-11. Ansible just uses ssh and sftp underneath.

Actual results:
The command fails with the following message:

Couldn't read packet: Connection reset by peer

Additional info:

Starting the sshd daemon in DEBUG mode on the Rawhide box, I get the following:

Set /proc/self/oom_score_adj from 0 to -1000
debug1: Bind to port 22 on 0.0.0.0.
Server listening on 0.0.0.0 port 22.
debug1: Bind to port 22 on ::.
Server listening on :: port 22.
debug1: Forked child 1368.
Set /proc/self/oom_score_adj to 0
debug1: rexec start in 6 out 6 newsock 6 pipe 8 sock 9
debug1: inetd sockets after dupping: 5, 5
Connection from 128.142.137.16 port 36672 on 172.17.0.9 port 22
debug1: Client protocol version 2.0; client software version OpenSSH_6.4
debug1: match: OpenSSH_6.4 pat OpenSSH* compat 0x04000000
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.7
debug1: SELinux support disabled [preauth]
debug1: permanently_set_uid: 74/74 [preauth]
debug1: list_hostkey_types: ssh-rsa,ecdsa-sha2-nistp256,ssh-ed25519 [preauth]
debug1: SSH2_MSG_KEXINIT sent [preauth]
debug1: SSH2_MSG_KEXINIT received [preauth]
debug1: kex: client->server aes128-ctr hmac-sha1-etm zlib [preauth]
debug1: kex: server->client aes128-ctr hmac-sha1-etm zlib [preauth]
debug1: kex: ecdh-sha2-nistp256 need=20 dh_need=20 [preauth]
debug1: kex: ecdh-sha2-nistp256 need=20 dh_need=20 [preauth]
debug1: expecting SSH2_MSG_KEX_ECDH_INIT [preauth]
debug1: SSH2_MSG_NEWKEYS sent [preauth]
debug1: expecting SSH2_MSG_NEWKEYS [preauth]
debug1: SSH2_MSG_NEWKEYS received [preauth]
debug1: KEX done [preauth]
debug1: userauth-request for user esindril service ssh-connection method none [preauth]
debug1: attempt 0 failures 0 [preauth]
debug1: PAM: initializing for "esindril"
debug1: PAM: setting PAM_RHOST to "pcitdss1410.cern.ch"
debug1: PAM: setting PAM_TTY to "ssh"
debug1: userauth-request for user esindril service ssh-connection method gssapi-with-mic [preauth]
debug1: attempt 1 failures 0 [preauth]
debug1: userauth-request for user esindril service ssh-connection method publickey [preauth]
debug1: attempt 2 failures 0 [preauth]
debug1: temporarily_use_uid: 58602/1028 (e=0/0)
debug1: trying public key file /home/esindril/.ssh/authorized_keys
debug1: fd 4 clearing O_NONBLOCK
debug1: matching key found: file /home/esindril/.ssh/authorized_keys, line 1 RSA SHA256:J0m633p7LuY7qxU4qvu3jOTLcMHWJSLfr4lIMjN2gtE
debug1: restore_uid: 0/0
debug1: do_pam_account: called
Accepted publickey for esindril from 128.142.137.16 port 36672 ssh2: RSA SHA256:J0m633p7LuY7qxU4qvu3jOTLcMHWJSLfr4lIMjN2gtE
debug1: monitor_child_preauth: esindril has been authenticated by privileged process
debug1: Enabling compression at level 6. [preauth]
debug1: monitor_read_log: child log fd closed
debug1: temporarily_use_uid: 58602/1028 (e=0/0)
debug1: ssh_gssapi_storecreds: Not a GSSAPI mechanism
debug1: restore_uid: 0/0
debug1: SELinux support disabled
debug1: PAM: establishing credentials
User child is on pid 1370
debug1: PAM: establishing credentials
debug1: permanently_set_uid: 58602/1028
debug1: packet_set_postauth: called
debug1: Entering interactive session for SSH2.
debug1: server_init_dispatch_20
debug1: server_input_channel_open: ctype session rchan 2 win 1048576 max 16384
debug1: input_session_request
debug1: channel 0: new [server-session]
debug1: session_new: session 0
debug1: session_open: channel 0
debug1: session_open: session 0: link with channel 0
debug1: server_input_channel_open: confirm session
debug1: server_input_channel_req: channel 0 request pty-req reply 1
debug1: session_by_channel: session 0 channel 0
debug1: session_input_channel_req: session 0 req pty-req
debug1: Allocating pty.
debug1: session_new: session 0
debug1: SELinux support disabled
debug1: session_pty_req: session 0 alloc /dev/pts/0
debug1: server_input_channel_req: channel 0 request env reply 0
debug1: session_by_channel: session 0 channel 0
debug1: session_input_channel_req: session 0 req env
debug1: server_input_channel_req: channel 0 request exec reply 1
debug1: session_by_channel: session 0 channel 0
debug1: session_input_channel_req: session 0 req exec
Starting session: command on pts/0 for esindril from 128.142.137.16 port 36672
debug1: Setting controlling tty using TIOCSCTTY.
debug1: Received SIGCHLD.
debug1: session_by_pid: pid 1371
debug1: session_exit_message: session 0 channel 0 pid 1371
debug1: session_exit_message: release channel 0
debug1: session_by_tty: session 0 tty /dev/pts/0
debug1: session_pty_cleanup: session 0 release /dev/pts/0
debug1: session_by_channel: session 0 channel 0
debug1: session_close_by_channel: channel 0 child 0
debug1: session_close: session 0 pid 0
debug1: session_by_id: unknown id -1
debug1: dump: used 0 next_unused -1 session 0 0x7fb2abba25e0 channel -1 pid 0
mm_answer_audit_end_command: invalid handle
debug1: do_cleanup
debug1: PAM: cleanup
debug1: PAM: closing session
debug1: channel 0: free: server-session, nchannels 1
debug1: PAM: deleting credentials
debug1: server_input_channel_open: ctype session rchan 2 win 2097152 max 32768
debug1: input_session_request
debug1: channel 0: new [server-session]
debug1: session_new: session 0
debug1: session_open: channel 0
debug1: session_open: session 0: link with channel 0
debug1: server_input_channel_open: confirm session
debug1: server_input_channel_req: channel 0 request env reply 0
debug1: session_by_channel: session 0 channel 0
debug1: session_input_channel_req: session 0 req env
debug1: server_input_channel_req: channel 0 request subsystem reply 1
debug1: session_by_channel: session 0 channel 0
debug1: session_input_channel_req: session 0 req subsystem
debug1: subsystem: exec() /usr/libexec/openssh/sftp-server
Starting session: subsystem 'sftp' for esindril from 128.142.137.16 port 36672
mm_request_send: write: Broken pipe
debug1: do_cleanup
mm_request_send: write: Broken pipe


I did not change anything in the configuration of the ssh daemon. I believe the interesting bit in the log above is:
mm_answer_audit_end_command: invalid handle

and the last 4 lines.

Thank you, 
Elvin

Comment 1 Jakub Jelen 2015-03-23 06:20:59 UTC
Yes, I know about it. Hopefully there will be new release today. Stay tuned.

*** This bug has been marked as a duplicate of bug 1203900 ***


Note You need to log in before you can comment on or make changes to this bug.