49372
24.02.2009, aktualisiert um 16:35:44 Uhr
9949
34
0
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:
Bin auf Linux ein Anfänger, kann mir jemand dabei helfen bin ratlos habe auch schon einige EInstellungen auskommentiert, brachte auch nichts
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 ~
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 109870
Url: https://administrator.de/contentid/109870
Ausgedruckt am: 22.11.2024 um 12:11 Uhr
34 Kommentare
Neuester Kommentar
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.
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.
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?)
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?)
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:
und dann sshd neu startest (mit /etc/init.d/sshd restart)?
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)?
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?
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?
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*
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*
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?
/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?
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.
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.
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...
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...
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-
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-