expertenaustausch > linux.debian.user.german

Thomas (11.02.2018, 14:00)
Hallo,

ich habe schon als root Zugriff
PermitRootLogin yes
und auch diverses anderes "probiert".

Aber nichts geht, immer password falsch
Permission denied (publickey,password).
Auch wenn ich mich auf einen user einloggen will geht nichts.

Consolen Zugriff geht problemlos, password sind richtig.

Der ssh Server läuft, vom Rechner auf externe Ziele geht.

Auch purge und alles noch mal neu installieren ändert nichts.

Was ist ist da nur in der sshd config falsch.

Gruss
Frank Babies (11.02.2018, 14:20)
Hallo Thomas,

ist es denn von der "/etc/security/access.conf" her erlaubt?

LG,

Frank

Am 11.02.2018 um 12:55 schrieb Thomas:
[..]
Peter Ludikovsky (11.02.2018, 14:20)
Hallo,

nach purge & neu installieren sind deine Änderungen an der sshd_config
auch dahin.

Ich klär mal das übliche ab:
* Nach der Änderung an der sshd_config den Daemon neu gestartet?
* Irgendwelche Änderungen an der PAM-config?
* Tastatur-Layout stimmt auf beiden Seiten überein?

Lg
/peter

Am 11.02.2018 um 12:55 schrieb Thomas:
[..]
nac (11.02.2018, 14:30)
Hallo,

Am 11.02.2018 um 12:55 schrieb Thomas:
> Hallo,
> ich habe schon als root Zugriff
> PermitRootLogin yes
> und auch diverses anderes "probiert".
> Aber nichts geht, immer password falsch
> Permission denied (publickey,password).


Scheint so als hätte er gern einen Public Key statt eines Passworts.
Solltest du deinen bisherigen Key nicht mehr finden können, kannst du in
der /etc/ssh/sshd_config die Zeile "PubkeyAuthentication yes" auf "no"
setzen. Dann sollte ein Passwort Login möglich sein.

vlg

nac
Thomas (11.02.2018, 15:10)
Hallo,
danke für die vielen Tips.
aber nix geht.
Wenn das noch hilft, das ist ein SuperMicro Rechner.
install purge hatte ich gemacht um eine neue config zu erhalten, das
Verzeichnis vorher gelöscht und auch den Dienst neu gestartet.
/etc/security/access.conf ist alles auskommentiert, ist auch auf einen anderen
Rechner so der "funktioniert"

Die müssen doch da irgendwo einen Schalter gesetzte haben das extern ssh nicht
geht. Soll ich Stretch einfach nochmal installieren.

Gruss

Am Sonntag, 11. Februar 2018, 13:08:28 schrieb Peter Ludikovsky:
[..]
Martin Steigerwald (11.02.2018, 15:30)
nac - 11.02.18, 13:14:
> Am 11.02.2018 um 12:55 schrieb Thomas:
> Scheint so als hätte er gern einen Public Key statt eines Passworts.
> Solltest du deinen bisherigen Key nicht mehr finden können, kannst du in
> der /etc/ssh/sshd_config die Zeile "PubkeyAuthentication yes" auf "no"
> setzen. Dann sollte ein Passwort Login möglich sein.


Nur kurz ein Einwurf:

Ich lese das so, dass SSH hier Beides akzeptiert. Nur mit Schlüssel sieht so
aus:

~> ssh irgendeinrechner
Enter passphrase for key '[?]id_ed25519':
irgendeinrechner: Permission denied (publickey).

Für den OP noch:

Ein wiederholtes Neu-Installieren des SSH-Dienstes natürlich nicht
zielführend. Meine Empfehlung: Erst mal tief durchatmen, aufkommende Panik
willkommen heißen und los lassen und *dann* sich nochmal an die Problemlösung
wagen.

Ein Blick in /var/log/auth.log könnte hilfreich sein.

Danke,
Thomas (11.02.2018, 17:50)
Hallo,
die "bekannsten" Einstellungen habe ich ja schon geändert, auch mit neu
angelegten user statt root
purge löschen config Verzeichnis install
nur um zu verhindern eine gemachte Änderung übersehen zu haben.

/var/log/auth.log

pam_unix .. session opened
pam_unix .. session closed

Gruss

Am Sonntag, 11. Februar 2018, 14:24:47 schrieb Martin Steigerwald:
[..]
Henning Follmann (11.02.2018, 18:20)
On Sun, Feb 11, 2018 at 04:48:10PM +0100, Thomas wrote:
> Hallo,
> die "bekannsten" Einstellungen habe ich ja schon geändert, auch mit neu
> angelegten user statt root
> purge löschen config Verzeichnis install
> nur um zu verhindern eine gemachte Änderung übersehen zu haben.

