ubuntuusers.de

Moin!

Scheinbar ist es bei Ubuntu nun der Standard, dass ein ssh Client keine PasswortAuthentication mehr versucht, wenn er sich zu einem Server verbinden soll - ganz gleich, ob der Server das anbietet oder nicht.

Während ich auf anderen Rechnern (Debian, Putty auf Windows) keine Probleme mit einer Passwort-Authentication zu besagtem Server habe, macht der ssh Client auf Ubuntu die Verbindung zu, sobald er feststellt, dass keiner der Schlüssel des Users passt. Erst mit

ssh -o PasswordAuthentication=yes user@server

kann ich ihn dazu überreden, mich um das Passwort zu bitten.

Kann man das global umkonfigurieren? Alles, was ich finden konnte, war für den jeweiligen Host einen Eintrag in ~/.ssh/config zu machen (und das lief bei meinem Test obendrein nicht). Die übrigen Suchergebnisse gingen immer in die Richtung "Passwort Authentication muss auf dem Server aktiviert sein" und "Ich will mich mit Schlüssel anmelden, aber er fragt trotzdem nach einem Passwort" (also beides nicht mein Problem).

Ich möchte nur für den Client einstellen, dass Passwort-Authentication immer eine valide Option ist. Für den Server auf der Maschine, von der aus ich mich verbinde, soll es nicht aktiv sein. Raus mit Passwort = ja - Rein mit Passwort = nein

Und bitte: ich weiß, wie ich mir Schlüssel mache und wie ich sie richtig auf dem Server hinterlege, damit ich mich damit anmelden kann. Ich weiß auch, dass es aus Sicherheitsgründen mitlerweile nicht mehr so gemacht wird. Der Server ist im LAN hinter einer Firewall (separate Maschine) und ist nicht ins Internet exposed. Ferner akzeptiert er nur Verbindungen aus dem LAN (nicht mal ausm VPN!).

inkasso schrieb:

Scheinbar ist es bei Ubuntu nun der Standard, dass ein ssh Client keine PasswortAuthentication mehr versucht, ...

Ob es nur "scheinbar" ist, kannst Du z. B. in der manpage der ssh_config nachschauen. Z. B.:

PasswordAuthentication
             Specifies whether to use password authentication.  The argument to this keyword must be yes (the default) or no.

oder

PasswordAuthentication
             Legt fest, ob Passwort-Authentifizierung verwandt werden soll. Das Argument für dieses Schlüsselwort muss yes (die Vorgabe) oder no sein.

Oder Du hast die Konfiguration des ssh-Clienten geändert und Du weißt das evtl. nicht mehr?

EDIT:

Du kannst es auch "global" ändern, mit z. B. den zusätzlichen Zeilen:

PubkeyAuthentication no
PasswordAuthentication yes

in der "/etc/ssh/ssh_config" (& Co.).

lubux schrieb:

Ob es nur "scheinbar" ist, kannst Du z. B. in der manpage der ssh_config nachschauen. Z. B.:

PasswordAuthentication
             Specifies whether to use password authentication.  The argument to this keyword must be yes (the default) or no.

Ist per default yes laut manpage

Oder Du hast die Konfiguration des ssh-Clienten geändert und Du weißt das evtl. nicht mehr? (...) in der "/etc/ssh/ssh_config" (& Co.).

OK... My bad: Hab die ssh_config tatsächlich editiert - aber unbewusst. Hab wohl die sshd_config editieren wollen und versehentlich die Falsche Datei erwischt.

Aber: PasswordAuthentication und KeyboardInteractive wieder aktiviert in der ssh_config hat nicht geholfen. Was könnte ich noch versemmelt haben? 😲

inkasso schrieb:

Aber: PasswordAuthentication und KeyboardInteractive wieder aktiviert in der ssh_config hat nicht geholfen. Was könnte ich noch versemmelt haben?

Wie ist die Ausgabe von:

ssh -v user@server

?

EDIT:

Versuch mal mit folgenden zusätzlichen und wirksamen Zeilen:

AuthenticationMethods password
PubkeyAuthentication no
PasswordAuthentication yes
PermitEmptyPasswords no
PermitRootLogin no
LoginGraceTime 0

in der "/etc/sshd_config" (... d. h. in der sshd-Server-config).

Die Serverseite ist ok. Sie bietet pubkey und password authentication an. Es geht ja auch von anderen Rechnern aus, und vom auch Problemkind, wenn ich explizit übersteuere.

Verbindungsaufbau vom Client aus:

$ ssh -v username@172.16.1.1
debug1: OpenSSH_10.0p2 Ubuntu-5ubuntu5, OpenSSL 3.5.3 16 Sep 2025
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Reading configuration data /etc/ssh/ssh_config.d/20-systemd-ssh-proxy.conf
debug1: /etc/ssh/ssh_config line 21: Applying options for *
debug1: Connecting to 172.16.1.1 [172.16.1.1] port 22.
debug1: Connection established.
debug1: identity file /home/username/.ssh/id_rsa type -1
debug1: identity file /home/username/.ssh/id_rsa-cert type -1
debug1: identity file /home/username/.ssh/id_ecdsa type -1
debug1: identity file /home/username/.ssh/id_ecdsa-cert type -1
debug1: identity file /home/username/.ssh/id_ecdsa_sk type -1
debug1: identity file /home/username/.ssh/id_ecdsa_sk-cert type -1
debug1: identity file /home/username/.ssh/id_ed25519 type -1
debug1: identity file /home/username/.ssh/id_ed25519-cert type -1
debug1: identity file /home/username/.ssh/id_ed25519_sk type -1
debug1: identity file /home/username/.ssh/id_ed25519_sk-cert type -1
debug1: identity file /home/username/.ssh/id_xmss type -1
debug1: identity file /home/username/.ssh/id_xmss-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_10.0p2 Ubuntu-5ubuntu5
debug1: Remote protocol version 2.0, remote software version OpenSSH_10.0p2 Debian-7
debug1: compat_banner: match: OpenSSH_10.0p2 Debian-7 pat OpenSSH* compat 0x04000000
debug1: Authenticating to 172.16.1.1:22 as 'username'
debug1: load_hostkeys: fopen /home/username/.ssh/known_hosts2: No such file or directory
debug1: load_hostkeys: fopen /etc/ssh/ssh_known_hosts: No such file or directory
debug1: load_hostkeys: fopen /etc/ssh/ssh_known_hosts2: No such file or directory
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: mlkem768x25519-sha256
debug1: kex: host key algorithm: ssh-ed25519
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
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: SSH2_MSG_KEX_ECDH_REPLY received
debug1: Server host key: ssh-ed25519 SHA256:<<redacted>>
debug1: load_hostkeys: fopen /home/username/.ssh/known_hosts2: No such file or directory
debug1: load_hostkeys: fopen /etc/ssh/ssh_known_hosts: No such file or directory
debug1: load_hostkeys: fopen /etc/ssh/ssh_known_hosts2: No such file or directory
debug1: Host '172.16.1.1' is known and matches the ED25519 host key.
debug1: Found key in /home/username/.ssh/known_hosts:1
debug1: ssh_packet_send2_wrapped: resetting send seqnr 3
debug1: rekey out after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: Sending SSH2_MSG_EXT_INFO
debug1: expecting SSH2_MSG_NEWKEYS
debug1: ssh_packet_read_poll2: resetting read seqnr 3
debug1: SSH2_MSG_NEWKEYS received
debug1: rekey in after 134217728 blocks
debug1: SSH2_MSG_EXT_INFO received
debug1: kex_ext_info_client_parse: server-sig-algs=<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>
debug1: kex_ext_info_check_ver: publickey-hostbound@openssh.com=<0>
debug1: kex_ext_info_check_ver: ping@openssh.com=<0>
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: SSH2_MSG_EXT_INFO received
debug1: kex_ext_info_client_parse: server-sig-algs=<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>
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: get_agent_identities: bound agent to hostkey
debug1: get_agent_identities: ssh_fetch_identitylist: agent contains no identities
debug1: Will attempt key: /home/username/.ssh/id_rsa 
debug1: Will attempt key: /home/username/.ssh/id_ecdsa 
debug1: Will attempt key: /home/username/.ssh/id_ecdsa_sk 
debug1: Will attempt key: /home/username/.ssh/id_ed25519 
debug1: Will attempt key: /home/username/.ssh/id_ed25519_sk 
debug1: Will attempt key: /home/username/.ssh/id_xmss 
debug1: Trying private key: /home/username/.ssh/id_rsa
debug1: Trying private key: /home/username/.ssh/id_ecdsa
debug1: Trying private key: /home/username/.ssh/id_ecdsa_sk
debug1: Trying private key: /home/username/.ssh/id_ed25519
debug1: Trying private key: /home/username/.ssh/id_ed25519_sk
debug1: Trying private key: /home/username/.ssh/id_xmss
debug1: No more authentication methods to try.
username@172.16.1.1: Permission denied (publickey,password).

