KeyHelp Community

Server-Betriebssystem + Version
Debian 10+11

KeyHelp-Version + Build-Nummer
22.2 (Build 2838) - Pro und normal...

Problembeschreibung / Fehlermeldungen
SSH Login nicht möglich für Benutzer

Erwartetes Ergebnis
SSH Login möglich (wenn freigegeben)

Tatsächliches Ergebnis
nix... kein Login... weder mit noch ohne chroot umgebung... nach 3 Versuchen im Fail2Ban, trotz richtigem PW

Schritte zur Reproduktion
mehrere Server und Benutzer probiert...

Servus miteinander,

habe ich noch irgendeine Einstellung übersehen? Mit root funktioniert der Login problemlos. Nur ich bekomme es mit keinerlei Benutzer hin. In der Doku finde ich auch nichts. Die Logs sind auch ruhig. Ich wette es ist irgendeine depperte Einstellung die ich übersehe/überlese...

SSH (und CHROOT bei PRO) habe ich natürlich für die User gesetzt. Passwort habe ich das selbe wie für den Backend Login probiert (Backend Login funktioniert).

Danke schonmal fürs Augen öffnen

Vorneweg:
Ich habe gerade versucht, deine Situation zu reproduzieren...
System Debain 11 mit KH Pro, Testuser mit allen nötigen Berechtigungen und SSH-Einschränkungen erstellt...und der Login aufs CLI funktioniert problemlos.

2 Fragen:
- Verwendest du zufällig Sonderzeichen in deinen Passwörtern?
- Was sagen die Logs und der SSH-Client beim Loginversuch?

marci wrote: ↑Thu 24. Nov 2022, 19:03 trotz richtigem PW

Wir haben 2022. Du solltest Deine Arbeitsweise überdenken.

Hint: https://www.server-world.info/en/note?o ... &p=ssh&f=4

Ansonsten: ssh -vvvv sagt mehr …

24unix wrote: ↑Thu 24. Nov 2022, 19:47
marci wrote: ↑Thu 24. Nov 2022, 19:03 trotz richtigem PW
Wir haben 2022. Du solltest Deine Arbeitsweise überdenken.

Hint: https://www.server-world.info/en/note?o ... &p=ssh&f=4

Ansonsten: ssh -vvvv sagt mehr …

Weniger großkotzig rumquatschen und mal mehr Lösungsorientiert kommentieren.

Und wenn schon auf die Verwendung von SSH-Keys hinweißt, dann auch bitte auf KH Basis.

Unter Windoof kann dieser zB. mit PuTTYgen erstellt werden.

OlliTheDarkness wrote: ↑Fri 25. Nov 2022, 00:44 Unter Windoof kann dieser zB. mit PuTTYgen erstellt werden.

Du weißt, dass ich den Spielestarter nicht als sinnvolle Arbeitsumgebung sehe, aber selbst da sollte man keine Passwörter fürs Login via ssh verwenden.

Hallo,

Zumindest die /var/log/auth.log sollte Informationen über den Login-Versuch enthalten. Schau da einmal rein.

Ich vermute mal ganz stark das "marci" meint der "Name" des SSH Schlüssel ist auch der Login-Name..
Über dieses Problem sind auch einige Kunden bei mir gestolpert..
Der Benutzername ist immer der, der in der Benutzerverwaltung angezeigt wird. Der Name für den SSH Schlüssel, ist nur dafür da, um dem Schlüssel einen eindeutigen Namen zu geben.

Ich stelle kurioser Weise aktuell das selbe Problem von meinem Arbeitsrechner aus fest. Scheint aber ein Client-Problem zu sein. Von anderen Rechnern / Servern (mit dem selben Passwort in der Zwischenablage) komm ich problemlos auf den Server. Ich schaue am Montag nochmal genauer, woran das liegen könnte.

Alex maybe an idea, but I noticed before that many clients (try to) login with IPv6 and not IPv4.
This often causes problems. I changed SSH to IPv4 only.

I asked Cinfu.com to restrict my number of IPv6 addresses to 2, it it won't use any other address for incoming and outgoing.
As it cause problems with Postfix as well.

If you have 6x IPv6, the servers will/can use all 6, when limited to just 2 IPv6 and 1 IPv4 the problem is gone.

I know email and SSH are not the same, but it could be related. I got rejected as Postfix used non-Keyhelp assigned addresses.

Beware, may ISP's will assign 6 or more IPv6 addresses, but KeyHelp only assigns 2, yet all others are used if they are active.

Not saying this is the problem, but it is with e.g. Postfix and SPF, reverse-DNS etc.

Guten Morgen,

ich arbeite normalerweise mit ssh keys und kenne das Problem nicht.

