Login per SSH schlägt fehl - SuSE 9.1

[tstening]

Hallo zusammen,

folgendes Problem stellt sich hier bei mir (neues SuSE 9.1 auf 1&1 RootServer, ohne Confixx):

Mit Yast oder per Shell angelegte neue User können sich nicht per SSH auf dem Server einloggen. Sie erhalten nur ein lapidares Access denied beim Loginversuch.

Neue User gehören zur Gruppe "users", haben "/bin/bash" als Shell, Username und Passwort. Das hat auf dem alten System mit SuSE 7.2 immer ausgereicht, um per SSH Zugriff zu haben.

Kann mir jemand auf die Sprünge helfen und mir sagen, was ich übersehen haben könnte? Muss der User noch in einer anderen Gruppe Mitglied sein? Oder versteckt sich irgendwo noch ne Einstellung, die den Login standardmäßig für alle, außer Root verhindert?

Viele Grüße,
Tobias

[temal]

Wie sieht denn die sshd_config auf?

[tstening]

Wie sieht denn die sshd_config auf?

Hier die sshd_conf inkl. der nicht verwendeten Settings:

-----------------------------

# $OpenBSD: sshd_config,v 1.68 2003/12/29 16:39:50 millert Exp $
#Port 22
#Protocol 2,1
#ListenAddress 0.0.0.0
#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
#LogLevel INFO

# Authentication:
#LoginGraceTime 2m
#PermitRootLogin yes
#StrictModes yes

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

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

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

# GSSAPI options
#GSSAPIAuthentication no
# Set this to 'yes' to enable support for the deprecated 'gssapi' authentication
# mechanism to OpenSSH 3.8p1. The newer 'gssapi-with-mic' mechanism is included
# in this release. The use of 'gssapi' is deprecated due to the presence of
# potential man-in-the-middle attacks, which 'gssapi-with-mic' is not susceptib$
#GSSAPIEnableMITMAttack no

# Set this to 'yes' to enable PAM authentication (via challenge-response)
# and session processing. Depending on your PAM configuration, this may
# bypass the setting of 'PasswordAuthentication' and 'PermitEmptyPasswords'
UsePAM yes

#AllowTcpForwarding yes
#GatewayPorts 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/sshd.pid
#MaxStartups 10

# no default banner path
#Banner /some/path
# override default of no subsystems
Subsystem sftp /usr/lib/ssh/sftp-server

-----------------------------

Viele Grüße,
Tobias

[marce]

PasswordAuthentication no
ist denn der key des Users hinterlegt?

[tstening]

PasswordAuthentication no
ist denn der key des Users hinterlegt?

Ähem, nein. Bin nicht davon ausgegangen, dass ich Authentifizierung per PublicKey benötige, da der Root ja aktuell auch ohne seinen Schlüssel nur mit dem Passwort Zugriff hat. Ändere ich den Wert auf PasswordAuthentication yes funktioniert es prima.

Auf dem alten System hatten einige User Schlüssel, andere nicht. Das sollte der nächste Schritt sein, diese wieder einzubinden.

Danke für den Tipp. :-)

Gruss, Tobias