root login

[xlerator]

hallo zusammen,

ich habe in der sshd_config den root login unterbunden, mit winscp funktioniert das auch, mit putty kann ich mich aber immernoch als root anmelden :? wie kann ich das ändern?

und gibts ne möglichkeit unter winscp den user zu switchen, weil als root kann ich mich ja dort nicht mehr anmelden.

danke,
xlr

[captaincrunch]

Du solltest nach der Ã?nderung auch den sshd neu starten.

[xlerator]

habe ich...

[captaincrunch]

Dann hast du ja auch kein Problem, und kannst dich auch per Putty nicht mehr als root anmelden. ;)

[xlerator]

ich kann mich aber in putty als root anmelden.

[captaincrunch]

Dann hast du wohl was falsch gemacht. Mehr zu sagen wäre aber reine Raterei, und dafür hab ich momentan keine Zeit (und auch keine Lust).

[xlerator]

kann das ein problem mit der PAM authentication sein?

[Joe User]

Ja.

[Anonymous]

Ja aber an der PAM hast Du doch nichts verändert oder? Poste doch mal die Config von Deinem sshd? :)

[xlerator]

das ist alles was nicht auskommentiert ist:

PermitRootLogin no
PasswordAuthentication no
PermitEmptyPasswords no
UsePAM yes
X11Forwarding yes

Subsystem sftp /usr/lib/ssh/sftp-server

[Joe User]

Code: Select all

UsePAM no
X11Forwarding no

[philipp]

Falls das Problem noch besteht, mach mal ein

Code: Select all

killall -9 sshd -HUP

Ging mir schon zweimal, aus welchen Gründen auch immer, so, dass ich nur auf diese Weise Konfigurationsänderungen anwenden konnte.

schönen Gruß

[oxygen]

Falls das Problem noch besteht, mach mal ein

Code: Select all

killall -9 sshd -HUP

Also was das darstellen soll ist mir ein Rätsel. Welches Signal möchtest du nun senden, KILL (-9) oder HUP?

[philipp]

Falls das Problem noch besteht, mach mal ein

Code: Select all

killall -9 sshd -HUP

Also was das darstellen soll ist mir ein Rätsel. Welches Signal möchtest du nun senden, KILL (-9) oder HUP?

-9 für das sofortige Killen
-HUP fürs Neustarten

War mir nicht bekannt, dass man offenbar nur ein Signal absetzen kann, bzw., dass -9 neben -HUP obsolet ist.

[oxygen]

1. sendet killall nur ein Signal (das letzte auf der Kommandozeile)
2. Wenn dem nicht wäre, würde zu erst -9 durchkommen, d.h. sshd sich beenden und dann würde HUP gesendet. Aber da gäbs schon kein Prozess mehr, der das Signal empfangen könnte. Das macht ja nun erst Recht keinen Sinn.

[wolfseye]

Tja, ich habe ein ähnliches Problem, mein Server hat SUSE 9, und ich hab jetzt schon probiert, was ihr hier geschrieben habt, und auch ohne. Kann mich aber immer wieder als ROOT einloggen.
Bei meinem DEBIAN root klappt das, da kann ich mich jetzt nur noch als User einloggen.
Ist bei SUSE was anders was das betrifft ?

Mfg

Wolfseye

[flo]

poste doch mal die config - evtl. hast Du ja was übersehen ...

flo.

[wolfseye]

Was das komische ist, und jetzt sagt bitte nicht sowas wegen n00b etc, bin halt kein LINUX Fachmann, aber normalerweise sind doch Zeilen die ein # davor haben, nicht benutzt in der Config, das ist doch richtig, oder ?

Weil bei dem SUSE sieht das so aus:

#Port 22
#Protocol 2,1
#ListenAddress 0.0.0.0
#ListenAddress ::

# HostKey for protocol version 1
#HostKey /etc/ssh/ssh_host_key
# HostKeys for protocol version 2
#HostKey /etc/ssh/ssh_host_rsa_key
#HostKey /etc/ssh/ssh_host_dsa_key

# Lifetime and size of ephemeral version 1 server key
#KeyRegenerationInterval 1h
#ServerKeyBits 768

# Logging
#obsoletes QuietMode and FascistLogging
#SyslogFacility AUTH
#LogLevel INFO

