Proxmox LXC Container - SSH Zugriff klappt nicht (bad configuration option: user)

[Orionatus]

Hallo liebe Wissende,

ich schreibe mal wieder einen Beitrag als Unwissender – und hoffe auf Eure Hilfe. Wie meistens sitzt das Problem vor dem Bildschirm.

Ich habe auf einem Dell Wyze 5070 (4Core CPU, Ram upgrade auf 16 GB, Upgrade auf 1TB SSD) Proxmox (Version 8.1.4) installiert und probiere diverse Anwendungen auf dem Heimserver aus.

Bei Homer bin ich auf das „Problem“ gestoßen, dass ich ja das ganze Dashboard in einer yml-Datei konfigurieren kann. In der Proxmox Konsole war mir das nicht komfortabel genug, daher habe ich versucht Visual Studio Code dafür zu verwenden und dort die Remote SSH-Extension installiert.

Leider schaffe ich es nicht, per SSH auf den LXC-Container zuzugreifen, auf dem Homer läuft. Ich habe die Proxmox Helper Scripts für die Erstellung verwendet.

Sowohl in VS Code als auch in der Windows Console funktioniert der SSH Zugriff nicht.

Ich bekomme folgenden Fehler:

Zuerst hatte ich das mal mit root versucht, dann einen neuen Benutzer angelegt – ich laufe immer auf diesen Fehler. Und ich sehe meinen Fehler nicht. Könnt Ihr mir bitte die richtige Richtung zeigen, ich habe mich verirrt.

Vielen lieben Dank

Orionatus

 

[LasseSamenström]

Also in deinem Post ist eine Menge falsch.

Bei Homer bin ich auf das „Problem“ gestoßen, dass ich ja das ganze Dashboard in einer yml-Datei konfigurieren kann.

Da steht nur wie du unter Docker HOMER betriebsbereit einrichtest.

Leider schaffe ich es nicht, per SSH auf den LXC-Container zuzugreifen

poste doch mal die .ssh...

Ich habe die Proxmox Helper Scripts für die Erstellung verwendet.

Weißt du überhaupt was diese tun?

und die lxc config posten wäre auch schön

 

[Orionatus]

Also in deinem Post ist eine Menge falsch.

