49372
Goto Top

ssh für externe zugriffe konfigurieren

kann mir jemand helfen wie ich ssh konfiguriere auf linux damit externe linux maschinen über ssh und scp sich verbinden bzw. remote kopieren kann?

wenn ich mittels scp Befehl local was kopieren möchte fragt es mich schön nach einem Passwort ab, jedoch versuch ich auf eine andere Linux Maschine auf dem auch SSH Dienst läuft Dateien zu kopieren und dann kommt lediglich follgende Meldung:

ssh: connect to host 192.168.1.91 port 22: Connection refused
lost connection

/etc/ssh/sshd_config:
#       $OpenBSD: sshd_config,v 1.59 2002/09/25 11:17:16 markus Exp $

# This is the sshd server system-wide configuration file.  See
# sshd_config(5) for more information.

# This sshd was compiled with PATH=/usr/local/bin:/bin:/usr/bin

# 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
#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 3600
#ServerKeyBits 768

# Logging
#obsoletes QuietMode and FascistLogging
#SyslogFacility AUTH
#LogLevel VERBOSE

# Authentication:

#LoginGraceTime 700
#PermitRootLogin no
#StrictModes no

#RSAAuthentication no
#PubkeyAuthentication no
#AuthorizedKeysFile     .ssh/authorized_keys

# rhosts authentication should not be used
#RhostsAuthentication no
# 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/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 yes

# To disable tunneled clear text passwords, change to no here!
# PasswordAuthentication yes
# PermitEmptyPasswords yes

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

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

#AFSTokenPassing no

# Kerberos TGT Passing only works with the AFS kaserver
#KerberosTgtPassing no

# Set this to 'yes' to enable PAM keyboard-interactive authentication 
# Warning: enabling this may bypass the setting of 'PasswordAuthentication' 
#PAMAuthenticationViaKbdInt no

#X11Forwarding no
#X11DisplayOffset 10
#X11UseLocalhost yes
#PrintMotd yes
#PrintLastLog yes
#KeepAlive yes
#UseLogin yes
#UsePrivilegeSeparation yes
#PermitUserEnvironment no
#Compression yes

#MaxStartups 10
# no default banner path
#Banner /some/path
#VerifyReverseMapping no
#ShowPatchLevel no

# override default of no subsystems
#Subsystem      sftp    /usr/libexec/openssh/sftp-server
#Ciphers aes256-cbc,aes128-cbc


/etc/ssh/ssh_config file:

#       $OpenBSD: ssh_config,v 1.16 2002/07/03 14:21:05 markus Exp $

# This is the ssh client system-wide configuration file.  See
# ssh_config(5) for more information.  This file provides defaults for
# users, and the values can be changed in per-user configuration files
# or on the command line.

# Configuration data is parsed as follows:
#  1. command line options
#  2. user-specific file
#  3. system-wide file
# Any configuration value is only changed the first time it is set.
# Thus, host-specific definitions should be at the beginning of the
# configuration file, and defaults at the end.

# Site-wide defaults for various options

#   Host *
#   ForwardAgent no
#   ForwardX11 no
#   RhostsAuthentication no
#   RhostsRSAAuthentication no
#   RSAAuthentication no
#   PasswordAuthentication no
#   HostbasedAuthentication no
#   BatchMode yes
#   CheckHostIP no
#   StrictHostKeyChecking ask
#   IdentityFile ~/.ssh/identity
#   IdentityFile ~/.ssh/id_rsa
#   IdentityFile ~/.ssh/id_dsa
#   Port 22
#Protocol 2
#   Cipher 3des
#Ciphers aes256-cbc,aes128-cbc
#   EscapeChar ~
Bin auf Linux ein Anfänger, kann mir jemand dabei helfen bin ratlos habe auch schon einige EInstellungen auskommentiert, brachte auch nichts

Content-ID: 109870

Url: https://administrator.de/contentid/109870

Ausgedruckt am: 22.11.2024 um 12:11 Uhr

