I'm having an issue with my Fedora 19 x86_64 virtual machine.

It seems to ignore my 4096-bit key setting. I've set the ServerKeyBits directive to 4096, stopped the sshd service, deleted all host keys in the /etc/ssh/ directory, and then restarted the sshd service. It creates new keys that are 2048-bits instead. I know this because when I do ssh-keygen -lf /etc/ssh/ssh_host_rsa_key.pub it returns 2048 yet on another machine that I've done this for it returns 4096.

Why is my OpenSSH service ignoring its ServerKeyBits directive? It doesn't seem to ignore other directives, such as turning off password authentication and only allowing key-pair authentication.

I have openssh-6.2p2-7.fc19.x86_64 and openssl-1:1.0.1e-37.fc19.1.x86_64 installed.

Thanks in advance.

My configuration file is as follows:

#       $OpenBSD: sshd_config,v 1.89 2013/02/06 00:20:42 dtucker 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:/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 override the
# default value.

# If you want to change the port on a SELinux system, you have to tell
# SELinux about this change.
# semanage port -a -t ssh_port_t -p tcp #PORTNUMBER
Port 22
AddressFamily any
ListenAddress ::

# The default requires explicit activation of protocol 1
Protocol 2

# 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
#HostKey /etc/ssh/ssh_host_ecdsa_key

# Lifetime and size of ephemeral version 1 server key
KeyRegenerationInterval 1h
ServerKeyBits 4096

# Logging
# obsoletes QuietMode and FascistLogging
#SyslogFacility AUTH
SyslogFacility AUTHPRIV
#LogLevel INFO

# Authentication:

#LoginGraceTime 2m
#PermitRootLogin yes
#StrictModes yes
#MaxAuthTries 6
#MaxSessions 10

RSAAuthentication yes
PubkeyAuthentication yes

# The default is to check both .ssh/authorized_keys and .ssh/authorized_keys2
# but this is overridden so installations will only check .ssh/authorized_keys
AuthorizedKeysFile      .ssh/authorized_keys

#AuthorizedPrincipalsFile none

#AuthorizedKeysCommand none
#AuthorizedKeysCommandUser nobody

# 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
PasswordAuthentication no
PermitEmptyPasswords no

# Change to no to disable s/key passwords
#ChallengeResponseAuthentication yes
ChallengeResponseAuthentication no

# Kerberos options
#KerberosAuthentication no
#KerberosOrLocalPasswd yes
#KerberosTicketCleanup yes
#KerberosGetAFSToken no
#KerberosUseKuserok yes

# GSSAPI options
#GSSAPIAuthentication no
GSSAPIAuthentication yes
#GSSAPICleanupCredentials yes
GSSAPICleanupCredentials yes
#GSSAPIStrictAcceptorCheck yes
#GSSAPIKeyExchange no

# 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 and
# PasswordAuthentication.  Depending on your PAM configuration,
# PAM authentication via ChallengeResponseAuthentication may bypass
# the setting of "PermitRootLogin without-password".
# If you just want the PAM account and session checks to run without
# PAM authentication, then enable this but set PasswordAuthentication
# and ChallengeResponseAuthentication to 'no'.
# WARNING: 'UsePAM no' is not supported in Fedora and may cause several
# problems.
#UsePAM no
UsePAM yes

#AllowAgentForwarding yes
AllowTcpForwarding no
#GatewayPorts no
#X11Forwarding no
X11Forwarding no
#X11DisplayOffset 10
#X11UseLocalhost yes
#PrintMotd yes
#PrintLastLog yes
#TCPKeepAlive yes
#UseLogin no
UsePrivilegeSeparation sandbox          # Default for new installations.
#PermitUserEnvironment no
#Compression delayed
#ClientAliveInterval 0
#ClientAliveCountMax 3
#ShowPatchLevel no
UseDNS no
#PidFile /var/run/sshd.pid
#MaxStartups 10:30:100
#PermitTunnel no
#ChrootDirectory none
#VersionAddendum none

# no default banner path
#Banner none
Banner /etc/issue.net

# Accept locale-related environment variables

# override default of no subsystems
Subsystem       sftp    /usr/libexec/openssh/sftp-server

# Uncomment this if you want to use .local domain
#Host *.local
#       CheckHostIP no

# Example of overriding settings on a per-user basis
#Match User anoncvs
#       X11Forwarding no
#       AllowTcpForwarding no
#       ForceCommand cvs server
  • Is there anything about host key generation logged by openssh? – EEAA Jul 3 '14 at 22:37
  • 1
    Is there some reason why you don't simply create your host keys manually? – Zoredache Jul 3 '14 at 22:39
  • Yes, it has 4 lines saying that it generated new host keys successfully. SSH2 RSA, SSH1 RSA, SSH2 DSA, SSH2 ECDSA. – Carl Bennett Jul 3 '14 at 22:41
  • There's no reason, I just haven't researched how to, and automatic host key generation has always worked for me. – Carl Bennett Jul 3 '14 at 22:41

The key that ServerKeyBits is for is ephemeral key. Not the generated host keys. It is also for version 1 of the protocol, which basically no longer relevant, and you have it disabled in the configuration file Protocol 2 you pasted. So in the context of your config changing the ServerKeyBits is completely meaningless.


Defines the number of bits in the ephemeral protocol version 1 server key. The minimum value is 512, and the default is 1024.

If you want to create 4096 bit rsa host keys issue a command like this.

ssh-keygen -q -f /etc/ssh/ssh_host_rsa_key -N '' \
           -b 4096 -t rsa

DSA keys are fixed at 1024 bits, and ecdsa keys can be 256, 384, or 521 bits. So this would generated the ecdsa key with the largest number of bits.

ssh-keygen -q -f /etc/ssh/ssh_host_ecdsa_key -N '' \
           -b 521 -t ecdsa

I am not sure about Centos/Redhat/Fedora, but on Debian based distros the host keys are generated as part of the postinst script. At one point in time the init.d script would also re-create these keys if they are missing. It wouldn't surprise me if the ssh start up script on Fedora is what you should be looking at instead of the sshd_config.

  • Looks like the Fedora startup script (the one ran by systemd) has a ExecStartPre directive that points to /usr/sbin/sshd-keygen, so your assumption seems to be correct. – Carl Bennett Jul 3 '14 at 23:04
  • Do you mean 512 instead of 521, or am I mistaken? I'm just asking to be sure, because you wrote 521 twice. – Steen Schütt Mar 25 '16 at 12:12
  • Trying to run ssh-keygen -q -f ecdsa_key -N '' -b 512 -t ecdsa results in an error Invalid ECDSA key length - valid lengths are 256, 384 or 521 bits. – Zoredache Mar 25 '16 at 16:51
  • @TimeSheep got it straight from the ssh-keygen manpage. For ECDSA keys, the -b flag determines the key length by selecting from one of three elliptic curve sizes: 256, 384 or 521 bits. Attempting to use bit lengths other than these three values for ECDSA keys will fail. manpages.debian.org/cgi-bin/… – Zoredache Mar 25 '16 at 16:52
  • Okay, it just seems like an odd number, especially because it could have been a typo :) – Steen Schütt Mar 25 '16 at 18:32

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.