Thema: "lenny" auf Extensa 5220, Fernwartung

Hallo,

Zitat von Rain_Maker

Die üblichen Methoden wären ssh oder vnc,

ssh heißt das, nicht ssl! Sollte mir wirklich angewöhnen meine Brille auch zu benutzen. Oder wenigstens die Schrift im Browser zu vergrössern und genauer hinzuschaun.

Nach durchlesen was Wikipedia dazu sagt, installieren von opensshserver auf dem top, und verzweifeltem anstieren der manpages von ssh (821 Zeilen) und sshd (501 Zeilen) -alles natürlich auch noch in englisch- nach 'ner (deutschen) Anleitung für Doofe gesucht.
Folgendes gefunden: [OS X]SSH-Remote-Lösungen unter OSX (dazu VNC, KVM) - Apfeltalk
Erfüllt zwar meine Ansprüche (in bezug auf Doofe) nicht ganz, aber ich habs damit jetzt mal geschafft mich per ssh vom Desktop auf den Laptop einzuloggen.
Ausführliche Schritt für Schritt- Führung, super erklärt, prima!

Ich fass, was ich nach der Anleitung bis hierhin gemacht habe mal zusammen: (sshd läuft nach Installation auf dem Server)

Code:

client:~$ ssh username@serverip

Fingerprint mit "yes" bestätigen.

Code:

client:~$ ssh-keygen -b 2048 -t rsa

Code:

scp ~/.ssh/id_rsa.pub  username@serverip:~/.ssh/authorized_keys

Soweit hab ich halbwegs kapiert was ich da mache. Glaub ich wenigstens.

Gekürzt zitiert: (vollständiger Text in o.g. Anleitung)

Nun sind die Schlüssel verteilt und wir passen die Einstellungen von SSH unseren Bedürfnissen an. Dabei wollen wir die unsichere Passwort-Authentifikation deaktivieren sowie auch gleich ein paar mehr Dinge für die Sicherheit unseres Servers tun...

...Also:
cd /etc
Hier ist die Datei sshd_config abgelegt, welche die Einstellungen für unseren SSH-Dienst enthält...
... man kann nur mit root-Rechten die sshd_config verändern. Die /etc/services muss man zusätzlich ändern, wenn man den SSH-Port verändern will. Dazu muss sowohl die bei /etc/services als auch bei /etc/sshd_config der Eintrag für den SSH-Port geändert werden.
Jedoch gibt es dabei immer ein paar Probleme. Auch ich hab diese. Angeblich soll es ausreichen bei der /etc/services die Zeilen
Code:
ssh 22/udp # SSH Remote Login Protocol
ssh 22/tcp # SSH Remote Login Protocol
zu ändern. ...

...Somit nutzen wir den neuen SSH-Port, der dort nicht in der Liste steht. Aber wie gesagt... bei mir scheitert es aus unerfindlichen Gründen bei der Port-Änderungen.
Wie gesagt muss zusätzlich zur /etc/services die /etc/sshd_config für die Port-Änderungen abgeändert werden.
In der Zeile Code:
Port 22
ändern wir die 22 in unseren neuen Ziel-Port um, den wir auch in /etc/services angegeben haben....


Wenn es jemand hinbekommen haben sollte den SSH-Port manuell umstellen zu können, dann soll er es mir doch bitte verraten...

Falls ich alles richtig verstanden habe wartet sshd normalerweise ständig auf einen Kontaktversuch an Port 22, durch verlegen des Ports soll ein Angriff erschwert werden. Ich kenn mich damit nicht aus, aber kann der neue Port nicht einfach durch einen Portscan gefunden werden?

Ist es, für jemand der sowieso nur leise ahnt was er da macht, trotzdem empfehlenswert die anscheinend nicht ganz so einfache Änderung der Ports vorzunehmen?