inkasso schrieb:

Die Serverseite ist ok.

Es geht ja darum den Server so zu konfigurieren, dass der ssh-Client (nur) das macht, was Du haben/benutzen willst.

inkasso schrieb:

..., wenn ich explizit übersteuere.

Mit z. B. zusätzlich (siehe oben):

PubkeyAuthentication no
PasswordAuthentication yes

auf dem ssh-Client in der "/etc/ssh/ssh_config", musst Du nicht "explizit übersteuern".

inkasso schrieb:

Verbindungsaufbau vom Client aus:

...
debug1: Reading configuration data /etc/ssh/ssh_config.d/20-systemd-ssh-proxy.conf
...

BTW: Was und warum, hast Du in der Datei "/etc/ssh/ssh_config.d/20-systemd-ssh-proxy.conf" konfiguriert?

EDIT:

BTW: Die Vorgabe (Standard) der Reihenfolge für "PreferredAuthentications" beim ssh-Client ist:

gssapi-with-mic,hostbased,publickey,keyboard-interactive,password

Du könntest das in der config des ssh-Clienten, ändern mit der Zeile:

PreferredAuthentications password,publickey

lubux schrieb:

Es geht ja darum den Server so zu konfigurieren, dass der ssh-Client (nur) das macht, was Du haben/benutzen willst.

Na ich möchte ja sowohl als auch. Die Rechner, von denen aus ich regelmäßig mit dem Server arbeite, haben Zertifikats-Authentifizierung. Es gibt aber immer mal wieder Rechner, die "ausnahmsweise mal" ne Verbindung brauchen, und für die will ich es dann halt mit Passwort machen können.

Ist also keine Lösung die Pubkey-Authentifizierung ganz abzuschalten.

lubux schrieb:

auf dem ssh-Client in der "/etc/ssh/ssh_config", musst Du nicht "explizit übersteuern".

Ich meine nicht in der config übersteuern, sondern ich übersteuere es direkt in der Kommandozeile und es geht. Nur auf diesen Schritt es tun zu müssen, will ich halt verzichten, weil ich es beim nächsten Mal, wenn ich es brauche, bestimmt wieder vergessen habe...

$ ssh -o PasswortAuthentication=yes user@server

funktioniert

aber

$ ssh user@server

führt zum Abbruch der Verbindung durch den Client weil er die Passwort Authentication nicht versucht, wenn man es ihm nicht extra sagt.

lubux schrieb:

BTW: Was und warum, hast Du in der Datei "/etc/ssh/ssh_config.d/20-systemd-ssh-proxy.conf" konfiguriert?

Die Datei hab ich nicht erstellt/modifiziert. Aber den Inhalt geb ich dir gern:

# SPDX-License-Identifier: LGPL-2.1-or-later
#
# Allow connecting to the local host directly via ".host"
Host .host machine/.host
        ProxyCommand /usr/lib/systemd/systemd-ssh-proxy unix/run/ssh-unix-local/socket %p
        ProxyUseFdpass yes
        CheckHostIP no

