Der OpenSSH-Daemon ignoriert die ServerKeyBits-Direktive


7

Ich habe ein Problem mit meiner virtuellen Fedora 19 x86_64-Maschine.

Es scheint meine 4096-Bit-Schlüsseleinstellung zu ignorieren. Ich habe die ServerKeyBitsAnweisung auf gesetzt 4096, den sshd-Dienst gestoppt, alle Hostschlüssel im Verzeichnis gelöscht /etc/ssh/und dann den sshd-Dienst neu gestartet. Es werden stattdessen neue Schlüssel mit 2048 Bit erstellt. Ich weiß das, weil wenn ich es tue ssh-keygen -lf /etc/ssh/ssh_host_rsa_key.pub, 2048noch auf einem anderen Computer zurückkehrt, dass ich dies getan habe, weil es zurückkehrt 4096.

Warum ignoriert mein OpenSSH-Dienst seine ServerKeyBitsAnweisung? Andere Anweisungen wie das Deaktivieren der Kennwortauthentifizierung und das Zulassen der Schlüsselpaarauthentifizierung scheinen nicht ignoriert zu werden.

Ich habe openssh-6.2p2-7.fc19.x86_64und openssl-1:1.0.1e-37.fc19.1.x86_64installiert.

Danke im Voraus.

Meine Konfigurationsdatei lautet wie folgt:

#       $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 0.0.0.0
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
AcceptEnv LANG LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE LC_MONETARY LC_MESSAGES
AcceptEnv LC_PAPER LC_NAME LC_ADDRESS LC_TELEPHONE LC_MEASUREMENT
AcceptEnv LC_IDENTIFICATION LC_ALL LANGUAGE
AcceptEnv XMODIFIERS

# 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

Gibt es etwas über die von openssh protokollierte Hostschlüsselgenerierung?
EEAA

1
Gibt es einen Grund, warum Sie Ihre Hostschlüssel nicht einfach manuell erstellen?
Zoredache

Ja, es gibt 4 Zeilen, die besagen, dass neue Hostschlüssel erfolgreich generiert wurden. SSH2 RSA, SSH1 RSA, SSH2 DSA, SSH2 ECDSA.
Carl Bennett

Es gibt keinen Grund, ich habe nur nicht nachgeforscht, wie es geht, und die automatische Generierung von Hostschlüsseln hat immer für mich funktioniert.
Carl Bennett

Antworten:


9

Der Schlüssel, ServerKeyBitsfür den es geht, ist ein kurzlebiger Schlüssel. Nicht die generierten Hostschlüssel. Dies gilt auch für Version 1 des Protokolls, die grundsätzlich nicht mehr relevant ist und in der von Protocol 2Ihnen eingefügten Konfigurationsdatei deaktiviert ist . Im Kontext Ihrer Konfiguration ist das Ändern der ServerKeyBits also völlig bedeutungslos.

ServerKeyBits

Definiert die Anzahl der Bits im Serverschlüssel des kurzlebigen Protokolls Version 1 . Der Mindestwert ist 512 und der Standardwert ist 1024.

Wenn Sie 4096-Bit-RSA-Hostschlüssel erstellen möchten, geben Sie einen Befehl wie diesen ein.

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

DSA-Schlüssel sind auf 1024 Bit festgelegt, und ecdsa-Schlüssel können 256, 384 oder 521 Bit sein. Dies würde also den ecdsa-Schlüssel mit der größten Anzahl von Bits erzeugen.

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

Ich bin mir bei Centos / Redhat / Fedora nicht sicher, aber bei Debian-basierten Distributionen werden die Host-Schlüssel als Teil des Postinst-Skripts generiert. Zu einem bestimmten Zeitpunkt würde das Skript init.d diese Schlüssel auch neu erstellen, wenn sie fehlen. Es würde mich nicht überraschen, wenn Sie das ssh-Startskript auf Fedora anstelle der sshd_config betrachten sollten.


Es sieht so aus, als ob das Fedora-Startskript (das von systemd ausgeführt wird) eine ExecStartPreDirektive hat, auf die verwiesen wird /usr/sbin/sshd-keygen, sodass Ihre Annahme richtig zu sein scheint.
Carl Bennett

Meinst du 512 statt 521 oder irre ich mich? Ich möchte nur sicher gehen, weil Sie zweimal 521 geschrieben haben.
Steen Schütt

Der Versuch, etwas auszuführen, ssh-keygen -q -f ecdsa_key -N '' -b 512 -t ecdsaführt zu einem Fehler Invalid ECDSA key length - valid lengths are 256, 384 or 521 bits.
Zoredache

@TimeSheep hat es direkt von der ssh-keygen Manpage bekommen. 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

Okay, es scheint nur eine ungerade Zahl zu sein, vor allem, weil es ein Tippfehler gewesen sein könnte :)
Steen Schütt
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.