Mir ist schon klar, so sicher wie nur möglich- allerdings nützt es mir auch nix wenn ich das Teil dann so "sicher" hab daß ich selbst keine Verbindung mehr zustande kriege.
Was ich bräuchte wäre eine Einschätzung von jemand der was davon versteht nach dem Motto: "Würde ich unbedingt machen, bringt wirklich einen anständigen Gewinn an Sicherheit" oder "Bringt zwar was wenns klappt, aber relativ wenig und wenns nicht klappt...".
Und müßte ich, im Falle ich probiers, nicht auch am client die ports entsprechend verstellen, sind das dann die gleichen Konfigurationsfiles?

1. Das "Umlegen" von ssh auf einen anderen Port als 22 ist kein zusätzlicher Sicherheitsgewinn im klassischen Sinne, denn ein Portscan wird diesen Dienst trotzdem finden und ein schlecht konfigurierter ssh auf Port 12345 ist genauso angreifbar wie auf Port 22.

Der Vorteil eines non-Standard Ports für ssh liegt darin, daß die Logfiles nicht mit dem üblichen scriptgestützten "Hintergrundrauschen" standardisierter Loginversuche überquellen.

2. Wirklicher Sicherheitsgewinn entsteht durch Pubkey-Authentifizierung (das wurde ja schon erledigt).

3. Es muß auch nicht immer VNC sein, für Updates via apt-get reicht eine "einfache" ssh-Sitzung und die Kommandozeile aus, wenn man noch zusätzlich VNC (natürlich über eine verschlüsselte Verbindung getunnelt, das ist so oder so sinnvoll, dann kann niemand mithören) laufen lässt, dann wird das auch bei einer normalen DSL-Verbindung nicht gerade ein Geschwindigkeitswunder sein.

Die zusätzliche Bandbreite, die eine X-Sitzung benötigt, würde ich also so oft wie irgend möglich vermeiden.

Greetz,

RM

Hallo,
denke ich hab's jetzt mit der ssh-Verbindung.

Aber erst mal:

3. Es muß auch nicht immer VNC sein, für Updates via apt-get reicht eine "einfache" ssh-Sitzung und die Kommandozeile aus, wenn man noch zusätzlich VNC (natürlich über eine verschlüsselte Verbindung getunnelt, das ist so oder so sinnvoll, dann kann niemand mithören) laufen lässt, dann wird das auch bei einer normalen DSL-Verbindung nicht gerade ein Geschwindigkeitswunder sein.

Die zusätzliche Bandbreite, die eine X-Sitzung benötigt, würde ich also so oft wie irgend möglich vermeiden.

Ja, so ähnlich hab ich mir das inzwischen auch gedacht: Möchte die (getunnelte) VNC-Verbindung nur dann benutzen wenn Mama mir auf ihrem Schirm zeigen muß was sie meint oder umgekehrt.
Dazu möchte ich VNC dann auch noch so einrichten, daß ich bei mir gerade noch so das Notwendigste erkennen kann, um die Bandbreite soweit möglich zu verringern. Mama kriegt zwar DSL 2000 aber ich muß immer noch mit der Light-version rumkrebsen.

Aber das habe ich noch nach dem Tunneln an den Schluß gestellt.

Mein momentanes Problem ist, daß ich zwar glaube daß ich es bis jetzt sicher hingekriegt habe, es aber nicht wirklich weiß.
Darum:
Könntet Ihr Euch bitte mal meine sshd_config ansehen und mir sagen ob die so ok ist?

Code:

 #Package generated configuration file
# See the sshd(8) manpage for details

# What ports, IPs and protocols we listen for
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 1800 
ServerKeyBits 4096

# Logging
SyslogFacility AUTH
LogLevel ERROR

