Hi,
nicht wundern, ich habe folgenden Beitrag ins Ubuntu-Forum geschrieben
"Hi,
mein Clientrechner ist Windows und mein Server ist ein Ubuntu 12.04
Nun habe ich per Putty Keygenerator einen Keypair erstellt (wie hier
beschrieben http://wiki.ubuntuusers.de/PuTTY).
Jetzt möchte ich den Public Key auf dem Server einfügen, aber das mit
der Zwischenablage funktioniert nicht. Ich habe es mit dem nano und dem
vi Editor versucht, aber es funktioniert nicht.
Wie bekomme ich mein File auf den Server? Lokal ist es ja ein normales
txt File. Was muss es auf dem Server sein? Muss dieses File einen
besonderen Namen haben?"
Aber trotz über 70 Aufrufen keine Antwort erhalten. Ich weiß nicht, ob
ich mich so unklar ausgedrückt habe, oder ob "das Problem" so schwierig
ist??
Ach ja, ich habe mittlerweile zudem Versucht, dass File üer WinSCP auf
den Server zu schieben. Doch dort erhalte ich die Meldung, dass ich als
Benutzer keine Rechte habe in diesen Ordner .ssh ein File abzulegen :-(
Im Terminal würde ich mir ja über sudo die Rechte geben, aber wie kann
ich dass in der WinSCP-Software machen?
STK500-Besitzer schrieb:> "Sudo" ist das Zauberwort, wenn man nicht die notwendigen Rechte> besitzt.
Kannst du lesen? Probier das doch mal, bevor du antwortest.
Du musst Dich unter WinSCP als root auf dem server einloggen.
Dazu muss der Server aber ein root Passwort besitzen.
am Server: sudo passwd root
danach Passwort eingeben.
anschliessend vom client unter WinSCP als root@serverip anmelden.
http://www.linupedia.org/opensuse/Mit_putty_und_ssh_key_auf_einen_sicheren_Linux_Server_zugreifen#Kopieren_des_public_OpenSSH_Keys_auf_den_Server_und_Aufnahme_des_keys_in_der_authorized_keys_Datei
Punkt zwei dürfte das sein, was du suchst.
Dann prüfe, ob du als Benutzer das Verzeichnis .ssh im Heimatverzeichnis
hast und wie dort die Rechte dieses Verzeichnisses aussehen. Damit der
open-ssh Server die Dateien aus diesem Verzeichnis benutzt, muss
folgende Voraussetzung zutreffen:
-> Der Benutzer muss Eigentümer des Verzeichnis und seiner Dateien sein-
-> Nur der Eigentümer des Verzeichnis hat die Berechtigung die Dateien
zu lesen oder zu schreiben.
-> Other hat keine Zugriffsrechte auf die Dateien und das Verzeichnis
Zusätzlich solltest du prüfen, ob in der Konfigurationsdatei
/etc/ssh/sshd.conf die Authentifikation mit Zertifikaten aktiviert ist.
Wenn Du als Benutzer nicht auf das Verzeichnis zugreifen kannst, prüfe
den Eigentümer und die Berechtigungen. Wenn der Benutzer nicht der
Eigentümer ist, machst du leider schon etwas grundlegendes falsch.
Fred schrieb:> STK500-Besitzer schrieb:>> "Sudo" ist das Zauberwort, wenn man nicht die notwendigen Rechte>> besitzt.>> Kannst du lesen? Probier das doch mal, bevor du antwortest.
Ja, nur bei manchen Fragestellungen habe ich gewisse Probleme, und ich
bezog mich auf das hier:
Bianca schrieb:> Doch dort erhalte ich die Meldung, dass ich als> Benutzer keine Rechte habe in diesen Ordner .ssh ein File abzulegen :-(
Da würde Sudo schon gewisse Vorteile bringen...
Ich habe hier im Netzwerk ein paar Raspberry Pi laufen, die ich nur noch
per SSH-Tunnel anspreche...
Übrigens hilft deine Aussage auch nicht bei der Problemlösung.
Hi,
hab das erst letztens gemacht. Du bekommst doch in dem Putty
Keygenerator diese Textbox "Public keys for pasting ..." (wenn du das
schon weggeklickt hast kannst du mit dem Keygenerator einfach wieder
deinen key laden, den hast du ja wohl gespeichert). Den kopierst du dann
in die Zwischenablage.
Dann öffnest du mit putty eine Verbindung mit Benutzernamen und
Passwort.
Anschließend wechselst du in das Verzeichnis .ssh des Benutzers
1
cd ~/.ssh
und bearbeitest kauthorized_keys
1
nano authorized_keys
dann solltest du mit einem Klick auf die rechte Maustaste automatisch
den Key einfügen können
Wenn das Verzeichnis noch nicht angelegt ist dann so:
1
mkdir ~/.ssh
2
nano ~/.ssh/authorized_keys
die Rechte solltest du aber definitiv haben um im eigenen
Heimverzeichnis einen Ordner zu erstellen
Liebe Grüße
Christopher
Hallo Bianca,
Bianca schrieb:> Wie bekomme ich mein File auf den Server? Lokal ist es ja ein normales> txt File. Was muss es auf dem Server sein? Muss dieses File einen> besonderen Namen haben?"
Ja, die Datei muß den Namen "authorized_keys" haben und im
.ssh-Verzeichnis im Homedirectory des Benutzers liegen.
> Ach ja, ich habe mittlerweile zudem Versucht, dass File üer WinSCP auf> den Server zu schieben. Doch dort erhalte ich die Meldung, dass ich als> Benutzer keine Rechte habe in diesen Ordner .ssh ein File abzulegen :-(
Das ist mindestens merkwürdig, wenn nicht sogar kaputt. Üblicherweise
gehört das Verzeichnis $HOME/.ssh dem Benutzer, dessen Homedirectory
$HOME ist, und hat die Rechte 0700. Das heißt, der Benutzer darf dort
hinein schreiben.
> Im Terminal würde ich mir ja über sudo die Rechte geben, aber wie kann> ich dass in der WinSCP-Software machen?
Du kannst Dich entweder über das Terminal einloggen und dem .ssh-Ordner
die korrekten Rechte setzen, oder Du kannst die Datei auf den Server
übertragen, Dich über das Terminal einloggen und die Datei dann damit an
den richtigen Ort verschieben oder kopieren, nötigenfalls mit sudo(8).
HTH,
Karl
Wow, vielen Dank für die Antworten!
Es wäre so einfach gewesen...
Ich wußte nicht, dass man im Vi-Editor mit der rechten Maustaste den
Inhalt der Zwischenablage einfügen kann!
Nun habe ich so viele verschiedene Anleitungen gelesen.
Was mich wundert ist die Bezeichnung des Puplic Key-Files auf dem
Server. Hier hat das Keyfile oft unterschiedliche Namen und selbst
unterschiedliche Endungen. Ist das entscheidende hier, dass das Keyfile
mit .ssh Ordner ist oder woran erkennt der SSH-Server welches File er
als Key verwenden soll?
Wie kann ich mir im Terminal den Inhalt des versteckten Ordners anzeigen
lassen?
Mit ls wird er mir der Order nur von außen angezeigt und
mit cd /.ssh darf ich aber nicht in den Ordner wechseln.
Hier ein paar Beispiele der Bezeichnungen aus den verschiedenen
Anleitungen:
authorized_keys
authorized_keys2
id_rsa.pub
identity.pub
..sorry, konnte den Betrag nicht mehr editieren, da ich nicht eingeloggt
bin
Bianca schrieb:> Mit ls wird er mir der Order nur von außen angezeigt und> mit cd /.ssh darf ich aber nicht in den Ordner wechseln.
/.ssh ist nicht das selb wie ~/.ssh !
~ steht für /home/deinBenutzername
entsprechend: ls -a ~/.ssh
Und zu "darf nicht in den Ordner wechseln": Das steht da bestimmt nicht
als Fehlermeldung, sondern eher, dass es den Ordner garnicht gibt.. Also
immer genau lesen
Vielen Dank!
Dieser Hinweis war mir eine große Hilf!
Wenn ich nun zukünftig nur noch als User und nicht als Admin per SSH auf
meinen Server möchte, dann stecke ich das Keyfile doch in
~/.ssh
Doch was hat dieser "user-" .ssh Folder mit dem .ssh-Folder des roots zu
tun?
Soll ich den Key in beide Ordner kopieren?
Bianca schrieb:> Vielen Dank!> Dieser Hinweis war mir eine große Hilf!>> Wenn ich nun zukünftig nur noch als User und nicht als Admin per SSH auf> meinen Server möchte, dann stecke ich das Keyfile doch in> ~/.ssh>> Doch was hat dieser "user-" .ssh Folder mit dem .ssh-Folder des roots zu> tun?> Soll ich den Key in beide Ordner kopieren?
Die beiden Ordner haben nichts miteinander zu tun. Jeder Benutzer hat
seinen eigenen Ordner. Es mach nur Sinn die Datei auch nach "/root/.ssh"
zu kopieren, wenn du dich über SSH auch als Root anmelden möchtest. Ob
man das machen will, ist jetzt eine Glaubensfrage.
Hi,
mich wundert es nur, da in meinem .ssh Ordner im Root file bereits ein
Key-File existiert. Mir ist nicht bewusst, dass ich hier das Keyfile
reinkopiert habe.
Aber ssh wurde vom Provider bereits auf dem Server kopiert.
Sollte ich das Keyfile aus dem Root-ssh-Folder dann doch besser
entfernen?
Ich habe nachfolgend mal mein aktuelles sshd_config File angefügt.
Nachdem ich mir nun viele Tutorials etc. angesehen habe bleiben noch
offene Fragen.
1.
Ich habe keine feste IP auf meinem Windows 8 Client Rechner, dennoch
habe ich gelesen, dass es wichtig ist die ListenAdress einzuschränken.
Wie soll das gehen?
1
#ListenAddress ::
2
#ListenAddress 0.0.0.0
2.
Mein VPS Provider hat den Ubuntu Server 12.04 incl. SSH vorinstalliert.
Kann es sein, dass ich deshalb folgende Zeilen im config File stehen
habe?
Ich habe diese jedenfalls nicht dort eingetragen und sie entsprechen
auch nicht dem von mir erstellten public key-file.
1
HostKey/etc/ssh/ssh_host_rsa_key
2
HostKey/etc/ssh/ssh_host_dsa_key
3
HostKey/etc/ssh/ssh_host_ecdsa_key
3.
Ich habe gelesen, dass ich RSAAutentication auf "no" setzen soll, da es
bei Protokoll 2 nicht mehr benötigt wird. Stimmt das, nicht dass ich mit
aussperre.
1
RSAAuthenticationyes
4.
Bis jetzt hat die Verbindung über das Keyfile funktioniert und das
obwohl der Pfad #AutorizedKeysFiles auskommentiert ist. Sollte ich hier
meinen eintragen?
1
PubkeyAuthenticationyes
2
#AuthorizedKeysFile %h/.ssh/authorized_keys
5.
Hat es überhaupt eine Auswirkung, wenn ich "MaxStartups 10:30:60"
wieder einkommentiere. Das bedeutet ja, wieviele unautorisierte
Login-Verbindungen ich erlaube. Wenn ich nun aber auf das Login per
Keyfile mich festlege, sind dann die Loginverbindungen mit
Benutzername/Passwort nicht
durch
1
PasswordAuthenticationno
automatisch deaktiviert.
6. Sehr ihr sonst noch an dem File einen Punkt, den ich zum Absichern
verbessern kann?
Vielen Dank!
1
GNUnano2.2.6File:/etc/ssh/sshd_config
2
# Package generated configuration file
3
# See the sshd_config(5) manpage for details
4
5
# What ports, IPs and protocols we listen for
6
Port23142
7
# Use these options to restrict which interfaces/protocols sshd will bind to
8
#ListenAddress ::
9
#ListenAddress 0.0.0.0
10
Protocol2
11
# HostKeys for protocol version 2
12
HostKey/etc/ssh/ssh_host_rsa_key
13
HostKey/etc/ssh/ssh_host_dsa_key
14
HostKey/etc/ssh/ssh_host_ecdsa_key
15
#Privilege Separation is turned on for security
16
UsePrivilegeSeparationyes
17
18
# Lifetime and size of ephemeral version 1 server key
19
KeyRegenerationInterval3600
20
ServerKeyBits768
21
22
# Logging
23
SyslogFacilityAUTH
24
LogLevelINFO
25
26
# Authentication:
27
LoginGraceTime120
28
PermitRootLoginno
29
MaxAuthTries3
30
AllowUserstestuser
31
StrictModesyes
32
33
RSAAuthenticationyes
34
PubkeyAuthenticationyes
35
#AuthorizedKeysFile %h/.ssh/authorized_keys
36
37
# Don't read the user's ~/.rhosts and ~/.shosts files
38
IgnoreRhostsyes
39
# For this to work you will also need host keys in /etc/ssh_known_hosts
40
RhostsRSAAuthenticationno
41
# similar for protocol version 2
42
HostbasedAuthenticationno
43
# Uncomment if you don't trust ~/.ssh/known_hosts for RhostsRSAAuthentication
44
#IgnoreUserKnownHosts yes
45
46
# To enable empty passwords, change to yes (NOT RECOMMENDED)
47
PermitEmptyPasswordsyes
48
49
# Change to yes to enable challenge-response passwords (beware issues with
50
# some PAM modules and threads)
51
ChallengeResponseAuthenticationno
52
53
# Change to no to disable tunnelled clear text passwords
54
PasswordAuthenticationno
55
56
# Kerberos options
57
#KerberosAuthentication no
58
#KerberosGetAFSToken no
59
#KerberosOrLocalPasswd yes
60
#KerberosTicketCleanup yes
61
62
# GSSAPI options
63
#GSSAPIAuthentication no
64
#GSSAPICleanupCredentials yes
65
66
X11Forwardingyes
67
X11DisplayOffset10
68
PrintMotdno
69
PrintLastLogyes
70
TCPKeepAliveyes
71
#UseLogin no
72
73
#MaxStartups 10:30:60
74
#Banner /etc/issue.net
75
76
# Allow client to pass locale environment variables
77
AcceptEnvLANGLC_*
78
79
Subsystemsftp/usr/lib/openssh/sftp-server
80
81
# Set this to 'yes' to enable PAM authentication, account processing,
82
# and session processing. If this is enabled, PAM authentication will
83
# be allowed through the ChallengeResponseAuthentication and
84
# PasswordAuthentication. Depending on your PAM configuration,
85
# PAM authentication via ChallengeResponseAuthentication may bypass
86
# the setting of "PermitRootLogin without-password".
87
# If you just want the PAM account and session checks to run without
88
# PAM authentication, then enable this but set PasswordAuthentication
Hallo Bianca,
Bianca schrieb:> Ich habe nachfolgend mal mein aktuelles sshd_config File angefügt.> Nachdem ich mir nun viele Tutorials etc. angesehen habe bleiben noch> offene Fragen.
Wenn Du nicht verstehst, was Du tust, dann laß' die Konfiguration so,
wie sie ist.
> 1.> Ich habe keine feste IP auf meinem Windows 8 Client Rechner, dennoch> habe ich gelesen, dass es wichtig ist die ListenAdress einzuschränken.> Wie soll das gehen?>
1
>#ListenAddress::
2
>#ListenAddress0.0.0.0
3
>
Das hat nichts mit der Client-Adresse zu tun, sondern ist die Adresse,
auf welcher der OpenSSH-_Server_ auf Verbindungen lauscht. Das kann
manchmal ganz sinnvoll sein, wenn man den Server nur an das Interface
des internen Admin-Netzwerks binden will. In allen anderen Fällen ist
"0.0.0.0" -- also alle Interfaces -- die richtige Einstellung.
> 2.> Mein VPS Provider hat den Ubuntu Server 12.04 incl. SSH vorinstalliert.> Kann es sein, dass ich deshalb folgende Zeilen im config File stehen> habe?> Ich habe diese jedenfalls nicht dort eingetragen und sie entsprechen> auch nicht dem von mir erstellten public key-file.>
1
>HostKey/etc/ssh/ssh_host_rsa_key
2
>HostKey/etc/ssh/ssh_host_dsa_key
3
>HostKey/etc/ssh/ssh_host_ecdsa_key
4
>
Das konfiguriert, wo der OpenSSH-Server seine eignene Zertifikate
findet. Nichts zu ändern für Dich.
> 3.> Ich habe gelesen, dass ich RSAAutentication auf "no" setzen soll, da es> bei Protokoll 2 nicht mehr benötigt wird. Stimmt das, nicht dass ich mit> aussperre.>
1
>RSAAuthenticationyes
2
>
Finger weg, sonst sperrst Du Dich tatsächlich aus. Dein Problem scheint
zu sein, daß Du zu viele "Tutorials" aus dubiosen Quellen liest, die
sich auf verschiedene Versionen der Software beziehen. Tatsächlich gab
es mal eine Zeit, in der von der Authentifizierung über RSA-Zertifikate
abgeraten wurde, weil es dabei ein Sicherheitsproblem gab. Diese Zeit
ist aber schon lange vorbei und RSAAuthentication der bevorzugte und
sicherste Weg, sich an einem SSH-Server zu authentifizieren.
Wenn Du etwas lesen willst, dann vergiß' die blöden Tutorials und lies
die offizielle Dokumentation, die Du unter http://www.openssh.org/ (oder
mit "man ssh", "man sshd_config" etc.) auf Deinem System findest.
> 4.> Bis jetzt hat die Verbindung über das Keyfile funktioniert und das> obwohl der Pfad #AutorizedKeysFiles auskommentiert ist. Sollte ich hier> meinen eintragen?>
1
>PubkeyAuthenticationyes
2
>#AuthorizedKeysFile%h/.ssh/authorized_keys
3
>
Da "%h/.ssh/authorized_keys" der Default-Wert ist, muß er nicht mehr
extra eingetragen werden und steht dort zu Dokumentationszwecken
auskommentiert drin. Es gilt unter UNIX als guter Stil,
Standardeinstellungen auf diese Weise zu dokumentieren. Finger weg, auch
von "Pubkeyauthentication" -- das steuert nämlich, ob Du Dich mit Deinem
Zertifikat einloggen kannst.
> 5.> Hat es überhaupt eine Auswirkung, wenn ich "MaxStartups 10:30:60"> wieder einkommentiere. Das bedeutet ja, wieviele unautorisierte> Login-Verbindungen ich erlaube. Wenn ich nun aber auf das Login per> Keyfile mich festlege, sind dann die Loginverbindungen mit> Benutzername/Passwort nicht> durch>
1
>PasswordAuthenticationno
2
>
> automatisch deaktiviert.
Das ist der einzige Punkt, an dem sich eine Änderung positiv auf die
Systemsicherheit auswirkt. Wenn Du die "PasswordAuthentication"
deaktivierst und die "PubkeyAuthentication" aktiviert läßt, kommt
wirklich nur noch derjenige hinein, der a) den richtigen Benutzernamen
und b) den korrekten privaten Schlüssel hat. Die Sicherheit der
Veranstaltung steht und fällt dann nur noch mit dem privaten Schlüssel,
mithin: mit der Sicherheit des Windows-Systems, auf dem Du diesen
privaten Schlüssel gespeichert hast. Indem Du die
"PasswordAuthentication" deaktivierst, sicherst Du Dich gegen schwache
Passwörter und damit gegen Wörterbuch- und BruteForce-Angriffe ab. Kann
man machen -- muß man aber nicht, wenn man starke Passwörter benutzt.
> 6. Sehr ihr sonst noch an dem File einen Punkt, den ich zum Absichern> verbessern kann?
Nein. Die Standardeinstellungen von OpenSSH sind bereits ausreichend
sicher. Wenn Du Dich nicht aussperren willst, Finger weg.
HTH,
Karl
@Karl
Vielen herzlichen Dank für deine ausführliche und toll beschriebene
Antwort!!
Ich erhalte leider bei der Verbindung über das Keyfile immer die Meldung
"Server refused our key" :-(
Mir ist nicht klar, woran das liegen könnte. Habe darauf geachtet, dass
der KEY in einer Zeile steht (ohne Returns), ich habe auch auf die
Rechtevergabe des Ordners und des Files geachtet.
Fällt euch noch was ein?
Ich habe die Lösung!!
Ich hatte den Ordner mit dem Key mit sudo erstellt und somit gehörte er
nicht meinem user der sich einloggen wollte, sondern eben root.
Nun funktioniert es :-)
Hi,
ich muss dieses alte Thema nochmal aufwärmen. Ich habe noch folgende
Punkte gefunden, die man sicherheitshalber angeblich noch ändern sollte:
1)AllowGroups users
2)ClientAliveInterval 15
3)MaxStartups 1
4)PrintLastLog yes
5)KeepAlive no
6)UsePam no
Ist das richtig so? Oder was meint ihr dazu? Macht das meinen Server
sicherer?
7)
Gibt es ausserdem eigentlich eine Möglichkeit den Client Rechner von dem
aus man sich auf seinen Server Verbindet in die Konfiguration mit
reinzunehmen. Also z.B. wenn man eine feste IP am Client hätte, dem
Server diese mitzuteilen, damit dieser nur von meiner IP entsprechende
Anfragen annimmt??? Was, wenn man keine feste IP am Client hat? Könnte
man dies z.B. über DynDNS dennoch realisieren?
Ich würde mich sehr über eure Ideen und Hinweise freuen.