theton
theton 24.02.2009 um 15:04:53 Uhr
Goto Top
Nimm mal die 'ListenAddress 0.0.0.0' und 'Port 22' wieder in die Konfiguration des sshd rein. Damit lauscht er dann an allen Netzwerkinterfaces und nicht nur am Loopback.

Im übrigen ist OpenBSD kein Linux, sondern ein BSD, wie der Name schon sagt und die Konfigurationsheader sehen sehr nach OpenBSD aus. Und benutze bitte in Zukunft Code-Tags, damit der Kram wenigstens einigermaßen lesbar bleibt.
49372
49372 24.02.2009 um 15:16:14 Uhr
Goto Top
das hab ich versucht funktioniert immer noch nicht face-sad
jhinrichs
jhinrichs 24.02.2009 um 15:19:46 Uhr
Goto Top
Was heißt "externer Zugriff"? Andere Maschine im gleichen Subnetz (192.168.1.x) oder aus dem Internet über Router?
Was ergibt die Eingabe von

iptables -L

auf der Kommandozeile?

Defaultverhalten bei sshd ist eigentlich, dass er an allen Interfaces lauscht.
49372
49372 24.02.2009 um 15:22:51 Uhr
Goto Top
mit extern mein ich im selben Netzwerk einfach von einem anderem Linux Computer aus

iptables -L kennt Vmware als Befehl leider nicht

Der andere Computer sitzt im selben Subnetz
jhinrichs
jhinrichs 24.02.2009 um 15:31:11 Uhr
Goto Top
Ooops, sorry
Jetzt war ich auch bei Linux...
Netzwerk läuft, denke ich, sonst käme wohl auch ein "No route to host" statt "Connection refused", trotzdem: ping 192.168.1.91 geht?

Ist ein Paketfilter installiert (unter Linux eben "iptables"), unter OpenBSD "pf". Damit kenne ich mich aber nicht aus, siehe ggf. man-pages. Vielleicht blockiert ein Paketfilter den Zugriff.

sshd läuft? Unter Linux
ps ax | grep sshd

Und lauscht auf Port 22? Unter Linux

lsof -i :22

Ich hoffe, diese Befehle gibt es auch bei openBSD (wieso eigentlich VMWare?)
49372
49372 24.02.2009 um 15:39:39 Uhr
Goto Top
also Pingen läuft einwandfrei in beide richtungen

es ist dazwischen auch keine firewall oder Router

Ergebniss nach ps ax | grep sshd:

1470 ? S 0:00 sshd: vmware [priv]
1484 ? R 0:00 sshd: vmware@pts/0
1775 ? S 0:00 sshd: vmware [priv]
1777 ? S 0:00 sshd: vmware@pts/1
2161 ? S 0:00 /usr/sbin/sshd
2166 pts/1 S 0:00 grep sshd


Den Befehl lsof -i :22 kennt vmware irgendwie nicht

Mit dem Befehl: netstat -nlvp | grep :22
wird folgendes angezeigt, das sollte den anderen Befehl ersetzen den du gegeben hast.

Ergebnis:
netstat: no support for `AF IPX' on this system.
netstat: no support for `AF AX25' on this system.
netstat: no support for `AF X25' on this system.
netstat: no support for `AF NETROM' on this system.
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 1042/sshd

VMware weil darauf Virtualisierungen läuft und ich über die komando Zeile planmässige Backups machen möchte, da ich kein andere Script ausser vmbk script welch ich nicht zum laufen brachte
theton
theton 24.02.2009 um 16:01:27 Uhr
Goto Top
Also moment... du hast den SSH-Server in einer VMWare laufen? Hast du im Host-System die Netzwerk-Einstellungen entsprechend angepasst, dass Verbindungen an die VMWare weitergereicht werden?
jhinrichs
jhinrichs 24.02.2009 um 16:02:25 Uhr
Goto Top
Um ein Missverständnis zu vermeiden: die Kommandozeile ist die BSD-Shell? Die Ausgabe von ps spricht dafür.