Da wir jetzt aber eine Agentur auf einen Kundenordner drauf lassen "müssen" und die von mehreren PCs daher kommen und das nicht kennen muss das Passwort herhalten.

Das mit den Sonderzeichen ist aber ein guter Einwand, den ich bisher noch nie als Problem gesehen habe. Vor allem da ich das Passwort auch in der Shell mal von Hand nochmal neu gesetzt hatte zur Sicherheit und trotzdem auf das selbe Problem gestoßen bin.

Sorry das ich mich die letzten Tage nicht gemeldet habe. Aber ich schau jetzt gleich mal, ob es daran liegen könnte und berichte dann weiter.

Wenns nicht erklär ich der Agentur eh das mit dem SSH Key. Dann müssen die sich einen Server suchen von dem aus sie dann immer bei dem Kunden zugreifen

Danke vorab und einen schönen Sonntag!

marci wrote: ↑Sun 27. Nov 2022, 08:36 Wenns nicht erklär ich der Agentur eh das mit dem SSH Key.

Solche Kunden, die dein Sicherheitskonzept nicht begreifen wollen, kannst du ganz schnell zuzm Dazulernen bewegen.
Dazu mußt du solchen Leuten einfach nur die juristische Keule vor Augen halten.

In deinem Beispiel mach denen zuerst klar, daß Key Based Auth die sicherere Methode gegenüber Paßwörtern ist.
Wenn die das begriffen haben, dann erklär ihnen, daß sie die rechtliche Verantwortung für Schäden tragen, weil sie grob fahrlässig handeln, wenn sie von dem höheren Schutzlevel von Keys wissen, aber trotzdem auf die schwächere Sicherheitslösung mit Paßwörtern setzen.

Wenn die Verantwortlichen nicht zu betriebsblind sind, dann wirst du so ein Umdenken erreichen.

So... Passwort war es nicht.... und bei mir ists wurscht ob ichs vom Windows probier oder einem anderen frisch installiertem Keyhelp Server mit Debian 11. IPv6 wars leider auch nicht...

Ich bin ja schon gespannt was Alexander evtl. noch raus bekommt und ich hoffe nicht das ich allein mit dem Problem bin

und noch zur Vollständigkeit die ssh-login log. Wie gesagt: 2 nagelneu installierte Keyhelp Server mit Debian 11:

Code: Select all