:-(

Da steht nur wie du unter Docker HOMER betriebsbereit einrichtest.

hmmm? Ich hab nur verlinkt, was ich installiert habe?

poste doch mal die .ssh...

das ist die lokale ssh.config

Host Homer
  HostName 192.168.x.y
  User: root

Aufruf entsprechend

ssh username@192.168.x.y

auf dem LXC-Container sehen die Config-Dateien wie folgt aus:

ssh_config

# This is the ssh client system-wide configuration file.  See
# ssh_config(5) for more information.  This file provides defaults for
# users, and the values can be changed in per-user configuration files
# or on the command line.

# Configuration data is parsed as follows:
#  1. command line options
#  2. user-specific file
#  3. system-wide file
# Any configuration value is only changed the first time it is set.
# Thus, host-specific definitions should be at the beginning of the
# configuration file, and defaults at the end.

# Site-wide defaults for some commonly used options.  For a comprehensive
# list of available options, their meanings and defaults, please see the
# ssh_config(5) man page.

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

Host *
#   ForwardAgent no
#   ForwardX11 no
#   ForwardX11Trusted yes
#   PasswordAuthentication yes
#   HostbasedAuthentication no
#   GSSAPIAuthentication no
#   GSSAPIDelegateCredentials no
#   GSSAPIKeyExchange no
#   GSSAPITrustDNS no
#   BatchMode no
#   CheckHostIP yes
#   AddressFamily any
#   ConnectTimeout 0
#   StrictHostKeyChecking ask
#   IdentityFile ~/.ssh/id_rsa
#   IdentityFile ~/.ssh/id_dsa
#   IdentityFile ~/.ssh/id_ecdsa
#   IdentityFile ~/.ssh/id_ed25519
#   Port 22
#   Ciphers aes128-ctr,aes192-ctr,aes256-ctr,aes128-cbc,3des-cbc
#   MACs hmac-md5,hmac-sha1,umac-64@openssh.com
#   EscapeChar ~
#   Tunnel no
#   TunnelDevice any:any
#   PermitLocalCommand no
#   VisualHostKey no
#   ProxyCommand ssh -q -W %h:%p gateway.example.com
#   RekeyLimit 1G 1h
#   UserKnownHostsFile ~/.ssh/known_hosts.d/%k
    SendEnv LANG LC_*
    HashKnownHosts yes
    GSSAPIAuthentication yes

sshd_config

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

 

[Azghul0815]

Weißt du überhaupt was diese tun?

Na eben die passenden Container installieren.

Erste Antwort bei Google:

 

[oicfar]

Das

PasswordAuthentication yes

sollte man aber auch erlauben. Dann muss man den ssh deamon restarten.

 

[LasseSamenström]

Und wenn man sich das Script mal richtig anguckt, erkennt man dass das Script ssh gar nicht aktiviert

 

[Orionatus]

service ssh status
* ssh.service - OpenBSD Secure Shell server
     Loaded: loaded (/lib/systemd/system/ssh.service; enabled; preset: enabled)
     Active: active (running) since Sun 2024-01-21 15:37:45 CET; 1h 25min ago
TriggeredBy: * ssh.socket
       Docs: man:sshd(8)
             man:sshd_config(5)
    Process: 11654 ExecStartPre=/usr/sbin/sshd -t (code=exited, status=0/SUCCESS)
   Main PID: 11655 (sshd)
      Tasks: 1 (limit: 18888)
     Memory: 1.6M
        CPU: 46ms
     CGroup: /system.slice/ssh.service
             `-11655 "sshd: /usr/sbin/sshd -D [listener] 0 of 10-100 startups"

Jan 21 15:37:45 homer systemd[1]: Starting ssh.service - OpenBSD Secure Shell server...
Jan 21 15:37:45 homer sshd[11655]: Server listening on 0.0.0.0 port 22.
Jan 21 15:37:45 homer sshd[11655]: Server listening on :: port 22.
Jan 21 15:37:45 homer systemd[1]: Started ssh.service - OpenBSD Secure Shell server.

hmm, sieht für mich aktiv aus?

 

[oicfar]

Ist doch oben in sshd_config

#PasswordAuthentication yes

deaktiviert. Es muss so

PasswordAuthentication yes

aussehen.

Und dann noch

sudo service sshd restart

ausführen und ssh testen.

 

[Orionatus]

Danke, hab ich gemacht - keine Veränderung.

root@homer:/opt/homer/assets# systemctl status sshd.service
* ssh.service - OpenBSD Secure Shell server
     Loaded: loaded (/lib/systemd/system/ssh.service; enabled; preset: enabled)
     Active: active (running) since Sun 2024-01-21 17:05:23 CET; 1min 54s ago
TriggeredBy: * ssh.socket
       Docs: man:sshd(8)
             man:sshd_config(5)
    Process: 11774 ExecStartPre=/usr/sbin/sshd -t (code=exited, status=0/SUCCESS)
   Main PID: 11775 (sshd)
      Tasks: 1 (limit: 18888)
     Memory: 1.4M
        CPU: 46ms
     CGroup: /system.slice/ssh.service
             `-11775 "sshd: /usr/sbin/sshd -D [listener] 0 of 10-100 startups"

Hab die gleiche Zeile auch in der ssh_config auf dem LXC und lokal aktiviert - auch keine Veränderung.

Ich komme gar nicht zur Passwort-Abfrage.

VS Code gibt zusätzlich noch folgende Fehlermeldung aus. SSH stolpert aus irgendeinem Grund über Zeile 3 der ssh_config, oder nicht? Da steht nur "User: root" (und ich habs auch schon mit einem anderen User ausprobiert).

 .ssh/config: line 3: Bad configuration option: user

Ein Prozess hat versucht, zu einer nicht bestehenden Pipe zu schreiben.

 

[oicfar]

.ssh/config: line 3: Bad configuration option: user

Wie sieht das genau aus? In Zeile 3 hast du den Fehler.

 

[blablub1212]

Host Homer
  HostName 192.168.x.y
  User: root

Hier muss der Doppelpunkt nach User weg. Hier gibt es ein paar Beispiele und Erklärungen: https://linuxize.com/post/using-the-ssh-config-file/

 

[oicfar]

Und nun geht es. Oder?

 

[Orionatus]

jopp, danke. kA wo der Doppelpunkt herkam. Hab echt einiges versucht und habs nicht gefunden.

Tausend Dank für den Schubser in die richtige Richtung!

Ergänzung: klappt auch mit dem nicht-Root user!

 

[Azghul0815]

Danke auch von mir. Hab mich bisher aufgrund meines Posts mit der console im Browser rumgeschlagen

 

[oicfar]

jopp, danke. kA wo der Doppelpunkt herkam. Hab echt einiges versucht und habs nicht gefunden.

Du hattest 2 Fehler. Der Doppelpunkt und PasswordAuthentication war nicht erlaubt. Wenn du PasswordAuthentication wieder deaktivierst und ssh deamon restartest, dann wird SSH Login nicht gehen.

Und prinzipiell bei Problemen genau schauen, was für Fehler angezeigt werden. Dann erst selbst nach der Lösung suchen. Meist wird man schnell fündig. So lernt man die Probleme zu analysieren und zu lösen.

 

[XamBonX]

Nur zur info: 192.168.x.y brauchste net zu zensieren, wenn jemand da schon drin ist, sind die 192.168.x.y deine kleinste Probleme.

 

[Orionatus]

hmm, hast ja Recht.

Ergänzung (21. Januar 2024)

Und prinzipiell bei Problemen genau schauen, was für Fehler angezeigt werden. Dann erst selbst nach der Lösung suchen. Meist wird man schnell fündig. So lernt man die Probleme zu analysieren und zu lösen.

joa mache ich ja - ich hab - in müdem Zustand abends - mehrere Abende versucht, das zum Laufen zu bekommen. Leider sind Fehlermeldungen ja nicht immer sprechend. Wie hier jetzt auch, oder nicht?

Ein Prozess hat versucht, zu einer nicht bestehenden Pipe zu schreiben.

= da ist ein Doppelpunkt, der da nicht hingehört.

Bin noch nicht so lange mit Linux / Heimserver unterwegs und entsprechend viel gibt es zu lernen. Nervt etwas, wenn man jeden Befehl nachschlagen muss. seufzt

Danke nochmal für Eure Zeit und Hilfe.

 

[oicfar]

joa mache ich ja - ich hab - in müdem Zustand abends - mehrere Abende versucht, das zum Laufen zu bekommen. Leider sind Fehlermeldungen ja nicht immer sprechend. Wie hier jetzt auch, oder nicht?

Na der 1. Anhaltspunkt was "Bad configuration option" mit der Angabe der Zeile. Und 2. würde man auch finden können. Und ja, googeln muss man auch lernen, um die Lösungen zu bekommen, die man sucht.

Und aus Fehlern lernt man auch. Meistens.

 

[Azghul0815]

Bin noch nicht so lange mit Linux / Heimserver unterwegs und entsprechend viel gibt es zu lernen.

Geht mir genauso und wenn das Dingen läuft, fass ich es alle jubeljahre mal fürs Update an und proxmox läuft bei mir schon seit 3 Jahren 😂😂

 

[oicfar]

@Azghul0815 es ist schon sinnvoll regelmäßig upzudaten. Wenn man es sehr lange hinauszögert, dann muss man notfalls neu aufsetzen. Welche Proxmox Version hast du dann am Start? Aktuell ist ja 8.1.x.