Version-Release number of selected component: openssh-server-6.8p1-5.fc22 Additional info: reporter: libreport-2.5.1 backtrace_rating: 4 cmdline: /usr/sbin/sshd -D crash_function: ssh_packet_connection_is_on_socket executable: /usr/sbin/sshd global_pid: 924 kernel: 4.0.0-1.fc22.x86_64 runlevel: N 5 type: CCpp uid: 0 Truncated backtrace: Thread no. 1 (6 frames) #0 ssh_packet_connection_is_on_socket at packet.c:371 #1 set_remote_ipaddr at canohost.c:356 #2 get_remote_ipaddr at canohost.c:377 #3 audit_destroy_sensitive_data at audit-linux.c:379 #4 destroy_sensitive_data at sshd.c:608 #5 server_accept_loop at sshd.c:1347
Created attachment 1017754 [details] File: backtrace
Created attachment 1017755 [details] File: cgroup
Created attachment 1017756 [details] File: core_backtrace
Created attachment 1017757 [details] File: dso_list
Created attachment 1017758 [details] File: environ
Created attachment 1017759 [details] File: limits
Created attachment 1017760 [details] File: maps
Created attachment 1017761 [details] File: mountinfo
Created attachment 1017762 [details] File: namespaces
Created attachment 1017763 [details] File: open_fds
Created attachment 1017764 [details] File: proc_pid_status
Created attachment 1017765 [details] File: var_log_messages
Hi Mike, I believe that this was fixed with last update after bz1213423. Can you reproduce this issue? What were the steps that lead you to this failure? Is possible that you were running server/session from older openssh version?
(In reply to Jakub Jelen from comment #13) > Hi Mike, > I believe that this was fixed with last update after bz1213423. Can you > reproduce this issue? What were the steps that lead you to this failure? > Is possible that you were running server/session from older openssh version? I could not reproduce it on Fedora-Live-Workstation-x86_64-22-TC3.iso anymore. Although TC3 still has the same version of openssh-server as the Beta Version of Fedora 22 where I encountered that problem: [mfabian@Fedora-Live-Workstation-x86_64-2 ~]$ rpm -q openssh-server openssh-server-6.8p1-5.fc22.x86_64 [mfabian@Fedora-Live-Workstation-x86_64-2 ~]$ I didn’t do any special steps to get that failure, after installation of a beta version of Fedora 22 I just enabled ssh using sudo systemctl enable sshd.service sudo systemctl start sshd.service then logged into the guest from the host using ssh.
If I am right, sshd is one of the services that are enabled by default (if not on workstation, please correct me. It doesn't mean that they are automatically installed) and I think this happened just during update of this package, when the old sshd was stopping and new version was starting (which is handled by systemd scriptlet). I'm not aware that some of "enable" or "start" systemctl commands are doing restart if service is running so it seems strange to me. According to FAF, there seems to be more people involved and also both versions 6.8p1-4.fc22 and 6.8p1-5.fc22 which supports my theory. I guess this should be reported for the first mentioned version and it looks like a bug in abrt for me. If nobody will protest, I will reassign it to abrt. They can maybe explain more.
(In reply to Jakub Jelen from comment #15) > If I am right, sshd is one of the services that are enabled by default (if > not on workstation, please correct me. It doesn't mean that they are > automatically installed) and I think this happened just during update of > this package, when the old sshd was stopping and new version was starting > (which is handled by systemd scriptlet). No, sshd is not enabled by default after a default install from a Fedora 22 Workstation Live DVD.
According to FAF, the reports no longer appears so I think it was really the rest of previous bug during service stop. Closing.