Ist schon fazimierend wie wage Deine Aussagen sind. Wie erwartest Du, dass
Dir mit diesen Aussagen irgenwer sinnvoll helfen kann?

Also wenn Du eine default Konfiguration von der Debian Package installiert
hast erlaubt diese login vi password (nicht fuer root) und public key
authentication.

Schreibe doch einmal was Du wirklich unter
"bekannten" Einstellungen verstehst.

-H
Thomas Hochstein (11.02.2018, 20:10)
Thomas schrieb:

> Aber nichts geht, immer password falsch
> Permission denied (publickey,password).
> Auch wenn ich mich auf einen user einloggen will geht nichts.
> Consolen Zugriff geht problemlos, password sind richtig.


Blöde Frage, ich weiß: Du greifst über SSH auch ganz sicher auf die
richtige Maschine zu?
Dirk (11.02.2018, 21:10)
On Sun, Feb 11, 2018 at 01:00:14PM +0100, Frank Babies wrote:
> ist es denn von der "/etc/security/access.conf" her erlaubt?


Ehm? Mir wäre nicht bekannt, daß diese Datei irgendetwas benutzt. Bei
mir ist darin alles auskommentiert.

ciao, Dirk
Marc Haber (11.02.2018, 21:10)
On Sun, 11 Feb 2018 12:55:21 +0100, Thomas <thmeier> wrote:
>ich habe schon als root Zugriff
>PermitRootLogin yes
>und auch diverses anderes "probiert".
>Aber nichts geht, immer password falsch
>Permission denied (publickey,password).
>Auch wenn ich mich auf einen user einloggen will geht nichts.
>Consolen Zugriff geht problemlos, password sind richtig.


Abgesehen von allen anderen Tipps, die Du hier bekommen hast (die sind
alle richtig!), jetzt von mir die Frage, ob Du wirklich den direkten
root-Login, der nur mit einm Passwort gesichert ist, aus dem Internet
freigeben möchtest.

Bist Du Dir da ganz ganz sicher?

Grüße
Marc
Thomas (11.02.2018, 21:10)
Am Sonntag, 11. Februar 2018, 11:02:41 schrieb Henning Follmann:

> Also wenn Du eine default Konfiguration von der Debian Package installiert
> hast erlaubt diese login vi password (nicht fuer root) und public key
> authentication.
> Schreibe doch einmal was Du wirklich unter
> "bekannten" Einstellungen verstehst.


Das ist ein gekaufter Server mit Stretch vorinstalliert.
Installiere ich ssh komplett neu wird diese neue sshd_config geschrieben
Trotz Befolgung der hier gemachten Vorschläge funktioniert ein ssh Zugriff auf
den Rechner nicht.

Ich gebe ja zu das ist meine erste stretch Installation, aber bei allen
Versionen zuvor hatte ich niemals solche Probleme.
Einfach googeln, und schon konnte man sogar einschalten als root zuzugreifen.

Gruss

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

ChallengeResponseAuthentication no

#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
nac (11.02.2018, 21:20)
Ach und den ssh daemon neustarten

Am 11.02.2018 um 20:13 schrieb nac:
[..]
Thomas (11.02.2018, 21:20)
Am Sonntag, 11. Februar 2018, 18:45:21 schrieb Thomas Hochstein:

> Blöde Frage, ich weiß: Du greifst über SSH auch ganz sicher aufdie
> richtige Maschine zu?


Hallo,
nein, Frage ist nicht blöde.

Aber ich sehe den Zugriff in der auth.log
Und ich probiere von console, Laptop und einen anderen Desktop Rechner.

Gruss
Thomas (11.02.2018, 21:20)
Am Sonntag, 11. Februar 2018, 20:02:46 schrieb Marc Haber:

> Abgesehen von allen anderen Tipps, die Du hier bekommen hast (die sind
> alle richtig!), jetzt von mir die Frage, ob Du wirklich den direkten
> root-Login, der nur mit einm Passwort gesichert ist, aus dem Internet
> freigeben möchtest.


Hallo,
nein natürlich nicht, aber um auszuschließen das es am einfacher user liegt.
Das ist ja auch keine Installation mehr sondern rumprobieren.

PS: Der Rechner steht jetzt im LAN, der Zugriff erfolgt direkt auf die IP

Gruss

Ähnliche Themen