Red Hat Bugzilla – Full Text Bug Listing
|Summary:||New openssh update fails to start sshd with default configuration|
|Product:||[Fedora] Fedora||Reporter:||Jon Benson <jon>|
|Component:||openssh||Assignee:||Tomas Mraz <tmraz>|
|Status:||CLOSED NOTABUG||QA Contact:||Brian Brock <bbrock>|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2005-07-18 02:42:34 EDT||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
Description Jon Benson 2005-07-13 21:15:42 EDT
Description of problem: The recent update fails to start SSHD. Version-Release number of selected component (if applicable): 4.1p1-3.1 How reproducible: Always Steps to Reproduce: 1. Install the update. 2. Try "service sshd restart". 3. Attempt to SSH in to the server. Actual results: Connection refused. Expected results: A SSH connection. Additional info: /var/log/secure shows Jul 14 11:00:35 gibhli sshd: Server listening on :: port 22. Jul 14 11:00:35 gibhli sshd: error: Bind to port 22 on 0.0.0.0 failed: Address already in use. I have tried various solutions I've seen suggested. 1. Uncomment ListenAddress :: This results in: [root@gibhli ssh]# service sshd start Starting sshd: /etc/ssh/sshd_config line 18: bad port number [FAILED] 2. Uncomment ListenAddress 0.0.0.0 This works, but if someone simply made the upgrade then logged out of a remote server it would be highly annoying.
Comment 1 Tomas Mraz 2005-07-14 04:54:36 EDT
I cannot reproduce your problem here. Which kernel version do you use? It works here on 2.6.11-1.1369_FC4smp and 2.6.12-1.1390_FC4smp kernels. There must be something wrong with your configuration. The messages in /var/log/secure are harmless and actually mean that sshd listens on both IPv4 and IPv6 address families. There is real bug - in the sshd_config file the commented IPv6 ListenAddress should look like: # ListenAddress [::] Could you somehow investigate more?
Comment 2 Jon Benson 2005-07-14 21:06:13 EDT
2.6.12-1.1390_FC4 (not SMP) They aren't harmless messages because sshd was NOT listening on IPv4 and I could NOT connect to the box even though sshd was running. Eg: [root@gibhli ssh]# netstat -anp | grep sshd tcp 0 0 :::22 :::* LISTEN 11398/sshd The config as it was. Hopefully this helps: # $OpenBSD: sshd_config,v 1.70 2004/12/23 23:11:00 djm Exp $ # This is the sshd server system-wide configuration file. See # sshd_config(5) for more information. # This sshd was compiled with PATH=/usr/local/bin:/bin:/usr/bin # The strategy used for options in the default sshd_config shipped with # OpenSSH is to specify options with their default value where # possible, but leave them commented. Uncommented options change a # default value. #Port 22 #Protocol 2,1 Protocol 2 #AddressFamily any #ListenAddress 0.0.0.0 #ListenAddress :: # HostKey for protocol version 1 #HostKey /etc/ssh/ssh_host_key # HostKeys for protocol version 2 #HostKey /etc/ssh/ssh_host_rsa_key #HostKey /etc/ssh/ssh_host_dsa_key # Lifetime and size of ephemeral version 1 server key #KeyRegenerationInterval 1h #ServerKeyBits 768 # Logging #obsoletes QuietMode and FascistLogging #SyslogFacility AUTH SyslogFacility AUTHPRIV #LogLevel INFO # Authentication: #LoginGraceTime 2m #PermitRootLogin yes #StrictModes yes #MaxAuthTries 6 #RSAAuthentication yes #PubkeyAuthentication yes #AuthorizedKeysFile .ssh/authorized_keys # For this to work you will also need host keys in /etc/ssh/ssh_known_hosts #RhostsRSAAuthentication no # similar for protocol version 2 #HostbasedAuthentication no # Change to yes if you don't trust ~/.ssh/known_hosts for # RhostsRSAAuthentication and HostbasedAuthentication #IgnoreUserKnownHosts no # Don't read the user's ~/.rhosts and ~/.shosts files #IgnoreRhosts yes # To disable tunneled clear text passwords, change to no here! #PasswordAuthentication yes #PermitEmptyPasswords no PasswordAuthentication yes # Change to no to disable s/key passwords #ChallengeResponseAuthentication yes ChallengeResponseAuthentication no # Kerberos options #KerberosAuthentication no #KerberosOrLocalPasswd yes #KerberosTicketCleanup yes #KerberosGetAFSToken no # GSSAPI options #GSSAPIAuthentication no GSSAPIAuthentication yes #GSSAPICleanupCredentials yes GSSAPICleanupCredentials yes # Set this to 'yes' to enable PAM authentication, account processing, # and session processing. If this is enabled, PAM authentication will # be allowed through the ChallengeResponseAuthentication mechanism. # Depending on your PAM configuration, this may bypass the setting of # PasswordAuthentication, PermitEmptyPasswords, and # "PermitRootLogin without-password". If you just want the PAM account and # session checks to run without PAM authentication, then enable this but set # ChallengeResponseAuthentication=no #UsePAM no UsePAM yes #AllowTcpForwarding yes #GatewayPorts no #X11Forwarding no X11Forwarding yes #X11DisplayOffset 10 #X11UseLocalhost yes #PrintMotd yes #PrintLastLog yes #TCPKeepAlive yes #UseLogin no #UsePrivilegeSeparation yes #PermitUserEnvironment no #Compression yes #ClientAliveInterval 0 #ClientAliveCountMax 3 #UseDNS yes #PidFile /var/run/sshd.pid #MaxStartups 10 #ShowPatchLevel no # no default banner path #Banner /some/path # override default of no subsystems Subsystem sftp /usr/libexec/openssh/sftp-server
Comment 3 Tomas Mraz 2005-07-15 06:26:42 EDT
The problem is that the netstat output doesn't mean that it doesn't listen on IPv4. Here it works fine: [root@vepro ~]# netstat -anp | grep sshd tcp 0 0 :::22 :::* LISTEN 2547/sshd [root@vepro ~]# ssh email@example.com firstname.lastname@example.org's password: Binding to the IPv6 wildcard address on Linux makes it listen on both IPv4 and IPv6 traffic. And the log message means exactly that. If the Linux semantics (different from *BSDs) is right is a different question, but I don't know the answer. The config file doesn't look suspicious at all. The problem must be elsewhere. Could you try running sshd with -ddd options from command line and attach the output here?
Comment 4 Jon Benson 2005-07-17 21:11:55 EDT
Thanks I learn something new every day. I don't know what's changed but I just tried things again (with the debug options) and now it's working fine. The kernel version is the same, as is the sshd. Sorry to bother you. Since I can't reproduce it again I will have to put it down to random luck.
Comment 5 Tomas Mraz 2005-07-18 02:42:34 EDT
Closing per reporter's comment.