Forum: PC-Programmierung Local Key File vom Windows Rechner auf Ubuntu Server übertragen


von Bianca (Gast)


Lesenswert?

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?

von STK500-Besitzer (Gast)


Lesenswert?

"Sudo" ist das Zauberwort, wenn man nicht die notwendigen Rechte 
besitzt.

von Fred (Gast)


Lesenswert?

STK500-Besitzer schrieb:
> "Sudo" ist das Zauberwort, wenn man nicht die notwendigen Rechte
> besitzt.

Kannst du lesen? Probier das doch mal, bevor du antwortest.

von (nicht "Gast") (Gast)


Lesenswert?

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.

von Marek W. (ma_wa)


Lesenswert?

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.

: Bearbeitet durch User
von STK500-Besitzer (Gast)


Lesenswert?

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.

von Fred (Gast)


Lesenswert?

STK500-Besitzer schrieb:
> Übrigens hilft deine Aussage auch nicht bei der Problemlösung.

Sie hilft aber bei der Forumshygiene.

von Christopher B. (chrimbo) Benutzerseite


Lesenswert?

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

: Bearbeitet durch User
von Karl Käfer (Gast)


Lesenswert?

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

von Karl Käfer (Gast)


Lesenswert?

Hi,

Christopher B. schrieb:
> Wenn das Verzeichnis noch nicht angelegt ist dann so:
>
1
 mkdir ~/.ssh
2
>  nano ~/.ssh/authorized_keys

Wenn schon, dann
1
 mkdir ~/.ssh
2
chmod 0700 ~/.ssh
3
nano ~/.ssh/authorized_keys

/klugscheiß,
Karl

von Bianca (Gast)


Lesenswert?

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.

von Bianca (Gast)


Lesenswert?

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

von Simon S. (-schumi-)


Lesenswert?

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

von Bianca (Gast)


Lesenswert?

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?

von Marek W. (ma_wa)


Lesenswert?

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.

: Bearbeitet durch User
von Bianca (Gast)


Lesenswert?

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?

von Bianca (Gast)


Lesenswert?

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
RSAAuthentication yes

4.
Bis jetzt hat die Verbindung über das Keyfile funktioniert und das 
obwohl der Pfad #AutorizedKeysFiles auskommentiert ist. Sollte ich hier 
meinen eintragen?
1
PubkeyAuthentication yes
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
PasswordAuthentication no
automatisch deaktiviert.

6. Sehr ihr sonst noch an dem File einen Punkt, den ich zum Absichern 
verbessern kann?

Vielen Dank!


1
GNU nano 2.2.6          File: /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
Port 23142
7
# Use these options to restrict which interfaces/protocols sshd will bind to
8
#ListenAddress ::
9
#ListenAddress 0.0.0.0
10
Protocol 2
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
UsePrivilegeSeparation yes
17
18
# Lifetime and size of ephemeral version 1 server key
19
KeyRegenerationInterval 3600
20
ServerKeyBits 768
21
22
# Logging
23
SyslogFacility AUTH
24
LogLevel INFO
25
26
# Authentication:
27
LoginGraceTime 120
28
PermitRootLogin no
29
MaxAuthTries 3
30
AllowUsers testuser
31
StrictModes yes
32
33
RSAAuthentication yes
34
PubkeyAuthentication yes
35
#AuthorizedKeysFile     %h/.ssh/authorized_keys
36
37
# Don't read the user's ~/.rhosts and ~/.shosts files
38
IgnoreRhosts yes
39
# For this to work you will also need host keys in /etc/ssh_known_hosts
40
RhostsRSAAuthentication no
41
# similar for protocol version 2
42
HostbasedAuthentication no
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
PermitEmptyPasswords yes
48
49
# Change to yes to enable challenge-response passwords (beware issues with
50
# some PAM modules and threads)
51
ChallengeResponseAuthentication no
52
53
# Change to no to disable tunnelled clear text passwords
54
PasswordAuthentication no
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
X11Forwarding yes
67
X11DisplayOffset 10
68
PrintMotd no
69
PrintLastLog yes
70
TCPKeepAlive yes
71
#UseLogin no
72
73
#MaxStartups 10:30:60
74
#Banner /etc/issue.net
75
76
# Allow client to pass locale environment variables
77
AcceptEnv LANG LC_*
78
79
Subsystem sftp /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
89
# and ChallengeResponseAuthentication to 'no'.
90
UsePAM yes

von Karl Käfer (Gast)


Lesenswert?

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
> #ListenAddress 0.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
> RSAAuthentication yes
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
> PubkeyAuthentication yes
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
> PasswordAuthentication no
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

von Robert L. (lrlr)


Lesenswert?

>Aber trotz über 70 Aufrufen keine Antwort erhalten.

mich wundert eher dass sie die frage nicht gelöscht haben..

von Bianca (Gast)


Lesenswert?

@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?

von Bianca (Gast)


Lesenswert?

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 :-)

von Bianca (Gast)


Lesenswert?

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.

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.