ubuntuusers.de

Login mit Public-Key, dennoch PW-Abfrage

Status: Ungelöst | Ubuntu-Version: Server 23.10 (Mantic Minotaur)
Antworten |

007joker

Anmeldungsdatum:
4. Dezember 2009

Beiträge: 220

Hi,

ich habe - wie im Wiki beschrieben - das Public-Key-Verfahren aufgesetzt und kann mich mit meinem Benutzernamen ohne Angabe eines Passworts über SSH auf meinem Server einloggen. Spaßeshalber habe ich mal getestet, wie das mit einem anderen Benutzer ist, den es aber auf dem Server gar nicht gibt. Da gibt es dann tatsächlich eine Passwort-Abfrage, die aber natürlich ins Leere läuft. Ist das so gedacht? Oder sollte da gar keine Passwort-Abfrage mehr sein?

Das hier ist die sshd_conf, wie ich sie aktuell laufen habe.

# This is the sshd server system-wide configuration file.  See 
# sshd_config(5) for more information. 

# This sshd was compiled with PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games 

# 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. 

Include /etc/ssh/sshd_config.d/*.conf 

# Port and ListenAddress options are not used when sshd is socket-activated, 
# which is now the default in Ubuntu.  See sshd_config(5) and 
# /usr/share/doc/openssh-server/README.Debian.gz for details. 
#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 

# Expect .ssh/authorized_keys2 to be disregarded by default in future. 
#AuthorizedKeysFile     .ssh/authorized_keys .ssh/authorized_keys2 

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

# Change to yes to enable challenge-response passwords (beware issues with 
# some PAM modules and threads) 
KbdInteractiveAuthentication no 

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

# GSSAPI options 
#GSSAPIAuthentication no 
#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 KbdInteractiveAuthentication and 
# PasswordAuthentication.  Depending on your PAM configuration, 
# PAM authentication via KbdInteractiveAuthentication may bypass 
# the setting of "PermitRootLogin prohibit-password". 
# If you just want the PAM account and session checks to run without 
# PAM authentication, then enable this but set PasswordAuthentication 
# and KbdInteractiveAuthentication to 'no'. 
UsePAM yes 

#AllowAgentForwarding yes 
#AllowTcpForwarding yes 
#GatewayPorts no 
X11Forwarding yes 
#X11DisplayOffset 10 
#X11UseLocalhost yes 
#PermitTTY yes 
PrintMotd no 
#PrintLastLog yes 
#TCPKeepAlive yes 
#PermitUserEnvironment no 
#Compression delayed 
#ClientAliveInterval 0 
#ClientAliveCountMax 3 
#UseDNS no 
#PidFile /run/sshd.pid 
#MaxStartups 10:30:100 
#PermitTunnel no 
#ChrootDirectory none 
#VersionAddendum none 

# no default banner path 
#Banner none 

# Allow client to pass locale environment variables 
AcceptEnv LANG LC_* 

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

# Example of overriding settings on a per-user basis 
#Match User anoncvs 
#       X11Forwarding no 
#       AllowTcpForwarding no 
#       PermitTTY no 
#       ForceCommand cvs server

micneu

Avatar von micneu

Anmeldungsdatum:
19. Januar 2021

Beiträge: 807

Wohnort: Hamburg

Moin, ist doch alles richtig, du kannst dich so NICHT mit Passwort anmelden. Ich hatte es so verstanden das soll es sein. Oder stört dich das er trotzdem nach Passwort fragt? Auch wenn du das richtige Passwort eingeben würdest, kommst du nicht rein.

lubux

Anmeldungsdatum:
21. November 2012

Beiträge: 14347

007joker schrieb:

Spaßeshalber habe ich mal getestet, wie das mit einem anderen Benutzer ist, den es aber auf dem Server gar nicht gibt. Da gibt es dann tatsächlich eine Passwort-Abfrage, die aber natürlich ins Leere läuft.

BTW: Wenn Du:

AllowUsers <user>
DenyUsers root !<user>

in der sshd_config richtig anwendest (... so dass Du dich nicht aussperrst!), gibt es keine Passwort-Abfrage.

007joker

(Themenstarter)

Anmeldungsdatum:
4. Dezember 2009

Beiträge: 220

Danke für eure Antworten. Es ist ja oft privat so, dass es nur einen Account gibt.

BTW: Wenn Du: AllowUsers <user> DenyUsers root !<user> in der sshd_config richtig anwendest (... so dass Du dich nicht aussperrst!), gibt es keine Passwort-Abfrage.

Wie mache ich das? Setze ich unter AllowUsers <user> nur meinen Usernamen ein?

lubux

Anmeldungsdatum:
21. November 2012

Beiträge: 14347

007joker schrieb:

Setze ich unter AllowUsers <user> nur meinen Usernamen ein?

Den username mit dem Du dich anmelden kannst (ohne spitze Klammern).

This keyword can be followed by a list of user name patterns, separated by spaces.
If specified, login is allowed only for user names that match one of the patterns.

007joker

(Themenstarter)

Anmeldungsdatum:
4. Dezember 2009

Beiträge: 220

Sorry, ich fühl' mich gerade doof, weil ich nochmal nachfrage.

AllowUsers steht ja erstmal nirgends. Das ergänze ich also. Irgendwo? Dann ssh neustarten.

Aber ... wenn ich es mit ssh xyz@server versuche, werde ich aufgefordert, das PW für xyz einzugeben.

Ich frage so nach, weil ich auch fail2ban laufen habe - und nach drei Loginversuchen 3600s Pause sind 😉 Wenn da einer meinen Server angreift, kann es sein, dass ich mich selbst nicht einloggen kann. Vielleicht gehe ich das aber auch völlig verkehrt an.

lubux

Anmeldungsdatum:
21. November 2012

Beiträge: 14347

007joker schrieb:

AllowUsers steht ja erstmal nirgends. Das ergänze ich also. Irgendwo? Dann ssh neustarten.

In der sshd_config (oder gleichwertig), aber nur wenn Du weißt was Du tust. Neustarten tust Du sshd (nach sudo systemctl daemon-reload).

007joker schrieb:

Aber ... wenn ich es mit ssh xyz@server versuche, werde ich aufgefordert, das PW für xyz einzugeben.

Wie soll man das verstehen? Hast Du die config schon geändert?

007joker schrieb:

Ich frage so nach, weil ich auch fail2ban laufen habe - ...

Für sshd brauchst Du fail2ban nicht.

007joker

(Themenstarter)

Anmeldungsdatum:
4. Dezember 2009

Beiträge: 220

Dann nehme ich fail2ban wieder runter.

Müsste aber nicht "PasswordAuthentication no" dafür sorgen, dass gar nicht erst eine PW-Abfrage kommt, falls jemand von außen doch versuchen sollte, sich einzuloggen?

lubux

Anmeldungsdatum:
21. November 2012

Beiträge: 14347

007joker schrieb:

Müsste aber nicht "PasswordAuthentication no" dafür sorgen, dass gar nicht erst eine PW-Abfrage kommt, falls jemand von außen doch versuchen sollte, sich einzuloggen?

Ja, der von außen, muss dann die Mitteilung bekommen:

<falscher username>@<IP-Adresse-sshd>: Permission denied (publickey).

Aber ich denke, dir geht es doch um das Passwort für die benutzung des private key, auf deinem ssh-Client, oder?

007joker

(Themenstarter)

Anmeldungsdatum:
4. Dezember 2009

Beiträge: 220

Irgendwie liegt das Problem noch tiefer, merke ich. Ich kann mich von außen immer noch mit Benutzernamen und PW einloggen. Da stimmt was in der sshd_conf nicht, scheint mir.

lubux

Anmeldungsdatum:
21. November 2012

Beiträge: 14347

007joker schrieb:

Da stimmt was in der sshd_conf nicht, scheint mir.

Ja, sieht so aus.
Bei meinen sshd-Servern wird nur publickey, zum Anmelden, angeboten:

debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: No more authentication methods to try.

007joker

(Themenstarter)

Anmeldungsdatum:
4. Dezember 2009

Beiträge: 220

Guck, hier heißt es:

debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey

lubux

Anmeldungsdatum:
21. November 2012

Beiträge: 14347

007joker schrieb:

debug1: Authentications that can continue: publickey,password

Ja. D. h. mit der jetzigen sshd_config wird "password authentication" noch erlaubt/ermöglicht.

007joker

(Themenstarter)

Anmeldungsdatum:
4. Dezember 2009

Beiträge: 220

Sehr seltsam. Ich habe

sudo sshd -T

durchlaufen lassen. Im Ergebnis sieht es so aus, als hätte ich an der sshd_config nie was verändert.

port 22
addressfamily any
listenaddress [::]:22
listenaddress 0.0.0.0:22
usepam yes
logingracetime 120
x11displayoffset 10
maxauthtries 6
maxsessions 10
clientaliveinterval 0
clientalivecountmax 3
requiredrsasize 1024
streamlocalbindmask 0177
unusedconnectiontimeout none
permitrootlogin without-password
ignorerhosts yes
ignoreuserknownhosts no
hostbasedauthentication no
hostbasedusesnamefrompacketonly no
pubkeyauthentication yes
kerberosauthentication no
kerberosorlocalpasswd yes
kerberosticketcleanup yes
gssapiauthentication no
gssapicleanupcredentials yes
gssapikeyexchange no
gssapistrictacceptorcheck yes
gssapistorecredentialsonrekey no
gssapikexalgorithms gss-group14-sha256-,gss-group16-sha512-,gss-nistp256-sha256-,gss-curve25519-sha256-,gss-group14-sha1-,gss-gex-sha1-
passwordauthentication yes
kbdinteractiveauthentication no
printmotd no
printlastlog yes
x11forwarding yes
x11uselocalhost yes
permittty yes
permituserrc yes
strictmodes yes
tcpkeepalive yes
permitemptypasswords no
compression yes
gatewayports no
usedns no
allowtcpforwarding yes
allowagentforwarding yes
disableforwarding no
allowstreamlocalforwarding yes
streamlocalbindunlink no
fingerprinthash SHA256
exposeauthinfo no
pidfile /run/sshd.pid
modulifile /etc/ssh/moduli
xauthlocation /usr/bin/xauth
ciphers chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com
macs umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1
banner none
forcecommand none
chrootdirectory none
trustedusercakeys none
revokedkeys none
securitykeyprovider internal
authorizedprincipalsfile none
versionaddendum none
authorizedkeyscommand none
authorizedkeyscommanduser none
authorizedprincipalscommand none
authorizedprincipalscommanduser none
hostkeyagent none
kexalgorithms sntrup761x25519-sha512@openssh.com,curve25519-sha256,curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group14-sha256
casignaturealgorithms ssh-ed25519,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,sk-ssh-ed25519@openssh.com,sk-ecdsa-sha2-nistp256@openssh.com,rsa-sha2-512,rsa-sha2-256
hostbasedacceptedalgorithms ssh-ed25519-cert-v01@openssh.com,ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp521-cert-v01@openssh.com,sk-ssh-ed25519-cert-v01@openssh.com,sk-ecdsa-sha2-nistp256-cert-v01@openssh.com,rsa-sha2-512-cert-v01@openssh.com,rsa-sha2-256-cert-v01@openssh.com,ssh-ed25519,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,sk-ssh-ed25519@openssh.com,sk-ecdsa-sha2-nistp256@openssh.com,rsa-sha2-512,rsa-sha2-256
hostkeyalgorithms ssh-ed25519-cert-v01@openssh.com,ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp521-cert-v01@openssh.com,sk-ssh-ed25519-cert-v01@openssh.com,sk-ecdsa-sha2-nistp256-cert-v01@openssh.com,rsa-sha2-512-cert-v01@openssh.com,rsa-sha2-256-cert-v01@openssh.com,ssh-ed25519,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,sk-ssh-ed25519@openssh.com,sk-ecdsa-sha2-nistp256@openssh.com,rsa-sha2-512,rsa-sha2-256
pubkeyacceptedalgorithms ssh-ed25519-cert-v01@openssh.com,ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp521-cert-v01@openssh.com,sk-ssh-ed25519-cert-v01@openssh.com,sk-ecdsa-sha2-nistp256-cert-v01@openssh.com,rsa-sha2-512-cert-v01@openssh.com,rsa-sha2-256-cert-v01@openssh.com,ssh-ed25519,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,sk-ssh-ed25519@openssh.com,sk-ecdsa-sha2-nistp256@openssh.com,rsa-sha2-512,rsa-sha2-256
loglevel INFO
syslogfacility AUTH
authorizedkeysfile .ssh/authorized_keys .ssh/authorized_keys2
hostkey /etc/ssh/ssh_host_rsa_key
hostkey /etc/ssh/ssh_host_ecdsa_key
hostkey /etc/ssh/ssh_host_ed25519_key
acceptenv LANG
acceptenv LC_*
authenticationmethods any
channeltimeout none
subsystem sftp /usr/lib/openssh/sftp-server
maxstartups 10:30:100
persourcemaxstartups none
persourcenetblocksize 32:128
permittunnel no
ipqos lowdelay throughput
rekeylimit 0 0
permitopen any
permitlisten any
permituserenvironment no
pubkeyauthoptions none

Was ist da los?

sebix Team-Icon

Ehemalige

Anmeldungsdatum:
14. April 2009

Beiträge: 5582

Welche Datei hast du veraendert? Den ganzen Pfad bitte, und auf welche Maschine. (Du erwaehntest in deinen Posts eine Datei namens sshd_conf)

Antworten |