Verbindung mit ssh bei pro Version

[marco]

Ich bin sicher, dass die Ursache des Problems bei KeyHelp liegt
Ja

Server-Betriebssystem + Version
Debian 13


Eingesetzte Server-Virtualisierung-Technologie
KVM


KeyHelp-Version + Build-Nummer
25.3 (Build 3569)


Problembeschreibung / Fehlermeldungen
Der Server kann per ssh nur mit Key genutzt werden, das klappt auch prima. Bei Kunden wo der Benutzer ohne - im Namen ist geht es auch nur bei Nutzer die im Benutzername ein - haben nicht. Also Benutzer01 geht per ssh Benutzer-01 nicht.
Ich habe zum testen immer den selben Key benutzt und auch im Panel sind die Keys hinterlegt.
Im Log kommt nicht mal eine Info zu einer versuchten Verbindung bei Benutzern die ein - im Namen haben.
Kann das mal jemand prüfen? Wie gesagt bei mir gehen alle Kunden die als Benutzername nur Namen ohne - haben.
Ich hahe zum test mal ein Kunden test_01 angelegt, das geht ohne Probleme.

MfG
Marco

[Florian]

Hallo,

kann ich nicht nachvollziehen. Ich habe es auf einem Debian 13 getestet und dort geht ein Login eines Users mit Bindestrich im Usernamen problemlos

[marco]

Hmm eigenartig, ich habe extra zum testen auch neue Accounts angelegt.

[marco]

Es geht aber um den login mit filezilla und sftp und nicht um den login ins panel, ich hoffe ich wurde nicht falsch verstanden.

[marco]

Ich habe es gerade mal mit ssh Verbindung versucht, bei dem User test01 geht es mit dem key bei dem User test-01 nicht da schlägt dann irgendwann fail2ban zu. Es geht also weder per ssh in der Konsole mit - noch mit filezilla per sftp.

[marco]

Ich habe nun ein Systembenutzer mit adduser und - angelegt und da geht der Login mit Key (auch dem selben) ohne Probleme.
Wenn ich versuche mit Key und dem User test-01 (angelegt über Keyhelp) mich per ssh einzuloggen sehe ich im journalctl ein Fehler:

Code: Select all

User test-01 from 79.xx.1xx.xx not allowed because a group is listed in DenyGroups
Feb 28 07:11:26 mein-server.tld sshd-session[2045164]: Connection closed by invalid user test-01 79.xx.xx.xx port 60868 [preauth]

Wenn es vom System her kein Fehler gibt, was ich mir in diesem Fall nicht vorstellen kann, gibt es dann die Möglichkeit die bestehenden Usernamen zu ändern in einen ohne - ?

[Tobi]

Hat denn der User überhaupt ssh Rechte?

[marco]

Hat denn der User überhaupt ssh Rechte?

Ja hat er genau wie der test01 User und der Key ist bei beiden auch drin.

[mhagge]

Wie sieht

Code: Select all

cat /etc/ssh/sshd_config

aus?

Und was sagt die Ausgabe von

Code: Select all

groups test-01

Weil

Code: Select all

User test-01 from 79.xx.1xx.xx not allowed because a group is listed in DenyGroups

Das sieht danach aus, dass da in der Config was gesperrt wurde, wenn des beim User test01 klappt kann das aber nicht die Standard-Gruppe sein

Standard ist "nur"

Code: Select all

DenyGroups keyhelp_nossh keyhelp_suspended

Wenn da bei Dir nichts anderes steht, hat der User also entweder keine SSH-Rechte oder der Account wurde gesperrt

[marco]

Hallo, hier mal die Configs:

Code: Select all

# 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:/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 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 yes
#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
#PermitEmptyPasswords no

# Change to "yes" to enable keyboard-interactive authentication.  Depending on
# the system's configuration, this may involve passwords, challenge-response,
# one-time passwords or some combination of these and other methods.
# 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 and color environment variables
AcceptEnv LANG LC_* COLORTERM NO_COLOR

# 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

# Limit KeyHelp usergroup
DenyGroups keyhelp_nossh keyhelp_suspended

Match Group keyhelp_chroot
 ChrootDirectory %h
 AllowTCPForwarding no
 X11Forwarding no
Match all

Code: Select all

test-01 : test-01 keyhelp_file_manager keyhelp_nossh keyhelp_chroot

Bei test91 also ohne Strich:

Code: Select all

sudo groups test01
test01 : test01 keyhelp_file_manager keyhelp_chroot

Bei beiden ist aber im Panel alles gesetzt:
test-01:

test01:

Bei allen Kunden mit - im Namen steh keyhelp_nossh mit dabei bei der Gruppe

[mhagge]

Sieht so weit erst mal in Ordnung aus.

Ich habe es gerade mal bei mir nachgestellt - ein user test-01 angelegt, SSH-Recht, SSH-Key hinterlegt (und es ist ein Debian-13-System) - hat alles anstandslos geklappt, richtige Gruppenzugehörigkeit und SSH-Login klappt auch problemlos.

Ein generelles Problem scheint es also schon mal nicht zu sein. Was ist bei Dir anders …? Was passiert denn, wenn Du den Nutzer noch einmal neu abspeicherst (mal ein Recht wegnehmen, speichern, anschließend wieder neu vergeben und speichern – dann sollte das auf jeden Fall neu getriggert werden)?

[marco]

Ich habe die rechte im panel schon weg genommen und neu gesetzt alles ohne Erfolg. Das System wurde im Januar installiert und die Benutzer wurden mit keyhelp umgezogen. Aufgefallen ist es mir erst jetzt weil ich allen ssh geben wollte und ich bei einigen eigenen Accounts die mit - sind keine Verbindung hinbekommen habe.
wie gesagt rechte nehmen, neu geben alles ohne Erfolg bei Benutzer im keyhelp mit -.
Es läuft noch ein amp im Leerlauf aber das kann ja nun damit nichts zu tun haben das Benutzer mit - im keyhelp falsche Gruppen bekommen.

[Florian]

Hallo,

dann schau doch mal in die /etc/group wo Dein User da einsortiert ist.

Wenn er sich per SSH einloggen soll, darf er nicht in der Gruppe keyhelp_nossh sein. Bei aktiviertem Chroot taucht er in der Gruppe keyhelp_chroot auf.

[marco]

Aber genau das scheint ja bei Benutzern mit - im nanem bei mir zu passieren:

Code: Select all

sudo groups test-01
[sudo] Passwort für marco:
test-01 : test-01 keyhelp_file_manager keyhelp_nossh keyhelp_chroot

[Waldfee]

Hi, sorry wenn ich mich da jetzt einmische aber.

Es wurde gesagt, man möchte bitte in der /etc/group gucken und kein groups test-01 ausführen.

Edit:
Genau da wird das Problem wahrscheinlich zu finden sein.

Genau bei

Code: Select all

keyhelp_nossh:x:1002:

darf der User nicht auftauchen.