# Authentication:
LoginGraceTime 60
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 yes to enable challenge-response passwords (beware issues with
# some PAM modules and threads)
ChallengeResponseAuthentication no

# Change to no to disable tunnelled clear text passwords
PasswordAuthentication no

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

# GSSAPI options
#GSSAPIAuthentication no
#GSSAPICleanupCredentials yes

X11Forwarding yes
X11DisplayOffset 10
PrintMotd no
PrintLastLog yes
TCPKeepAlive yes
#UseLogin no

#MaxStartups 10:30:60
#Banner /etc/issue.net

# Allow client to pass locale environment variables
AcceptEnv LANG LC_*

Subsystem sftp /usr/lib/openssh/sftp-server

UsePAM yes

in blau: Unsicher ob ich das brauche

Der Vorteil eines non-Standard Ports für ssh liegt darin, daß die Logfiles nicht mit dem üblichen scriptgestützten "Hintergrundrauschen" standardisierter Loginversuche überquellen.

Kann ich das damit umgehen daß ich den LogLevel auf Error statt auf Info gesetzt habe?

Bringt mir eine große Schlüsselänge, außer dem Sicherheitsgewinn, eventuell zuviel Datenoverhead?

Hier auch noch die Ausgabe eines Portscans an dem top:

Code:

port    22    open    ssh  ok 
port   111   open  sunrpc  ? 
port   113   open  auth      ?  
port  5900  open  unbekannt  VNC; ok

113 wird wohl gebraucht, aber sollte der nicht geschlossen sein?
111 Text bei Internet Security Systems ...should never be exposed to the Internet... Brauch ich den?
VNC starte ich bei Bedarf per ssh.

So, einige Stunden später:
vnc läuft über ssh.

neskaya:/home/cal# ssh -L 5902:localhost:5900 renate@192.168.1.4

anderes Terminal:

neskaya:/home/cal# xvnc4viewer Autoselect=0 LowColourLevel=1 PreferredEncoding=ZRLE localhost:2

lap meldet:

lsof -P -n -i
sshd 7723 root 3r IPv6 29792 TCP 192.168.1.4:22->192.168.1.3:33348 (ESTABLISHED)
sshd 7728 renate 3u IPv6 29792 TCP 192.168.1.4:22->192.168.1.3:33348 (ESTABLISHED)
sshd 7728 renate 11u IPv4 30136 TCP 127.0.0.1:35176->127.0.0.1:5900 (ESTABLISHED)
renatemobil:/home/renate#

Traffic liegt bei ca 150kB/s, müsste ja für Mamas upload reichen.*
Natürlich ändere ich den ssh und vnc login per root noch in einen normalen User, wollte vermeiden daß ich irgendwelche Benutzerrechte-Probleme kriege solange ich am ausprobieren bin.

Jetzt muß ich das ja "nur" noch durch 2 Wlan-Router und eine DSL-Leitung bekommen.

Falls jemand noch einen Fehler entdecken sollte, bitte sagen.

Herzlichen Dank an alle die mir bisher weitergeholfen haben.

*Das reicht natürlich noch lange nicht, sind ja kByte, keine kbit.
Da muß ich wohl noch mal schau'n was ich da noch machen kann. Hab gerade mal nachgeschaut, Mamas Upstream kann ich auf 384kbit/s erhöhen lassen, was meinem Downstream entsprechen würde. Dann müßte ich noch auf etwa ein Viertel der jetzigen Datenrate kommen damits klappt..... Mit meinem Upstream dürfte es wohl keine Probleme geben, ich schicke ja kein Bild mit. Testen....

Hallo,

nach einigem rumpfriemeln ist die geplante VNC-Verbindung wohl gestorben.

Mit meinem Upstream dürfte es wohl keine Probleme geben, ich schicke ja kein Bild mit. Testen....

hat sich als Irrtum herausgestellt.
Mein Upstream würde sich, bei niedrigster Auflösung und ohne ssh-Tunnel auf etwas über 30kByte/s belaufen, das ist das doppelte des möglichen.
Der Upstream des Servers läge bei 45-50kB/s, mit noch ein wenig schrauben..
Mit ssh-tunnel kämen dann nochmal ca 50% dazu.
Dieses besch... DSL-light!
Mit 2 (aufgerüsteten) DSL2000 upstreams könnte es -unverschlüsselt- gerade mal so klappen. Zumindest könnte mans mal probieren.
Es bleibt aber immerhin die sichere ssh-Verbindung, dann muß ich mir mal überlegen wie ich über die logs möglicherweise nachvollziehen kann welche Probleme im Eventualfall Mama haben könnte.
Und wieder ein bissel was gelernt hab ich bei der Geschichte ja auch noch.