[Gelöst] SSH über xinetd nach Update geht nicht mehr

Alle weiteren Dienste, die nicht in die drei oberen Foren gehören.
Antworten
ObiTobi
Beiträge: 67
Registriert: 03.08.2016 20:50:26

[Gelöst] SSH über xinetd nach Update geht nicht mehr

Beitrag von ObiTobi » 10.08.2019 09:59:35

Hallo,

ich habe gestern 3 meinen VM's auf 10.0 upgedatet. Bei einer VM tut plötzlich ssh Zugang nicht mehr. Allerdings nur dann nicht wenn der Daemon über xinitd gesteuert wird. Starte ich den sshd "normal" funktioniert alles bestens.
In dem anderen Fall kommt beim Klient "ssh_exchange_identification: read: Connection reset" an.

Da bei allen Maschinen gleiche Konfig sowohl für xinetd wie auch sshd existiert bin ich etwas ratlos. Ideen wo ich ggf suchen soll?
Zuletzt geändert von ObiTobi am 03.10.2021 17:36:34, insgesamt 1-mal geändert.

Benutzeravatar
Blackbox
Beiträge: 4289
Registriert: 17.09.2008 17:01:20
Lizenz eigener Beiträge: GNU Free Documentation License

Re: SSH über xinetd nach Update geht nicht mehr

Beitrag von Blackbox » 22.08.2019 16:07:58

An dieser Stelle wäre es doch angebracht, deine bisherige Konfigurationsdateien zu posten.
Eigenbau PC: Debian Sid - Kernel: 6.5.13 - Xfce 4.18 mit sway
Desktop PC: Dell Inspiron 530 - Debian Sid - Kernel: 6.5.13 - Xfce 4.18 mit sway
Notebook: TUXEDO BU1406 - Debian Sid - Kernel: 6.5.13 - Xfce 4.18 mit sway
Alles Minimalinstallationen und ohne sudo/PA/PW.
Rootserver: Rocky Linux 9.3 - Kernel: 5.14

Freie Software unterstützen, Grundrechte stärken!

ObiTobi
Beiträge: 67
Registriert: 03.08.2016 20:50:26

Re: SSH über xinetd nach Update geht nicht mehr

Beitrag von ObiTobi » 24.09.2021 23:59:59

Mein altes Problem hat mich doch wieder eingeholt. Ich hatte damals es bei der einer VM einfach so umgestellt, dass sshd nativ und nicht über xinetd gestartet wird. Jetzt wollte ich es auf meinem Pi3 und zack - geht nicht.

cat /etc/xinetd.d/ssh

Code: Alles auswählen

service ssh
{
        socket_type     = stream
        protocol        = tcp
        wait            = no
        user            = root
        server          = /usr/sbin/sshd
        server_args     = -i
}
cat /etc/ssh/sshd_config

Code: Alles auswählen

#       $OpenBSD: sshd_config,v 1.100 2016/08/15 12:32:04 naddy Exp $

# This is the sshd server system-wide configuration file.  See
# sshd_config(5) for more information.

# This sshd was compiled with PATH=/usr/bin:/bin:/usr/sbin:/sbin

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

#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)
ChallengeResponseAuthentication 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 ChallengeResponseAuthentication and
# PasswordAuthentication.  Depending on your PAM configuration,
# PAM authentication via ChallengeResponseAuthentication may bypass
# the setting of "PermitRootLogin without-password".
# If you just want the PAM account and session checks to run without
# PAM authentication, then enable this but set PasswordAuthentication
# and ChallengeResponseAuthentication to 'no'.
UsePAM yes

#AllowAgentForwarding yes
#AllowTcpForwarding yes
#GatewayPorts no
X11Forwarding yes
#X11DisplayOffset 10
#X11UseLocalhost yes
#PermitTTY yes
PrintMotd no
#PrintLastLog yes
#TCPKeepAlive yes
#UseLogin no
#UsePrivilegeSeparation sandbox
#PermitUserEnvironment no
#Compression delayed
#ClientAliveInterval 0
#ClientAliveCountMax 3
#UseDNS no
#PidFile /var/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

ObiTobi
Beiträge: 67
Registriert: 03.08.2016 20:50:26

Re: [Gelöst] SSH über xinetd nach Update geht nicht mehr

Beitrag von ObiTobi » 03.10.2021 17:39:19

Auch hier war das Problem, fehlendes Verzeichnis.
Wenn im /etc/ssh Verzeichnis die Datei "sshd_not_to_be_run" vorliegt, wird kein /run/sshd Verzeichnis erstellt und damit kann sshd nicht gestartet werden.

Benutzeravatar
Blackbox
Beiträge: 4289
Registriert: 17.09.2008 17:01:20
Lizenz eigener Beiträge: GNU Free Documentation License

Re: [Gelöst] SSH über xinetd nach Update geht nicht mehr

Beitrag von Blackbox » 03.10.2021 20:44:16

Ein interessanter Fehler, den hatte ich in dieser Form noch nicht.
Eigenbau PC: Debian Sid - Kernel: 6.5.13 - Xfce 4.18 mit sway
Desktop PC: Dell Inspiron 530 - Debian Sid - Kernel: 6.5.13 - Xfce 4.18 mit sway
Notebook: TUXEDO BU1406 - Debian Sid - Kernel: 6.5.13 - Xfce 4.18 mit sway
Alles Minimalinstallationen und ohne sudo/PA/PW.
Rootserver: Rocky Linux 9.3 - Kernel: 5.14

Freie Software unterstützen, Grundrechte stärken!

Antworten