Ich beginne, einen YubiKey 5 zu verwenden, um mich per SSH mit Remote-Boxen zu verbinden, anstatt einen Softwareschlüssel zu verwenden. Ich generiere die Schlüssel mit diesem Befehl:
ssh-keygen -t ed25519-sk
Das funktioniert, wenn ich mich per SSH mit Ubuntu verbinde, aber nicht, wenn ich mich per SSH mit meinem Mac (macOS 11.4) verbinde. Ich erhalte ständig die Fehlermeldung „Zugriff verweigert (öffentlicher Schlüssel)“. Der öffentliche Schlüssel ed25519 befindet sich in der Datei „authorized_keys“. Ich kann Schlüssel, die ich mit dem RSA-Algorithmus generiert habe, verwenden, um mich per SSH mit dem Mac zu verbinden. Unten ist meine sshd_config-Datei auf meinem Mac.
Irgendwelche Ideen, was meinen Fehler verursachen könnte?
# $OpenBSD: sshd_config,v 1.103 2018/04/09 20:41:22 tj Exp $
# This is the sshd server system-wide configuration file. See
# sshd_config(5) for more information.
# This sshd was compiled with PATH=/usr/bin:/bin:/usr/sbin:/sbin
# 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.
#Port 22
#AddressFamily any
#ListenAddress 0.0.0.0
#ListenAddress ::
#HostKey /etc/ssh/ssh_host_rsa_key
#HostKey /etc/ssh/ssh_host_ecdsa_key
#HostKey /etc/ssh/ssh_host_ed25519_key
# Ciphers and keying
#RekeyLimit default none
# Logging
#SyslogFacility AUTH
#LogLevel INFO
# Authentication:
#LoginGraceTime 2m
#PermitRootLogin prohibit-password
#StrictModes yes
#MaxAuthTries 6
#MaxSessions 10
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
#HostbasedAuthentication no
# Change to yes if you don't trust ~/.ssh/known_hosts for
# 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 no
#PermitEmptyPasswords no
# Change to no to disable s/key passwords
ChallengeResponseAuthentication no
# Kerberos options
#KerberosAuthentication no
#KerberosOrLocalPasswd yes
#KerberosTicketCleanup yes
#KerberosGetAFSToken no
# GSSAPI options
#GSSAPIAuthentication no
#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 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'.
UsePAM no
#AllowAgentForwarding yes
#AllowTcpForwarding yes
#GatewayPorts no
#X11Forwarding no
#X11DisplayOffset 10
#X11UseLocalhost yes
#PermitTTY yes
#PrintMotd yes
#PrintLastLog yes
#TCPKeepAlive yes
#PermitUserEnvironment no
#Compression delayed
#ClientAliveInterval 0
#ClientAliveCountMax 3
#UseDNS no
#PidFile /var/run/sshd.pid
#MaxStartups 10:30:100
#PermitTunnel no
#ChrootDirectory none
#VersionAddendum none
# pass locale information
AcceptEnv LANG LC_*
# no default banner path
#Banner none
# override default of no subsystems
Subsystem sftp /usr/libexec/sftp-server
# Example of overriding settings on a per-user basis
#Match User anoncvs
# X11Forwarding no
# AllowTcpForwarding no
# PermitTTY no
# ForceCommand cvs server
Antwort1
Soweit ich weiß, enthält macOS 11.4 OpenSSH 8.1, das die neuen -skSchlüsseltypen noch nicht versteht. Diese Funktion wurde erst in OpenSSH 8.2 hinzugefügt.
("Sicherheitsschlüssel"-Schlüsselpaare sind ein anderer Typ als "normale" Ed25519-Schlüsselpaare, da U2F/FIDO-Schlüssel nicht zum Signieren beliebiger Daten verwendet werden können - sie signieren nur Dinge, die wie FIDO-Challenge-Nachrichten aussehen - also der SSH-ClientUndder Server muss zustimmen, die SSH-Challenge anders zu formatieren als für normale Schlüsselpaare.)