Habe geforscht, was ergibt der Befehl:

pfctl -sn

und

pfctl -sa

?
49372
49372 24.02.2009 um 16:09:25 Uhr
Goto Top
Ich habe SSH auf dem VMware Kernel am laufen

wie meinst du das?

ich habe

IP Adresse
Subnetz
Gateway
DNS

Manuell eingegeben

pfctl Befehl funktioniert nicht auf vmware
jhinrichs
jhinrichs 24.02.2009 um 16:15:02 Uhr
Goto Top
So, um jetzt die Konfiguration zu verstehen, bitte noch einmal folgende Angaben:
Welches Hostsystem?
Welches Gastsystem (VMWare ist ja kein Betriebssystem, sondern eine Virtualisierungsschicht, auf der ein Gastsystem installiert wird.)?
49372
49372 24.02.2009 um 16:20:56 Uhr
Goto Top
Ich verwende VMware ESX 3.5 auf der ich am Basteln bin mit der ssh
jhinrichs
jhinrichs 24.02.2009 um 18:13:38 Uhr
Goto Top
Was mir gerade einfällt: die sshd_config ist auf dem VMWare oder BSD/Linux-System?
sshd_config konfiguriert den ssh-Server, sollte auf dem Client also irrelevant sein.
49372
49372 25.02.2009 um 07:40:59 Uhr
Goto Top
ja die sshd_config ist auf dem WMware System
jhinrichs
jhinrichs 25.02.2009 um 10:02:33 Uhr
Goto Top
Noch weiter zum Verständnis:
Wir sprechen von der sshd_config auf einer virtuellen Maschine unter VMWare ESX. Dazu die Frage: welches Gastsystem ist installiert? Das wäre wichtig zu wissen, um konkrete Tips geben zu können. VMWare ESX selber bietet meines Wissens keinen ssh-Zugang auf Hypervisor-Ebene, sondern nur das Remote Command Line Interface, da gibt es aber keine Datei sshd_config, kein Verzeichnis /etc, kein ps etc.

Zwischenschritt: Was passiert, wenn Du in der sshd_config die Zeile 74 änderst:


#PAMAuthenticationViaKbdInt yes

und dann sshd neu startest (mit /etc/init.d/sshd restart)?
49372
49372 25.02.2009 um 10:30:20 Uhr
Goto Top
wie kann ich rausfinden welche version von linux auf der vmware mühle läuft?

Als Gastsystem versteh ich die angelegten Virtuellen Computern die unter ESX angelegt werden können. Lediglich ein Win Server 2003

Hat nichts gebracht
jhinrichs
jhinrichs 25.02.2009 um 12:28:14 Uhr
Goto Top
Ah - wir kommen der Sache näher:

Genau, Gastsystem ist/sind der/die virtuelle/n Computer. Möchtest Du den Win Server (Gastsystem) per ssh erreichen?
Welche IP-Adresse hat der VMWare-Host und welche der virtuelle PC?

Wenn ich Dich richtig verstanden habe, läuft das Wirtssystem (Hostsystem) unter Linux.

Was ergibt die Ausgabe von

uname -r

oder ein

ls -al /boot

und der Vollständigkeit halber, was ergibt:

ls -al /etc/ssh auf dem VMWare-System

und

ls -al ~/.ssh auf dem Linux-Client?
49372
49372 25.02.2009 um 13:32:52 Uhr
Goto Top
ich möchte von einem wirtsystem zu einem anderem Wirtsystem kopieren

ausgabe von uname -r:

2.4.21-57.ELvmnix

Ausgabe von ls -al /etc/ssh:

total 136
drwxr-xr-x 3 root root 4096 Feb 25 13:30 .
drwxr-xr-x 32 root root 4096 Feb 25 13:23 ..
-rw------- 1 root root 88039 Jul 24 2007 moduli
drwxr-xr-x 3 root root 4096 Feb 25 13:27 original
-rw-r--r-- 1 root root 1081 Jul 24 2007 ssh_config
-rw------- 1 root root 2480 Jul 24 2007 sshd_config
-rw------- 1 root root 668 Feb 25 13:19 ssh_host_dsa_key
-rw-r--r-- 1 root root 590 Feb 25 13:19 ssh_host_dsa_key.pub
-rw------- 1 root root 515 Feb 25 13:19 ssh_host_key
-rw-r--r-- 1 root root 319 Feb 25 13:19 ssh_host_key.pub
-rw------- 1 root root 887 Feb 25 13:19 ssh_host_rsa_key
-rw-r--r-- 1 root root 210 Feb 25 13:19 ssh_host_rsa_key.pub

Ausgabe von ls -al ~/.ssh:

total 12
drwx------ 2 root root 4096 Feb 25 13:28 .
drwxr-x--- 3 root root 4096 Feb 25 13:28 ..
-rw-r--r-- 1 root root 222 Feb 25 13:28 known_hosts
jhinrichs
jhinrichs 25.02.2009 um 13:45:26 Uhr
Goto Top
Es handelt sich also offenbar um einen 2.4er Kernel, das spricht auch für Linux als Basis. Die file permissions sehen auch ok aus. Im 2.4er Kernel sollte eigentlich als Paketfilter netfilter, zu administrtieren über iptables, enthalten sein, aber bei vmware...
Mit welchem Benutzeraccount bist Du auf der VMWare-Maschine angemeldet?
ggf. mit

whoami

herausfinden.
Wir machen weiter mit Listings:

was ergibt:

ls -al /sbin/ip*

oder (jetzt kommt wahrscheinlich eine längere Liste)

find / -name ip*
49372
49372 25.02.2009 um 13:53:56 Uhr
Goto Top
Ausgabe von ls -al /sbin/ip*:

-rwxr-xr-x 1 root root 97948 Mar 23 2007 /sbin/ip
-rwxr-xr-x 1 root root 9792 Mar 19 2007 /sbin/ipmaddr
-rwxr-xr-x 1 root root 47568 Dec 17 2003 /sbin/iptables
-rwxr-xr-x 1 root root 51872 Dec 17 2003 /sbin/iptables-restore
-rwxr-xr-x 1 root root 50276 Dec 17 2003 /sbin/iptables-save
-rwxr-xr-x 1 root root 13888 Mar 19 2007 /sbin/iptunnel

Mit dem Befehl find / -name ip* erhalte ich extrem viel Ausgabe welch ich hier mal nicht posten werde, es zeigt lediglich verzeichnisse an wie z.B:
/usr/src/linux-2.4.21-57.EL/net/ipv4/netfilter/ip_nat_proto_tcp.c

Zudem bin ich mit dem Benutzer root eingelogt
jhinrichs
jhinrichs 25.02.2009 um 13:58:08 Uhr
Goto Top
Aber dann ist ja iptables da!

Was ergibt

/sbin/iptables -L
49372
49372 25.02.2009 um 14:08:37 Uhr
Goto Top
stimm hast recht

Ausgabe:

Chain INPUT (policy DROP)
target prot opt source destination
ACCEPT all -- anywhere anywhere
valid-tcp-flags tcp -- anywhere anywhere
valid-source-address !udp -- anywhere anywhere
valid-source-address-udp udp -- anywhere anywhere
valid-source-address tcp -- anywhere anywhere tcp flags :SYN,RST,ACK/SYN
icmp-in icmp -- anywhere anywhere
ACCEPT all -- anywhere anywhere state RELATED,ESTABL ISHED
ACCEPT tcp -- anywhere anywhere tcp dpt:vmware-authd state NEW
ACCEPT tcp -- anywhere anywhere tcp dpt:http state N EW
ACCEPT tcp -- anywhere anywhere tcp dpt:https state NEW
ACCEPT udp -- anywhere anywhere udp spts:bootps:boot pc dpts:bootps:bootpc
ACCEPT udp -- anywhere anywhere udp dpt:svrloc
ACCEPT tcp -- anywhere anywhere tcp dpt:svrloc state NEW
ACCEPT tcp -- anywhere anywhere tcp dpt:5989 state N EW
ACCEPT tcp -- anywhere anywhere tcp dpt:ssh state NE W

