[gelöst] SSH zugang mittels Key absichern

[Becksta]

Servus,

ich noch mal....

Habe jetzt versucht, die Key Geschichte wieder einzubauen.
Habe für die beiden User auf dem Server, den Key erstellt und das halt anhand des obigen Links eingerichtet.
Wenn ich mich jetzt von dem Notebook aus, auf dem die Key drauf sind, anmelde, kommt auch keine Passwortabfrage mehr. Das interpretiere ich als Erfolg. Allerdings kann ich mich von den anderen Rechner aus immer noch mit Kennwort anmelden.

Hier mal meine sshd_conf:

#	$OpenBSD: sshd_config,v 1.74 2006/07/19 13:07:10 dtucker 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 change a
# default value.

#Port 22
#Protocol 2,1
#AddressFamily any
#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 yes
#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 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

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

# 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

# Example of overriding settings on a per-user basis
#Match User anoncvs
#	X11Forwarding no
#	AllowTcpForwarding no
#	ForceCommand cvs server

Ist nicht der Parameter: "PasswordAuthentication = no" dafür verantwortlich, das sich nur noch Key Inhaber anmelden dürfen???

Wie unterbinde ich nochmal, das man sich am dem Server direkt als "root" anmelden kann???

Greetz
Becksta

 

[Anonymous]

Das geht dann wohl hier:

# Authentication: 
 
 #LoginGraceTime 2m 
 #PermitRootLogin yes 
 #StrictModes yes 
 #MaxAuthTries 6

Greetz,

RM

 

[Becksta]

Hm,

# Authentication:

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

/etc/init.d/sshd restart

Und trotzdem kann ich mich unter Putty und Winscp nach wie vor als root am System anmelden....
Wie gesagt: Auf dem Rechner, an dem ich im Moment sitze, sind noch nicht mal die Pub Keys hinterlegt... Was könnte ich denn da noch falsch haben...
Irgendeine Einstellung in der Datei???

Greetz
Becksta

 

[framp]

Vor langer Zeit hatte ich mal hier beschrieben wie man einen ssh Server sicher aufsetzt, d.h. nur Zugriff mit keys und kein root Zugriff. Da kommt zwar noch putty vor - aber in Deinem Fall geht es ja nur im die sshd.conf.

 

[framp]

... des Effekt hatte ich auch. Ich glaube es war usepam no. Aber vergleiche einfach mal Deine Config und die im Wiki. Die funktioniert ! 8)

 

[Anonymous]

Hm,

# Authentication:

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

/etc/init.d/sshd restart

Also mal ganz auf der "sprachlichen" Ebene argumentiert.

"Permit " = "Erlauben".


Ansonsten ist ja framps Tipp genau der richtige.

Greetz,

RM

 

[Becksta]

oh shit....

Da hat mich mein Schulenglisch wohl gerade mal verlassen...
Hab die beiden Optionen verändert, und im Moment kann ich mich nicht mehr von dieser Maschine hier einloggen.... es scheint also zu laufen....

Hoffen wir mal, das ich vom Notebook aus noch dran komme... hehe

Greetz und danke....

Becksta

 

[Becksta]

Sieht ziemlich gut aus... vom Notebook komme ich nach wie vor auf den Server...

Jetzt stellt sich mir allerdings noch die Frage, wie ich in der Windows Welt vorgehe...

Im vorherigen Link geht es ja darum, einen von Putty erzeugten Key zu verwenden.... Dabei fällt mir sofort auf, das Putty einen .ppk, also einen private Key erzeugt, ich aber eine id_rsa.pub habe.

Kann mir jemand dabei noch ne Hilfestellung geben.... Dann bin ich auch wirklich glücklich und zufrieden... versprochen....

Greetz
becksta

 

[Leviathan]

Versteh die Aussage nicht ganz.

Du musst den Openssh id_rsa Key in ein id_rsa.ppk file konvertieren.

Schnapp dir das File id_rsa, das ist dein Private Key File (mit ssh-keygen generiert) und lade das in den Puttygen, der erzaehlt dir dann was von Format und Import etc, durchklicken, passwort vergeben etc, dann hast du einen Private Key in einem putty (ppk ) Format und in einem Opensshformat.

Gruß Dominik

 

[Becksta]

genau daran hapert es ja.....
Puttygen sagt mir halt leider nicht, "klick mich durch, dann wird aus dem .pub ein .ppk".
Es sagt einfach:"es handelt sich um keinen .ppk" und steigt aus....

Greetz
Becksta

EDIT:
Ich habe in "puttygen" versucht den key einfach zu öffnen, habe aber auch über den Punkt "Conversion" versucht den Key zu importieren.... beide schlägt fehl... ;o(

GELÖST:
Ich hatte mit der falschen Datei probiert... nämlich mit der id_rsa.pub, statt der id_rsa... Damit konnte ich dann auch den .ppk erstellen....