# Authentication:

#LoginGraceTime 2m
PermitRootLogin no
#StrictModes yes
#MaxAuthTries 6

#RSAAuthentication yes
#PubkeyAuthentication yes
#AuthorizedKeysFile .ssh/authorized_keys

# For this to work you will also need host keys in /etc/ssh/ssh_known_hosts
#RhostsRSAAuthentication no
# similar for protocol version 2
#HostbasedAuthentication no
# Change to yes if you don't trust ~/.ssh/known_hosts for
# RhostsRSAAuthentication and 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 no
#PermitEmptyPasswords no

# Change to no to disable s/key passwords
#ChallengeResponseAuthentication yes

# Kerberos options
#KerberosAuthentication no
#KerberosOrLocalPasswd yes
#KerberosTicketCleanup yes
#KerberosGetAFSToken no

# GSSAPI options
#GSSAPIAuthentication no
#GSSAPICleanupCredentials yes

# Set this to 'yes' to enable support for the deprecated 'gssapi' authentication
# mechanism to OpenSSH 3.8p1. The newer 'gssapi-with-mic' mechanism is included
# in this release. The use of 'gssapi' is deprecated due to the presence of
# potential man-in-the-middle attacks, which 'gssapi-with-mic' is not susceptible to.
#GSSAPIEnableMITMAttack 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 mechanism.
# Depending on your PAM configuration, this may bypass the setting of
# PasswordAuthentication, PermitEmptyPasswords, and
# "PermitRootLogin without-password". If you just want the PAM account and
UsePAM yes

#AllowTcpForwarding yes
#GatewayPorts no
X11Forwarding yes
#X11DisplayOffset 10
#X11UseLocalhost yes
#PrintMotd yes
#PrintLastLog yes
#TCPKeepAlive yes
#UseLogin no
#UsePrivilegeSeparation yes
#PermitUserEnvironment no
#Compression yes
#ClientAliveInterval 0
#ClientAliveCountMax 3
#UseDNS yes
#PidFile /var/run/sshd.pid
#MaxStartups 10

# no default banner path
#Banner /some/path

# override default of no subsystems
Subsystem sftp /usr/lib/ssh/sftp-server

Und da ist doch fast alles mit # ausgeklammert oder sehe ich das falsch ? Bei meinem DEBIAN sieht das so aus wie es sein soll. Wenn der SSHD dann bei dem SUSE dann aber doch irgendwo seine Config hernehmen muss, dann doch aus der o.g. Config, oder nicht ?
Sehr merkwürdig. Btw, der SUSE root ist übrigens von Server4you.

Wolfseye

[flo]

Code: Select all

UsePAM no
X11Forwarding no

[wolfseye]

Was mich aber auch wundert und ich nicht ganz verstehe, wieso sind hier bei dem SUSE Server in der Config fast alle Sachen mit der # ausgekennzeichnet, was doch heisst das die Zeilen nicht benutzt werdenm oder ?
Und bei dem DEBIAN sind fast alle ohne #. Nimmt der bei dem SUSE die Sachen aus ner anderen Config oder ist das richtig so ?

Mfg

Wolfseye

[Roger Wilco]

Nimmt der bei dem SUSE die Sachen aus ner anderen Config oder ist das richtig so ?

Die Defaultwerte stehen in der Manpage sshd_config(5). Lies dir die auf jeden Fall durch und schau dir deine Konfiguration danach nochmal an. Falls du danach wirklich noch Fragen haben solltest kannst du ja nochmal schreiben.

[mr_neutron]

Was das komische ist, und jetzt sagt bitte nicht sowas wegen n00b etc, bin halt kein LINUX Fachmann, aber normalerweise sind doch Zeilen die ein # davor haben, nicht benutzt in der Config, das ist doch richtig, oder ?

Wolfseye

Code: Select all

#       $OpenBSD: sshd_config,v 1.72 2005/07/25 11:59:40 markus Exp $

# 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:/bin:/usr/bin

# 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 change a
# default value.

Entweder du hast da was übersehen oder SuSE hat den block aus welchen Gründen auch immer rausgelöscht.

[wolfseye]

Mittlerweile hats geklappt. Danke für Eure Hilfe.

:) Gruss

Wolfseye