Chain FORWARD (policy DROP)
target prot opt source destination

Chain OUTPUT (policy DROP)
target prot opt source destination
ACCEPT all -- anywhere anywhere
valid-tcp-flags tcp -- anywhere anywhere
icmp-out icmp -- anywhere anywhere
ACCEPT udp -- anywhere anywhere udp spts:1024:65535 dpt:domain
ACCEPT tcp -- anywhere anywhere tcp spts:1024:65535 dpt:domain
ACCEPT all -- anywhere anywhere state RELATED,ESTABL ISHED
ACCEPT tcp -- anywhere anywhere tcp dpt:vmware-authd state NEW
ACCEPT udp -- anywhere anywhere udp spts:bootps:boot pc dpts:bootps:bootpc
ACCEPT udp -- anywhere anywhere udp spt:svrloc
ACCEPT tcp -- anywhere anywhere tcp spt:svrloc state NEW
ACCEPT tcp -- anywhere anywhere tcp dpt:https state NEW
ACCEPT tcp -- anywhere anywhere tcp dpt:vmware-authd state NEW
ACCEPT udp -- anywhere anywhere udp dpt:902 state NE W
ACCEPT tcp -- anywhere anywhere tcp dpt:27000 state NEW
ACCEPT tcp -- anywhere anywhere tcp dpt:27010 state NEW
REJECT all -- anywhere anywhere reject-with icmp-por t-unreachable

Chain icmp-in (1 references)
target prot opt source destination
ACCEPT icmp -- anywhere anywhere icmp echo-reply
ACCEPT icmp -- anywhere anywhere icmp echo-request
ACCEPT icmp -- anywhere anywhere icmp fragmentation-n eeded
DROP all -- anywhere anywhere

Chain icmp-out (1 references)
target prot opt source destination
ACCEPT icmp -- anywhere anywhere icmp echo-request
ACCEPT icmp -- anywhere anywhere icmp echo-reply
DROP all -- anywhere anywhere

Chain log-and-drop (7 references)
target prot opt source destination
LOG all -- anywhere anywhere LOG level debug tcp- options ip-options
DROP all -- anywhere anywhere

Chain valid-source-address (2 references)
target prot opt source destination
DROP all -- localhost.localdomain anywhere
DROP all -- 0.0.0.0/8 anywhere
DROP all -- anywhere 255.255.255.255

Chain valid-source-address-udp (1 references)
target prot opt source destination
DROP all -- localhost.localdomain anywhere
DROP all -- 0.0.0.0/8 anywhere

Chain valid-tcp-flags (2 references)
target prot opt source destination
log-and-drop tcp -- anywhere anywhere tcp flags:FIN,SYN ,RST,PSH,ACK,URG/NONE
log-and-drop tcp -- anywhere anywhere tcp flags:FIN,ACK /FIN
log-and-drop tcp -- anywhere anywhere tcp flags:PSH,ACK /PSH
log-and-drop tcp -- anywhere anywhere tcp flags:ACK,URG /URG
log-and-drop tcp -- anywhere anywhere tcp flags:FIN,SYN /FIN,SYN
log-and-drop tcp -- anywhere anywhere tcp flags:SYN,RST /SYN,RST
log-and-drop tcp -- anywhere anywhere tcp flags:FIN,RST /FIN,RST
jhinrichs
jhinrichs 25.02.2009 um 14:27:58 Uhr
Goto Top
Die Regeln scheinen mir teils redundant, teils unvollständig. Um Klarheit zu bringen, versuch einmal folgendes:

/sbin/iptables-save -c > ~/iptables-save