root@serverXX:~# ssh -vvvv kunde@test.meine-server.info
OpenSSH_8.4p1 Debian-5+deb11u1, OpenSSL 1.1.1n  15 Mar 2022
debug1: Reading configuration data /root/.ssh/config
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: include /etc/ssh/ssh_config.d/*.conf matched no files
debug1: /etc/ssh/ssh_config line 21: Applying options for *
debug3: expanded UserKnownHostsFile '~/.ssh/known_hosts' -> '/root/.ssh/known_hosts'
debug3: expanded UserKnownHostsFile '~/.ssh/known_hosts2' -> '/root/.ssh/known_hosts2'
debug2: resolving "test.meine-server.info" port 22
debug2: ssh_connect_direct
debug1: Connecting to test.meine-server.info [666.666.666.666] port 22.
debug1: Connection established.
debug1: identity file /root/.ssh/id_rsa type 0
debug1: identity file /root/.ssh/id_rsa-cert type -1
debug1: identity file /root/.ssh/id_dsa type -1
debug1: identity file /root/.ssh/id_dsa-cert type -1
debug1: identity file /root/.ssh/id_ecdsa type -1
debug1: identity file /root/.ssh/id_ecdsa-cert type -1
debug1: identity file /root/.ssh/id_ecdsa_sk type -1
debug1: identity file /root/.ssh/id_ecdsa_sk-cert type -1
debug1: identity file /root/.ssh/id_ed25519 type -1
debug1: identity file /root/.ssh/id_ed25519-cert type -1
debug1: identity file /root/.ssh/id_ed25519_sk type -1
debug1: identity file /root/.ssh/id_ed25519_sk-cert type -1
debug1: identity file /root/.ssh/id_xmss type -1
debug1: identity file /root/.ssh/id_xmss-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_8.4p1 Debian-5+deb11u1
debug1: Remote protocol version 2.0, remote software version OpenSSH_8.4p1 Debian-5+deb11u1
debug1: match: OpenSSH_8.4p1 Debian-5+deb11u1 pat OpenSSH* compat 0x04000000
debug2: fd 3 setting O_NONBLOCK
debug1: Authenticating to test.meine-server.info:22 as 'kunde'
debug3: hostkeys_foreach: reading file "/root/.ssh/known_hosts"
debug3: record_hostkey: found key type ECDSA in file /root/.ssh/known_hosts:11
debug3: load_hostkeys: loaded 1 keys from test.meine-server.info
debug3: order_hostkeyalgs: have matching best-preference key type ecdsa-sha2-nistp256-cert-v01@openssh.com, using HostkeyAlgorithms verbatim
debug3: send packet: type 20
debug1: SSH2_MSG_KEXINIT sent
debug3: receive packet: type 20
debug1: SSH2_MSG_KEXINIT received
debug2: local client KEXINIT proposal
debug2: KEX algorithms: 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,ext-info-c
debug2: host key algorithms: ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp521-cert-v01@openssh.com,sk-ecdsa-sha2-nistp256-cert-v01@openssh.com,ssh-ed25519-cert-v01@openssh.com,sk-ssh-ed25519-cert-v01@openssh.com,rsa-sha2-512-cert-v01@openssh.com,rsa-sha2-256-cert-v01@openssh.com,ssh-rsa-cert-v01@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,sk-ecdsa-sha2-nistp256@openssh.com,ssh-ed25519,sk-ssh-ed25519@openssh.com,rsa-sha2-512,rsa-sha2-256,ssh-rsa
debug2: ciphers ctos: chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com
debug2: ciphers stoc: chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com
debug2: MACs ctos: 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
debug2: MACs stoc: 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
debug2: compression ctos: none,zlib@openssh.com,zlib
debug2: compression stoc: none,zlib@openssh.com,zlib
debug2: languages ctos:
debug2: languages stoc:
debug2: first_kex_follows 0
debug2: reserved 0
debug2: peer server KEXINIT proposal
debug2: KEX algorithms: 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
debug2: host key algorithms: rsa-sha2-512,rsa-sha2-256,ssh-rsa,ecdsa-sha2-nistp256,ssh-ed25519
debug2: ciphers ctos: chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com
debug2: ciphers stoc: chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com
debug2: MACs ctos: 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
debug2: MACs stoc: 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
debug2: compression ctos: none,zlib@openssh.com
debug2: compression stoc: none,zlib@openssh.com
debug2: languages ctos:
debug2: languages stoc:
debug2: first_kex_follows 0
debug2: reserved 0
debug1: kex: algorithm: curve25519-sha256
debug1: kex: host key algorithm: ecdsa-sha2-nistp256
debug1: kex: server->client cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none
debug1: kex: client->server cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none
debug3: send packet: type 30
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug3: receive packet: type 31
debug1: Server host key: ecdsa-sha2-nistp256 SHA256:LRtAe0PYLEMkANe4/ljsQAFHT46ZFNIL/serBtxjG34
debug3: hostkeys_foreach: reading file "/root/.ssh/known_hosts"
debug3: record_hostkey: found key type ECDSA in file /root/.ssh/known_hosts:11
debug3: load_hostkeys: loaded 1 keys from test.meine-server.info
debug3: hostkeys_foreach: reading file "/root/.ssh/known_hosts"
debug3: record_hostkey: found key type ECDSA in file /root/.ssh/known_hosts:12
debug3: load_hostkeys: loaded 1 keys from 666.666.666.666
debug1: Host 'test.meine-server.info' is known and matches the ECDSA host key.
debug1: Found key in /root/.ssh/known_hosts:11
debug3: send packet: type 21
debug2: set_newkeys: mode 1
debug1: rekey out after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug3: receive packet: type 21
debug1: SSH2_MSG_NEWKEYS received
debug2: set_newkeys: mode 0
debug1: rekey in after 134217728 blocks
debug1: Will attempt key: /root/.ssh/id_rsa RSA SHA256:eYB3E+W26/Cio0gxuB1J6O/OGVy/eaHR5i5oAaStTGg
debug1: Will attempt key: /root/.ssh/id_dsa
debug1: Will attempt key: /root/.ssh/id_ecdsa
debug1: Will attempt key: /root/.ssh/id_ecdsa_sk
debug1: Will attempt key: /root/.ssh/id_ed25519
debug1: Will attempt key: /root/.ssh/id_ed25519_sk
debug1: Will attempt key: /root/.ssh/id_xmss
debug2: pubkey_prepare: done
debug3: send packet: type 5
debug3: receive packet: type 7
debug1: SSH2_MSG_EXT_INFO received
debug1: kex_input_ext_info: server-sig-algs=<ssh-ed25519,sk-ssh-ed25519@openssh.com,ssh-rsa,rsa-sha2-256,rsa-sha2-512,ssh-dss,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,sk-ecdsa-sha2-nistp256@openssh.com,webauthn-sk-ecdsa-sha2-nistp256@openssh.com>
debug3: receive packet: type 6
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug3: send packet: type 50
debug3: receive packet: type 51
debug1: Authentications that can continue: publickey,password
debug3: start over, passed a different list publickey,password
debug3: preferred gssapi-with-mic,publickey,keyboard-interactive,password
debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Offering public key: /root/.ssh/id_rsa RSA SHA256:eYB3E+W26/Cio0gxuB1J6O/OGVy/eaHR5i5oAaStTGg
debug3: send packet: type 50
debug2: we sent a publickey packet, wait for reply
debug3: receive packet: type 51
debug1: Authentications that can continue: publickey,password
debug1: Trying private key: /root/.ssh/id_dsa
debug3: no such identity: /root/.ssh/id_dsa: No such file or directory
debug1: Trying private key: /root/.ssh/id_ecdsa
debug3: no such identity: /root/.ssh/id_ecdsa: No such file or directory
debug1: Trying private key: /root/.ssh/id_ecdsa_sk
debug3: no such identity: /root/.ssh/id_ecdsa_sk: No such file or directory
debug1: Trying private key: /root/.ssh/id_ed25519
debug3: no such identity: /root/.ssh/id_ed25519: No such file or directory
debug1: Trying private key: /root/.ssh/id_ed25519_sk
debug3: no such identity: /root/.ssh/id_ed25519_sk: No such file or directory
debug1: Trying private key: /root/.ssh/id_xmss
debug3: no such identity: /root/.ssh/id_xmss: No such file or directory
debug2: we did not send a packet, disable method
debug3: authmethod_lookup password
debug3: remaining preferred: ,password
debug3: authmethod_is_enabled password
debug1: Next authentication method: password
kunde@test.meine-server.info's password:
debug3: send packet: type 50
debug2: we sent a password packet, wait for reply
debug3: receive packet: type 51
debug1: Authentications that can continue: publickey,password
Permission denied, please try again.
kunde@test.meine-server.info's password:

Jolinar wrote: ↑Sun 27. Nov 2022, 08:51 In deinem Beispiel mach denen zuerst klar, daß Key Based Auth die sicherere Methode gegenüber Paßwörtern ist.
Wenn die das begriffen haben, dann erklär ihnen, daß sie die rechtliche Verantwortung für Schäden tragen, weil sie grob fahrlässig handeln, wenn sie von dem höheren Schutzlevel von Keys wissen, aber trotzdem auf die schwächere Sicherheitslösung mit Paßwörtern setzen.

Wenn die Verantwortlichen nicht zu betriebsblind sind, dann wirst du so ein Umdenken erreichen.

Alles schon gemacht... ich hab jetzt auch nochmal eine Anleitung geschrieben, wie die die Keys erstellen können und mir zukommen lassen können... Also werden die dann so oder so umgestellt... Ansonsten könnens dann halt nicht per SSH drauf

Nichts desto trotz würde mich interessieren, warum der Login nicht funktioniert

Hat aber jetzt gar keine Eile mehr... Nur Interessens-Durst-Stillungs-Charakter

Alexander wrote: ↑Fri 25. Nov 2022, 09:35 Zumindest die /var/log/auth.log sollte Informationen über den Login-Versuch enthalten. Schau da einmal rein.

Magst du uns diese Infos noch zur Verfügung stellen? Eventuell ist aus diesen Logfileauszügen das Problem erkennbar...

marci wrote: ↑Sun 27. Nov 2022, 08:54 und noch zur Vollständigkeit die ssh-login log. Wie gesagt: 2 nagelneu installierte Keyhelp Server mit Debian 11:
Code: Select all
debug1: Authentications that can continue: publickey,password
Permission denied, please try again.
kunde@test.meine-server.info's password:

Das Problem liegt auf der Seite des Servers.

Musst da mal die entsprechenden Logs konsultieren, warum "kunde" kein ssh darf.

Was sagt

Code: Select all

grep "kunde" /etc/passwd

KeyHelp Community

SSH Benutzer Login nicht möglich

SSH Benutzer Login nicht möglich

Re: SSH Benutzer Login nicht möglich

Re: SSH Benutzer Login nicht möglich

Re: SSH Benutzer Login nicht möglich

Re: SSH Benutzer Login nicht möglich

Re: SSH Benutzer Login nicht möglich

Re: SSH Benutzer Login nicht möglich

Re: SSH Benutzer Login nicht möglich

Re: SSH Benutzer Login nicht möglich

Re: SSH Benutzer Login nicht möglich

Re: SSH Benutzer Login nicht möglich

Re: SSH Benutzer Login nicht möglich

Re: SSH Benutzer Login nicht möglich

Re: SSH Benutzer Login nicht möglich

Re: SSH Benutzer Login nicht möglich