SSHD und PermitRootLogin

Shadow

Registered User
Hallo

Heute ist mein neuer Server gekommen. Als OS ist Debian sarge installiert. Wie von S4Y und Suse gewöhnt, wollte ich mich zuerst an SSh machen und das RootLogin verbieten und nur noch ein Login mit Schlüsseln zulassen.
Alles so eingestellt wie immer und SSHD mittels /etc/init.d/ssh restart neu gestartet. Doch nix hat sich geändert. RootLogin ist immer noch möglich. Genauso wie login mit Passwörtern.

Hier mal meine sshd_config:

Code:
Port 22
# Use these options to restrict which interfaces/protocols sshd will bind to
#ListenAddress ::
#ListenAddress 0.0.0.0
Protocol 2
# HostKeys for protocol version 2
#HostKey /etc/ssh/ssh_host_rsa_key
#HostKey /etc/ssh/ssh_host_dsa_key
#Privilege Separation is turned on for security
UsePrivilegeSeparation yes

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

# Logging
#SyslogFacility AUTH
#LogLevel INFO
# Authentication:
#LoginGraceTime 600
PermitRootLogin no
#StrictModes yes

RSAAuthentication yes
PubkeyAuthentication yes
AuthorizedKeysFile      %h/.ssh/authorized_keys

# Don't read the user's ~/.rhosts and ~/.shosts files
#IgnoreRhosts yes
# For this to work you will also need host keys in /etc/ssh_known_hosts
#RhostsRSAAuthentication no
# similar for protocol version 2
#HostbasedAuthentication no
# Uncomment if you don't trust ~/.ssh/known_hosts for RhostsRSAAuthentication
#IgnoreUserKnownHosts yes
# To enable empty passwords, change to yes (NOT RECOMMENDED)
#PermitEmptyPasswords no

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

# Change to yes to enable tunnelled clear text passwords
PasswordAuthentication no

Der Rest sollte ja nicht interessieren. Vieleicht hat einer von euch ne Idee, was ich falsch mache.
Danke schonmal.
 
Wie mache ich das denn das ich mich an meinem Server ohne Passwort anmelde sondern mit einem Zertifikat ( ist doch so, oder ?)

Gibts ein HowTo ?
 
DarkFighter81 said:
Wie mache ich das denn das ich mich an meinem Server ohne Passwort anmelde sondern mit einem Zertifikat ( ist doch so, oder ?)

Gibts ein HowTo ?

Forensuche! Guckst du da gibt es noch mehr dazu!
 
Habe hier mit Suse 9.3 (Strato) das selbe Problem. In der sshd_config auf "PermitRootLogin no" gesetzt und sshd neu gestartet.

Leider kann ich mich immer noch mit root einloggen. Auch "UsePAM no" brachte keine Änderung.

Auf meinem 1blu Server hatte das damals reibungslos geklappt :-D
 
bitteschön:

Code:
#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 yes
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
# session checks to run without PAM authentication, then enable this but set
# ChallengeResponseAuthentication=no
UsePAM yes

#AllowTcpForwarding yes
#GatewayPorts no
X11Forwarding no
#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

# This enables accepting locale enviroment variables LC_* LANG, see sshd_config(5).
AcceptEnv LANG LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE LC_MONETARY LC_MESSAGES
AcceptEnv LC_PAPER LC_NAME LC_ADDRESS LC_TELEPHONE LC_MEASUREMENT
AcceptEnv LC_IDENTIFICATION LC_ALL


Wie gesagt, UsePAM no bringt keine Besserung, deshalb hab ichs wieder auf yes gesetzt.
 
Hallo,

wenn ich mich recht entsinne (bin auch bei Strato, habe aber zur Zeit keinen Zugriff auf meinen Server), sollte folgende Änderung den gewünschten Effekt liefern.

Code:
# Change to no to disable s/key passwords
ChallengeResponseAuthentication no

Gruß flyingoffice
 
leider brachte auch diese Änderung nicht den gewünschten Erfolg :-/ was is da nur los... jop ist Strato...
 
Habe das Problem leider immer noch. Sollte ich den ganzen Server mal neu starten? Habe da allerdings etwas Skrupel vor.

Der Stratosupport weiß auch nicht weiter :-P

Den SSH Port zu verlegen hat ja auch wunderbar geklappt.... ?!
 
HornOx said:
Was sagt "ssh -vv localhost"?

Code:
 # ssh -vv localhost
OpenSSH_3.9p1, OpenSSL 0.9.7e 25 Oct 2004
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to localhost [127.0.0.1] port 22.
debug1: connect to address 127.0.0.1 port 22: Connection refused
debug1: Connecting to localhost [::1] port 22.
socket: Address family not supported by protocol
ssh: connect to host localhost port 22: Address family not supported by protocol

btw. habe den Std-Port ja verändert... insofern glar, dass bei Port22 sich nix tut.


Déjà vu?
Äh, ja ich habe den Thread in dem ich poste gelesen und die Tipps getestet :)
 
Code:
OpenSSH_3.9p1, OpenSSL 0.9.7e 25 Oct 2004
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to localhost [127.0.0.1] port xyz.
debug1: Connection established.
debug1: permanently_set_uid: 0/0
debug1: identity file /root/.ssh/identity type -1
debug1: identity file /root/.ssh/id_rsa type -1
debug1: identity file /root/.ssh/id_dsa type -1
debug1: Remote protocol version 1.99, remote software version OpenSSH_3.9p1
debug1: match: OpenSSH_3.9p1 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_3.9p1
debug2: fd 3 setting O_NONBLOCK
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-gro                                                              up14-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,                                                              aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-c                                                              tr
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,                                                              aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-c                                                              tr
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@open                                                              ssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@open                                                              ssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,zlib
debug2: kex_parse_kexinit: none,zlib
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit: first_kex_follows 0
debug2: kex_parse_kexinit: reserved 0
debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-gro                                                              up14-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,                                                              aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-c                                                              tr
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,                                                              aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-c                                                              tr
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@open                                                              ssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@open                                                              ssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,zlib
debug2: kex_parse_kexinit: none,zlib
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit: first_kex_follows 0
debug2: kex_parse_kexinit: reserved 0
debug2: mac_init: found hmac-md5
debug1: kex: server->client aes128-cbc hmac-md5 none
debug2: mac_init: found hmac-md5
debug1: kex: client->server aes128-cbc hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug2: dh_gen_key: priv key bits set: 135/256
debug2: bits set: 502/1024
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug2: no key of type 0 for host localhost
debug2: no key of type 2 for host localhost
The authenticity of host 'localhost (127.0.0.1)' can't be established.
RSA key fingerprint is [blablub...].
Are you sure you want to continue connecting (yes/no)?
 
Are you sure you want to continue connecting (yes/no)?
Es sollte offensichtlich sein was ssh da von dir will. Denke bitte in Zukunft etwas mit sonst artet das hier zu einem Chat aus.
 
ssh will den rsa key?!

allerdings gehts mir darum nicht wirklich, ich will lediglich den root-login deaktivieren.
 
ssh will den rsa key?!
Nein, ssh will das du "yes" eintippst und deine Eingabe mit Enter bestätigst weil es den hostkey von localhost noch nicht kennt.
allerdings gehts mir darum nicht wirklich, ich will lediglich den root-login deaktivieren.
Es wäre hilfreich zu erfahren mit welcher Authentifikationsmethode du dich noch anmelden kannst und genau das verrät dir "ssh -vv".
 
Back
Top