sichert die aktuellen Regeln

/sbin/iptables -F INPUT
/sbin/iptables -F OUTPUT

löscht die aktuellen Regeln

/sbin/iptables -P INPUT ACCEPT
/sbin/iptables -P OUTPUT ACCEPT

erlaubt (fast) alles

Geht dann der ssh-Zugriff?

Wiederherstellen der alten Regeln mit

cat ~/iptables-save | /sbin/iptables-restore -c


Und was ergibt

/sbin/iptables -L

auf dem Client?
49372
49372 26.02.2009 um 12:07:33 Uhr
Goto Top
besten dank für deine Hilfe, es hat wirklich funktioniert gemäss deiner Anleitung. Es war die firewall des Tux

Wie richtet man dies richtig ein, jetzt wird wohl die firewall alles durchlassen und ein sicherheitsrisiko sein oder?

Auf der einter VMware maschine kommt beim befelh scp diese Meldung:
Permission denied (publickey,password,keyboard-interactive).

An was liegt das? auf der anderer Maschine läuft es richtig

Mal neh frage, von woher hast du das so gut gelernt mit Linux? möchte das auch so gut können und vorallem verstehen die Parametern und wie mehr Befelh sucht etc.
jhinrichs
jhinrichs 27.02.2009 um 08:25:56 Uhr
Goto Top
Danke für die Blumen...
Du wirst gemerkt haben, dass die geänderten iptables-Einstellungen nur bis zum nächsten reboot halten.
Wenn ich die, wie ich finde nicht durchweg schlüssigen, Regeln Deines Systems richtig verstanden habe (wobei ich mir nicht ganz sicher bin), fehlt in der OUTPUT-Chain die ACCESS-Regel für ssh. Die solltest Du einbauen.
Jetzt gilt es also, herauszufinden, wo beim Systemstart die Filterregeln hinterlegt sind. Dazu gibt es theoretisch unendlich viele Möglichkeiten, zumindest aber so viele, wie es Mücken gibt.
Da man aber per vollständiger Induktion beweisen kann, dass es unendlich viele Mücken gibt, kommt das auf das gleiche heraus:
1. Es gibt mindestens eine Mücke.
2. Wenn ich eine Mücke erschlage kommt immer noch eine Mücke
3. Also gibt es unendlich viele Mücken.
q.e.d.


Zwei häufige sind:
1. init-Scripte
2. eine Datei, gerne in /etc/sysconfig/iptables

Tückisch ist, dass im Grunde jedes init-Skript die Regeln ändern/ergänzen kann.

Vorschlag: suche zunächst die Datei /etc/sysconfig/iptables, alternativ im gesamten /etc-Baum mit

find /etc -name iptables

Die init scripte kannst Du mit

