h2oo
(Themenstarter)
Anmeldungsdatum: 23. Juni 2018
Beiträge: Zähle...
|
sudo netstat -tlpena | grep -i 22
| tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 0 11562 453/sshd
tcp 0 0 192.168.178.36:445 192.168.178.22:44082 ESTABLISHED 0 13628 622/smbd
tcp 0 0 192.168.178.36:445 192.168.178.22:44080 ESTABLISHED 0 14785 623/smbd
tcp 0 0 192.168.178.36:52292 88.85.73.243:443 ESTABLISHED 0 18774 396/java
tcp 0 0 192.168.178.36:22 192.168.178.22:44096 ESTABLISHED 0 14881 777/sshd: pi [priv]
tcp6 0 0 :::22 :::* LISTEN 0 13358 453/sshd
|
cat /etc/ssh/sshd_config
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123 | # $OpenBSD: sshd_config,v 1.100 2016/08/15 12:32:04 naddy Exp $
# This is the sshd server system-wide configuration file. See
# sshd_config(5) for more information.
# This sshd was compiled with PATH=/usr/bin:/bin:/usr/sbin:/sbin
# 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 override the
# default value.
#Port 22
#AddressFamily any
#ListenAddress 0.0.0.0
#ListenAddress ::
#HostKey /etc/ssh/ssh_host_rsa_key
#HostKey /etc/ssh/ssh_host_ecdsa_key
#HostKey /etc/ssh/ssh_host_ed25519_key
# Ciphers and keying
#RekeyLimit default none
# Logging
#SyslogFacility AUTH
#LogLevel INFO
# Authentication:
#LoginGraceTime 2m
#PermitRootLogin prohibit-password
#StrictModes yes
#MaxAuthTries 6
#MaxSessions 10
#PubkeyAuthentication yes
# Expect .ssh/authorized_keys2 to be disregarded by default in future.
#AuthorizedKeysFile .ssh/authorized_keys .ssh/authorized_keys2
#AuthorizedPrincipalsFile none
#AuthorizedKeysCommand none
#AuthorizedKeysCommandUser nobody
# For this to work you will also need host keys in /etc/ssh/ssh_known_hosts
#HostbasedAuthentication no
# Change to yes if you don't trust ~/.ssh/known_hosts for
# HostbasedAuthentication
#IgnoreUserKnownHosts no
# Don't read the user's ~/.rhosts and ~/.shosts files
#IgnoreRhosts yes
# To disable tunneled clear text passwords, change to no here!
#PasswordAuthentication yes
#PermitEmptyPasswords no
# Change to yes to enable challenge-response passwords (beware issues with
# some PAM modules and threads)
ChallengeResponseAuthentication no
# Kerberos options
#KerberosAuthentication no
#KerberosOrLocalPasswd yes
#KerberosTicketCleanup yes
#KerberosGetAFSToken no
# GSSAPI options
#GSSAPIAuthentication no
#GSSAPICleanupCredentials yes
#GSSAPIStrictAcceptorCheck yes
#GSSAPIKeyExchange no
# Set this to 'yes' to enable PAM authentication, account processing,
# and session processing. If this is enabled, PAM authentication will
# be allowed through the ChallengeResponseAuthentication and
# PasswordAuthentication. Depending on your PAM configuration,
# PAM authentication via ChallengeResponseAuthentication may bypass
# the setting of "PermitRootLogin without-password".
# If you just want the PAM account and session checks to run without
# PAM authentication, then enable this but set PasswordAuthentication
# and ChallengeResponseAuthentication to 'no'.
UsePAM yes
#AllowAgentForwarding yes
#AllowTcpForwarding yes
#GatewayPorts no
X11Forwarding yes
#X11DisplayOffset 10
#X11UseLocalhost yes
#PermitTTY yes
PrintMotd no
#PrintLastLog yes
#TCPKeepAlive yes
#UseLogin no
#UsePrivilegeSeparation sandbox
#PermitUserEnvironment no
#Compression delayed
#ClientAliveInterval 0
#ClientAliveCountMax 3
#UseDNS no
#PidFile /var/run/sshd.pid
#MaxStartups 10:30:100
#PermitTunnel no
#ChrootDirectory none
#VersionAddendum none
# no default banner path
#Banner none
# Allow client to pass locale environment variables
AcceptEnv LANG LC_*
# override default of no subsystems
Subsystem sftp /usr/lib/openssh/sftp-server
# Example of overriding settings on a per-user basis
#Match User anoncvs
# X11Forwarding no
# AllowTcpForwarding no
# PermitTTY no
# ForceCommand cvs server
|
|
lubux
Anmeldungsdatum: 21. November 2012
Beiträge: 13933
|
h2oo schrieb: sudo netstat -tlpena | grep -i 22
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 0 11562 453/sshd
tcp6 0 0 :::22 :::* LISTEN 0 13358 453/sshd
Der sshd des PI sollte in dieser Standard-Konfiguration auf die syn-Anfrage des Laptop antworten.
Obwohl auf den Ping geantwortet wurde, versuch mal auf deinem PI, mit:
sudo route add -host 192.168.60.21 gw 192.168.61.11 dev eth0
route -n EDIT: Wie ist auf deinem PI, die Ausgabe von:
sudo iptables -nvx -L
? EDIT 2: Mach mal einen Ping von deinem PI via eth0-Interface, zu deinem Laptop:
ping -c 3 -I eth0 192.168.60.21
|
h2oo
(Themenstarter)
Anmeldungsdatum: 23. Juni 2018
Beiträge: Zähle...
|
HAHA, also den Ping habe ich als erstes ausgeführt. Dieser hat auch von Raspberry in Richtung Laptop funktioniert. Die Ausgabe von sudo iptables -nvx -L
| Chain INPUT (policy ACCEPT 4483 packets, 4803464 bytes)
pkts bytes target prot opt in out source destination
Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
Chain OUTPUT (policy ACCEPT 5063 packets, 415135 bytes)
pkts bytes target prot opt in out source destination
|
danach hab ich die neue route von Raspberry aus (respektive das gleich doch wie oben vom Laptop aus - nur in die andere Richtung) erstellt. Und TADA ich komm nun per SSH über die Ethernet-IP in den Raspberry. ABER wenn ich nun via rsync eine Datei kopiere wird trotzdem offenbar die WLAN Verbindung über den Router benutzt anstatt die Kabelverbindung über den Switch.
//edit: Ich würde gerne durch die IP mit welcher ich in den Raspberry SSH'e bestimmen welche "Datenroute" genutzt wird.
|
lubux
Anmeldungsdatum: 21. November 2012
Beiträge: 13933
|
h2oo schrieb: Ich würde gerne durch die IP mit welcher ich in den Raspberry SSH'e, bestimmen welche "Datenroute" genutzt wird.
Dann versuch mal mit "ip rule". Z. B. auf deinem Laptop:
sudo ip rule add from 192.168.60.21 table 10
sudo ip route add 192.168.61.11 via 192.168.60.21 table 10
|
h2oo
(Themenstarter)
Anmeldungsdatum: 23. Juni 2018
Beiträge: 192
|
nope das hat leider nicht gebracht. Datenübertragung immer noch via WLAN.
|
lubux
Anmeldungsdatum: 21. November 2012
Beiträge: 13933
|
h2oo schrieb: ... Datenübertragung immer noch via WLAN.
Aber nur bei rsync, oder?
|
h2oo
(Themenstarter)
Anmeldungsdatum: 23. Juni 2018
Beiträge: 192
|
auch bei cp und mv wird das WLAN benutzt anstatt der Ethernet Verbindung.
.
EDIT:
ich weiß ehrlich gesagt auch nicht ob wirklich der eigentliche SSH Datenverkehr (also die Kommunikation selbst) auch über WLAN oder Ethernet läuft. Ich schaue mir am Laptop mit ethstatus die Datenmengen und Geschwindigkeiten an von wlp2s0 und enp1s0f1
|
lubux
Anmeldungsdatum: 21. November 2012
Beiträge: 13933
|
h2oo schrieb: ich weiß ehrlich gesagt auch nicht ob wirklich der eigentliche SSH Datenverkehr (also die Kommunikation selbst) auch über WLAN oder Ethernet läuft. Ich schaue mir am Laptop mit ethstatus die Datenmengen und Geschwindigkeiten an von wlp2s0 und enp1s0f1
Das kannst Du doch mit tcpdump oder mit iptables feststellen. Z. B. auf deinem PI:
sudo tcpdump -c 100 -vvveni wlan0 port 22
oder mit: sudo iptables -I INPUT 1 -i wlan0 -p tcp --dport 22
(d. h. eine iptables-Regel ohne target und siehe dann deren counter).
... oder Du blockst den ssh-Traffic auf dem wlan0-Interface zum Port 22:
sudo iptables -I INPUT 1 -i wlan0 -p tcp --dport 22 -j REJECT
|
h2oo
(Themenstarter)
Anmeldungsdatum: 23. Juni 2018
Beiträge: 192
|
ok, mit tcpdump kommt über sudo tcpdump -c 100 -vvveni wlan0 port 22 kein traffic, wenn ich jedoch sudo tcpdump -c 100 -vvveni eth0 port 22 ausführe ist die Liste mit den 100 Einträgen gleich voll, da ich ja die Ethernet-IP zum SSH'en genutzt habe.
- Dann hab ich das ganze umgedreht und mich mit der WLAN-IP eingeloggt. Dabei blieb dann dass tcpdump mit Parameter eth0 leer und wlan0 war gleich voll. Also läuft der SSH Datentransfer tatsächlich über die IP welche ich beim SSH'en auswähle *yeah*
.
Dann haben ich ja Teil 1 schon erledigt. Gibt's denn eine Möglichkeit rsync (was ja auch gemacht wurde im Daten im Netzwerk hin/herzuschieben) anzuweisen eth0 zu benutzen? Habe da nur die "Funktion" gefunden. Kann man das noch ausweiten?
| -4, --ipv4 prefer IPv4
-6, --ipv6 prefer IPv6
|
|
lubux
Anmeldungsdatum: 21. November 2012
Beiträge: 13933
|
h2oo schrieb: Gibt's denn eine Möglichkeit rsync (was ja auch gemacht wurde im Daten im Netzwerk hin/herzuschieben) anzuweisen eth0 zu benutzen?
Ich benutze rsync nicht. Wird bei dir, rsync als daemon/client benutzt? Wenn ja, dann sollte das doch möglich sein.
Evtl. kann dir jemand der sich damit auskennt, hier weiter helfen.
|
misterunknown
Ehemalige
Anmeldungsdatum: 28. Oktober 2009
Beiträge: 4403
Wohnort: Sachsen
|
h2oo schrieb: Dann haben ich ja Teil 1 schon erledigt. Gibt's denn eine Möglichkeit rsync (was ja auch gemacht wurde im Daten im Netzwerk hin/herzuschieben) anzuweisen eth0 zu benutzen? Habe da nur die "Funktion" gefunden. Kann man das noch ausweiten?
Nein. rsync ist nicht für den Transport zuständig. Über welches Interface die Pakete gehen, steht in der Routing-Tabelle. Du könntest maximal Policy-Routing verwenden, um rsync gesondert zu behandeln.
|
h2oo
(Themenstarter)
Anmeldungsdatum: 23. Juni 2018
Beiträge: 192
|
Nein zur Zeit benutze ich rsync "manuell" per Hand im Terminal während ich in der SSH Session des Raspberrys bin. Das mit dem Pfad von rsync hat nun auch funktioniert indem ich die Netzwerkfreigabe selbst nicht mit dem Hostnamen sondern mit der IP Adresse eingehängt hatte. Sprich es hatte artig die Daten über die Ethernet Verbindung übertragen Tja ich muss nun leider alle Schritte noch einmal durchgehen, ich hatte meinen Laptop von gestern auf heute heruntergefahren und nun erreiche ich erneut den Raspberry via Ethernet nicht.
OK also ich muss diese beiden Zeilen ausführen, scheinbar wurden die beim Neustart verworfen, den sie fehlten in route -n und arp -av
| sudo route add -host 192.168.61.11 gw 192.168.60.21 dev enp1s0f1
sudo arp -i enp1s0f1 -s 192.168.61.11 B8:27:EB:EB:00:DF
|
so nun erreiche ich den Raspberry wieder via SSH. Kann ich das irgendwie "permanent" ins System einspeichern?
|
h2oo
(Themenstarter)
Anmeldungsdatum: 23. Juni 2018
Beiträge: 192
|
Hmm, ich habe nun alles an dem Switch im selben Subnetz und schon brauche ich nicht mal mehr das Hinzufügen der Routen - jetzt läuft alles auf 192.168.60.xxx Soweit so gut, vielen Dank an alle.
|
Qupfer
Anmeldungsdatum: 10. Februar 2007
Beiträge: 114
|
Ich habe - glaube ich - nicht so wirklich verstanden, was du eigentlich erreichen willst bzw. wie deine "Verkabelung" aussieht.
Ich gehe mal von folgenden aus: FritzBox mit DHCP ←--Funk-–> Laptop ←--Kabel-–> Switch ←--Kabel-–> Raspi
^
|–-Kabel-–> NAS und möchtest erreiche, dass alle Geräte Internet haben bzw. im selben Netz hängen? Im Prinzip müsstest du dann nur dein Laptop ebenfalls zum Switch machen. Stichwort bridge.
Zum ausprobieren die bridge-utils installieren und mit brctl addbr br0 #die bridge br0 erstellen
brctl addif br0 wlan0 #das wlan Interface zu bridge hinzufügen
brctl addif br0 enp1s0f1 #das Ethernet Interface zu bridge hinzufügen Habe aber noch nie WLAN mit Ethernet zusammen gebridged (eventuell gibs da noch Fallstricke). Auch darf nur 1 DHCP im Netz sein, also der am NAS sollte aus bleiben.
Vermutlich wird dir auch Ubuntu mit seinen Netzwerktools zwischen funken und automatisch wieder irgendwas machen. Aber am besten ist wohl, nochmal kurz und exakt zu beschreiben, was du eigentlich machen willst.
|