Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 163206 - New openssh update fails to start sshd with default configuration
Summary: New openssh update fails to start sshd with default configuration
Alias: None
Product: Fedora
Classification: Fedora
Component: openssh
Version: 4
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Tomas Mraz
QA Contact: Brian Brock
Depends On:
TreeView+ depends on / blocked
Reported: 2005-07-14 01:15 UTC by Jon Benson
Modified: 2007-11-30 22:11 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2005-07-18 06:42:34 UTC

Attachments (Terms of Use)

Description Jon Benson 2005-07-14 01:15:42 UTC
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[29429]: Server listening on :: port 22.
Jul 14 11:00:35 gibhli sshd[29429]: error: Bind to port 22 on 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

2.  Uncomment ListenAddress

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 08:54:36 UTC
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-15 01:06:13 UTC
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.

[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 ::

# 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/
#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 10:26:42 UTC
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 root@
root@'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-18 01:11:55 UTC
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 

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 06:42:34 UTC
Closing per reporter's comment.

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