grep -n -e iptables -f /etc/init.d/*

durchsuchen lassen. Findet sich da etwas?

Das zweite Problem, das Du beschreibst, hat häufig etwas mit zu großzügigen Berechtigungen auf ssh-Schlüsseldateien zu tun, hier reicht im Grund immer ein rw- --- ---. Forsche da einmal nach (auf dem Client)

Wenn Du eine gemischte Linux/Windows-Umgebung betreibst, kann ich folgendes Buch (auch online einsehbar, aber ich finde es so gut, dass man es kaufen sollte) empfehlen: http://www.linuxbu.ch
Es gibt auch gut verständliche Grundlagen in reine Linux-Server-Themen.
49372
49372 27.02.2009 um 10:23:31 Uhr
Goto Top
hm also ich denke das einfachste wäre, wenn ich die Firewall des Linux Kernel ausschalten könnte, damit das probelm nicht mehr auftaucht

Nur muss ich schauen wie das funktioniert, leider hab ich keine erfahrung und die Man Page des iptables hat mir auch nicht weiter gebracht, um für die ssh einen Chain auf der Firewall einzurichten damit scp und ssh funktioniert.

Das Linux Buch welches du mir vorgeschlagen hast ist sehr gut aufgebaut, jedoch vermisse ich so die Grundlagen von Linux, gibt es da noch ein Linux Buch mit Grundlagen welches wirklich zu empfehlen ist?
jhinrichs
jhinrichs 27.02.2009 um 10:45:46 Uhr
Goto Top
EInfach ausschalten (ohne den Kernel neu zu kompilieren) geht nicht, ausgeschaltet ist die Firewall sozusagen durch die o.g. Policies (alles erlauben). Ausschalten würde ich auch nicht machen, auf gar keinen Fall, wenn der Rechner direkt am Internet hängt. Eine Regel für ssh einzufügen ist nicht schwer, würden wir schon hier hinkriegen, dazu musst Du aber wissen, wo in deinem System die Regeln beim Systemstart definiert sind (s.o.)
Ein allgemeines Buch zu Linux-Grundlagen ist eher schwierig zu empfehlen, da die meisten allgemeinen Linux-Bücher eher für User mit Inhalten wie "wie spiele ich mp3s ab", "wie bearbeite ich Office-Dokumente" etc. gefüllt sind. Für Server-Themen gibt es dann jeweils spezialisierte Bücher oder die große weite Welt des www. Ich denke, Du solltest Dich, da die Beurteilung "gut "oder "schlecht " sehr individuell ist, mit viel Zeit und EC-Karte in eine gut sortierte Buchhandlung setzen und schmökern...
49372
49372 27.02.2009 um 10:56:10 Uhr
Goto Top
Befehl find /etc -name iptables:

Ausgabe:
/etc/rc.d/init.d/iptables

Befehl grep -n -e iptables -f /etc/init.d/*:

Ausgabe:
grep: Trailing backslash

WIe macht man dies den mit dem Chain?
jhinrichs
jhinrichs 27.02.2009 um 11:04:24 Uhr
Goto Top
Jetzt poste bitte mal die Datei /etc/rc.d/init.d/iptables
49372
49372 27.02.2009 um 11:35:31 Uhr
Goto Top
Das wird ausgegeben wenn ich den Befehl eingebe:

Usage: /etc/rc.d/init.d/iptables {start|stop|restart|condrestart|status|panic|save}
jhinrichs
jhinrichs 27.02.2009 um 11:44:49 Uhr
Goto Top
Sry, ich meinte nicht die Ausgabe, sondern den Inhalt...

cat /etc/rc.d/init.d/iptables
49372
49372 27.02.2009 um 13:10:08 Uhr
Goto Top
damit bekomme ich die ganze Firewall Code die etliche Zeilen lang sind.
jhinrichs
jhinrichs 27.02.2009 um 13:13:44 Uhr
Goto Top
Schon klar. Alles muss aber auch nicht. Die essentiellen Zeilen kriegst Du über:

cat /etc/rc.d/init.d/iptables | grep -n iptables

Die definieren die Filterregeln, und die sind alle wichtig...

cat listet die Datei und grep filtert alle Zeilen mit dem Inhalt "iptables" heraus. Das "-n" sorgt dafür, dass grep die Zeilennummer mit angibt, damit man später beim editieren weiß, wo man suchen muss-
49372
49372 27.02.2009 um 14:33:20 Uhr
Goto Top
3:# iptables Start iptables firewall
6:# description: Starts, stops and saves iptables firewall
8:# config: /etc/sysconfig/iptables
9:# config: /etc/sysconfig/iptables-config
14:IPTABLES=iptables
170: # Do not stop if iptables module is not loaded.
226: # Do not print status if lockfile is missing and iptables modules are not
jhinrichs
jhinrichs 27.02.2009 um 14:39:33 Uhr
Goto Top
Da es /etc/sysconfig/iptables nicht gibt (sonst hätte find sie gefunden), poste doch bitte 1. das Ergebnis von

ls -al /etc/sysconfig/iptables*

und 2., sofern vorhanden, den Inhalt von

/etc/sysconfig/iptables-config