# Make sure unix/* and vsock/* can be used to connect to AF_UNIX and AF_VSOCK paths.
# Make sure machine/* can be used to connect to local machines registered in machined.
#
Host unix/* vsock/* machine/*
        ProxyCommand /usr/lib/systemd/systemd-ssh-proxy %h %p
        ProxyUseFdpass yes
        CheckHostIP no

        # Disable all kinds of host identity checks, since these addresses are generally ephemeral.
        StrictHostKeyChecking no
        UserKnownHostsFile /dev/null

lubux schrieb:

EDIT:

BTW: Die Vorgabe (Standard) der Reihenfolge für "PreferredAuthentications" beim ssh-Client ist:

gssapi-with-mic,hostbased,publickey,keyboard-interactive,password

Du könntest das in der config des ssh-Clienten, ändern mit der Zeile:

PreferredAuthentications password,publickey

Ich habe mir den Verbindungsaufbau selbst schon mit debug Level 3 angesehen. Er bekommt vom Server, dass pubkey,password ok sind. Er versucht zuerst pubkey und scheitert am fehlenden passenden Schlüssel. Dann kommt, dass password die remaining method ist und danach gibt er auf, ohne mich nach dem Passwort zu fragen.

Auf der Serverseite steht im Log, dass der Client die Verbindung getrennt hat vor Authentifizierung.

Bis ich raus hatte, dass ich explizit mit -o PasswortAuthentication=yes übersteuern muss, habe ich das Gegenteil in der Kommandozeile versucht. Ich habe die Pubkey-Authentifizierung ausgeschlossen. Ich habe auch die PreferredAuthentications auf password gesetzt... half alles nichts.

inkasso schrieb:

Nur auf diesen Schritt es tun zu müssen, will ich halt verzichten, weil ich es beim nächsten Mal, wenn ich es brauche, bestimmt wieder vergessen habe...

Dann solltest du das was du in der Kommandozeile z. Zt. benutzt, in eine eigene user-config-Datei im home-Verzeichnis des users (der den ssh-Client benutzt) "~/.ssh/config" (die evtl. noch erstellt werden muss), für den einen sshd-Server (Host <host>) mit der richtigen Syntax eintragen und benutzen.

EDIT:

inkasso schrieb:

Alles, was ich finden konnte, war für den jeweiligen Host einen Eintrag in ~/.ssh/config zu machen (und das lief bei meinem Test obendrein nicht).

Poste mal von deinem Client/user den Inhalt der "~/.ssh/config", mit der es bei deinen Tests nicht funktioniert hat bzw. nicht lief.

EDIT 2:

Hier ein funktionierendes Beispiel für den Eintrag/Ergänzung in der "~/.ssh/config" (beim ssh-Client), für einen Host (sshd-Server) mit _nur_ (d. h. lediglich) Passwort-Authentifizierung:

Host <host>
	HostName <IP-Adresse-sshd-Server>
	BindAddress <IP-Adresse-ssh-Client>
	CheckHostIP yes
	AddressFamily inet
        PubkeyAuthentication no
	PasswordAuthentication yes
	VerifyHostKeyDNS no
	UserKnownHostsFile /dev/null
	Ciphers chacha20-poly1305@openssh.com
	StrictHostKeyChecking no
	Protocol 2
	Port 22
	User <user-auf-dem-sshd-Server>

(Eintrag zwischen den spitzen Klammern anpassen und dann die spitzen Klammern weglassen!).
Danach die Verbindung vom ssh-Client, mit:

ssh -v <host>

(host anpassen und ohne spitze Klammern!) herstellen.

Das schaut dann in der Ausgabe mit "-v" u. a. auch so:

...
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: Next authentication method: keyboard-interactive
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: Next authentication method: password
<user-sshd>@<IP-Adresse-sshd-Server>'s password: 
Authenticated to <IP-Adresse-sshd-Server> ([<IP-Adresse-sshd-Server>]:22) using "password".
...

aus.

Host <IP-Adresse-sshd-Server>
	HostName <IP-Adresse-sshd-Server>
        PubkeyAuthentication no
	PasswordAuthentication yes

So sah die Datei aus. Rechte 755.

Und wenn ich das mit der config hinbekomme, ist es zwar für diesen Fall ok - aber die eigentliche Frage, wie ich das GLOBAL umstelle, ist damit nicht gelöst. Wenn ich irgendwann einen anderen SSH Server per Passwort connecten will, tritt das Problem wieder auf.

Werde gleich sicherheitshalber noch einmal die ssh_config durchgehen sowie alle Dateien in /etc/ssh/ssh_config.d. In meinem ~/.ssh/ habe ich aktuell nur die authorized_keys und die known_hosts. Die config hatte ich nach Fehlschlag gelöscht.

inkasso schrieb:

Host <IP-Adresse-sshd-Server>
	HostName <IP-Adresse-sshd-Server>
        PubkeyAuthentication no
	PasswordAuthentication yes

Verwende mal als Host nicht die IP-Adresse, sondern einen Namen (z. B. mypwaserver oder gleichwertig). Verbinden dann mit "ssh -v mypwaserver".

inkasso schrieb:

Und wenn ich das mit der config hinbekomme, ist es zwar für diesen Fall ok - aber die eigentliche Frage, wie ich das GLOBAL umstelle, ist damit nicht gelöst.

Das habe ich dir doch schon gezeigt/geschrieben (siehe weiter oben). "Globale" Einstellungen für alle Hosts (gültig), macht man in der /etc/ssh/ssh_config.

inkasso schrieb:

Wenn ich irgendwann einen anderen SSH Server per Passwort connecten will, tritt das Problem wieder auf.

Nein, denn in der "~/.ssh/config" kann man mehrere Hosts anlegen/konfigurieren. Ich habe in meinen "~/.ssh/config"-Dateien ca. 10 Hosts(-Zugänge) konfiguriert (verschieden, nur mit pubkey- und/oder nur mit password-Authentication).

lubux schrieb:

Das habe ich dir doch schon gezeigt/geschrieben (siehe weiter oben). "Globale" Einstellungen für alle Hosts (gültig), macht man in der /etc/ssh/ssh_config.

Und ich hatte geschrieben, dass es trotzdem nicht geht.

lubux schrieb:

Nein, denn in der "~/.ssh/config" kann man mehrere Hosts anlegen/konfigurieren. Ich habe in meinen "~/.ssh/config"-Dateien ca. 10 Hosts(-Zugänge) konfiguriert (verschieden, nur mit pubkey- und/oder nur mit password-Authentication).

Das Problem tritt auf, ich muss mich dran erinnern, dass ich mit der config Datei einen Workaround bauen muss und dann muss ich ihn eintragen. Das ist damit gemeint.

Wie gesagt: ich schau nachher als erstes mal, ob ich noch irgendwo einen Fehler finden kann in der ssh_config oder in den include-Directories.

inkasso schrieb:

..., dass ich mit der config Datei einen Workaround bauen muss und dann muss ich ihn eintragen. Das ist damit gemeint.

Das ist kein "Workaround", sondern übliche/richtige/beabsichtigte Konfiguration für den ssh-Client, wie sie von den devs (... auch lt. der Doku für ssh_config) vorgesehen ist.

Für mich ist es ein Workaround, weil es bisher immer out of the Box ohne Klimmzüge funktioniert hat.

Nachdem ich immer noch nicht den Fehler finden konnte, habe ich jetzt die Standard-Konfigurationsdateien aus dem Paket wiederhergestellt. Bingo. Nun geht es wieder. Keine Ahnung was da im Argen lag, aber Danke für deine Bemühungen!

Das ist kein Workaround. Zitat Wikipedia:

Ein Workaround (englisch für „Notlösung“, „Behelfslösung“, „to work around something“ = „um etwas herum arbeiten“) ist ein Umweg zur Vermeidung eines bekannten Fehlverhaltens eines technischen Systems. Es ist ein Hilfsverfahren, das das eigentliche Problem nicht behebt, sondern mit zusätzlichem Aufwand seine Symptome umgeht.