Discussion:
IPv6 port open op Fritz 7360v2 6.52 werkt niet, of niet vanaf xs9?
(te oud om op te antwoorden)
A. Dumas
2017-03-02 16:43:19 UTC
Permalink
Port forwarding over IPv4 werkt prima: ik definieer een externe en
interne port in Fritz en ik kan ssh'en van buiten naar binnen. "Buiten"
is nu shell.xs4all.nl maar laatst ook een Ziggo-aansluiting.

Nu probeer ik hetzelfde via IPv6, maar het werkt niet. Ik heb op mijn
eigen domein een AAAA-record gemaakt voor de server, dat werkt: op
shell.xs4all.nl (xs9) krijg ik het juiste 2001:980:etc adres voor de
naam. Maar ssh -6 (op de juiste port, met de juiste user) geeft
Permission Denied.

Zet Fritz de poort niet goed open of laat xs9 het niet toe, of wat zou
het kunnen zijn? Hoeft toch geen UDP-verkeer te hebben?

Wat ik zie:
***@xs9:~$ ssh -v -6 -p 12345 ***@server.mijndomein
OpenSSH_6.7p1 Debian-5+deb8u3, OpenSSL 1.0.1t 3 May 2016
debug1: Reading configuration data /home/x/xsuser/.ssh/config
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: Connecting to server.mijndomein [2001:980:etc] port 12345.
debug1: connect to address 2001:980:etc port 12345: Permission denied
ssh: connect to host server.mijndomein port 12345: Permission denied

Inhoud van /etc/ssh/ssh_config:
Host *
SendEnv LANG LC_*
HashKnownHosts yes
GSSAPIAuthentication yes
GSSAPIDelegateCredentials no
UseRoaming no
Osiris
2017-03-02 17:27:34 UTC
Permalink
Post by A. Dumas
Port forwarding over IPv4 werkt prima: ik definieer een externe en
interne port in Fritz en ik kan ssh'en van buiten naar binnen. "Buiten"
is nu shell.xs4all.nl maar laatst ook een Ziggo-aansluiting.
Nu probeer ik hetzelfde via IPv6, maar het werkt niet. Ik heb op mijn
eigen domein een AAAA-record gemaakt voor de server, dat werkt: op
shell.xs4all.nl (xs9) krijg ik het juiste 2001:980:etc adres voor de
naam. Maar ssh -6 (op de juiste port, met de juiste user) geeft
Permission Denied.
Zet Fritz de poort niet goed open of laat xs9 het niet toe, of wat zou
het kunnen zijn? Hoeft toch geen UDP-verkeer te hebben?
OpenSSH_6.7p1 Debian-5+deb8u3, OpenSSL 1.0.1t 3 May 2016
debug1: Reading configuration data /home/x/xsuser/.ssh/config
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: Connecting to server.mijndomein [2001:980:etc] port 12345.
debug1: connect to address 2001:980:etc port 12345: Permission denied
ssh: connect to host server.mijndomein port 12345: Permission denied
Host *
SendEnv LANG LC_*
HashKnownHosts yes
GSSAPIAuthentication yes
GSSAPIDelegateCredentials no
UseRoaming no
"Permission denied" klinkt alsof de TCP-pakketjes wel op je server
aankomen (en dus niet vastlopen op de Fritz!Box, dan zou je een timeout
verwachten), maar dat er niets luistert op je server op poort 12345.

Heb je bij IPv4 toevallig externe poort 12345 naar interne poort 22
gemapped? Dat "kan" namelijk niet bij IPv6 (in de Fritz!Box): je opent
een poort of niet. Je kunt alleen X openen, niet X extern -> Y intern.
A. Dumas
2017-03-02 18:08:02 UTC
Permalink
Post by Osiris
Post by A. Dumas
Port forwarding over IPv4 werkt prima: ik definieer een externe en
interne port in Fritz en ik kan ssh'en van buiten naar binnen. "Buiten"
is nu shell.xs4all.nl maar laatst ook een Ziggo-aansluiting.
Nu probeer ik hetzelfde via IPv6, maar het werkt niet. Ik heb op mijn
eigen domein een AAAA-record gemaakt voor de server, dat werkt: op
shell.xs4all.nl (xs9) krijg ik het juiste 2001:980:etc adres voor de
naam. Maar ssh -6 (op de juiste port, met de juiste user) geeft
Permission Denied.
Zet Fritz de poort niet goed open of laat xs9 het niet toe, of wat zou
het kunnen zijn? Hoeft toch geen UDP-verkeer te hebben?
OpenSSH_6.7p1 Debian-5+deb8u3, OpenSSL 1.0.1t 3 May 2016
debug1: Reading configuration data /home/x/xsuser/.ssh/config
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: Connecting to server.mijndomein [2001:980:etc] port 12345.
debug1: connect to address 2001:980:etc port 12345: Permission denied
ssh: connect to host server.mijndomein port 12345: Permission denied
Host *
SendEnv LANG LC_*
HashKnownHosts yes
GSSAPIAuthentication yes
GSSAPIDelegateCredentials no
UseRoaming no
"Permission denied" klinkt alsof de TCP-pakketjes wel op je server
aankomen (en dus niet vastlopen op de Fritz!Box, dan zou je een timeout
verwachten), maar dat er niets luistert op je server op poort 12345.
Heb je bij IPv4 toevallig externe poort 12345 naar interne poort 22
gemapped? Dat "kan" namelijk niet bij IPv6 (in de Fritz!Box): je opent
een poort of niet. Je kunt alleen X openen, niet X extern -> Y intern.
Voor IPv4 heb ik verschillende externe poorten ge-forward telkens naar
dezelfde poort op verschillende servers: 2200 naar server0:2200, 2201
naar server1:2200, 2202 naar server2:2200. Dat werkt en heeft altijd
gewerkt.

Voor IPv6 noemt Fritz het ook forward, maar dat is alleen openen in de
firewall, dat weet ik. Dus daar heb ik op de verschillende interfaces
telkens dezelfde poort geopend: 2200 voor server0:2200, 2200 voor
server1:2200, 2200 voor server2:2200. Permission Denied op alledrie.

Maar intern IPv6 werkt wel! In /etc/ssh/sshd_config op de servers staat:

Port 22000
#ListenAddress ::
#ListenAddress 0.0.0.0

dus zou moeten werken, en werkt intern ook, op elk IPv4 of IPv6 adres.
Ik snap 't niet.
A. Dumas
2017-03-02 18:15:25 UTC
Permalink
Post by A. Dumas
telkens dezelfde poort geopend: 2200 voor server0:2200, 2200 voor
server1:2200, 2200 voor server2:2200. Permission Denied op alledrie.
Dit was ge-edit...
Post by A. Dumas
Port 22000
...en die is echt. Sorry voor de verwarring, verkeerde port is niet het
probleem!
A. Dumas
2017-03-02 19:58:14 UTC
Permalink
Post by Osiris
"Permission denied" klinkt alsof de TCP-pakketjes wel op je server
aankomen (en dus niet vastlopen op de Fritz!Box, dan zou je een timeout
verwachten), maar dat er niets luistert op je server op poort 12345.
Kweenie, er verschijnt niks in /var/log/auth.log tijdens een Permission
Denied poging en wel tijdens een succesvolle connectie, dus ik denk toch
dat Fritz ze tegenhoudt.
Rob
2017-03-02 17:55:51 UTC
Permalink
Post by A. Dumas
Port forwarding over IPv4 werkt prima: ik definieer een externe en
interne port in Fritz en ik kan ssh'en van buiten naar binnen. "Buiten"
is nu shell.xs4all.nl maar laatst ook een Ziggo-aansluiting.
Nu probeer ik hetzelfde via IPv6, maar het werkt niet. Ik heb op mijn
eigen domein een AAAA-record gemaakt voor de server, dat werkt: op
shell.xs4all.nl (xs9) krijg ik het juiste 2001:980:etc adres voor de
naam. Maar ssh -6 (op de juiste port, met de juiste user) geeft
Permission Denied.
O bij mij werkt dat wel maar je moet het wel open zetten in de Fritz.
A. Dumas
2017-03-02 18:13:15 UTC
Permalink
Post by Rob
Post by A. Dumas
Port forwarding over IPv4 werkt prima: ik definieer een externe en
interne port in Fritz en ik kan ssh'en van buiten naar binnen. "Buiten"
is nu shell.xs4all.nl maar laatst ook een Ziggo-aansluiting.
Nu probeer ik hetzelfde via IPv6, maar het werkt niet. Ik heb op mijn
eigen domein een AAAA-record gemaakt voor de server, dat werkt: op
shell.xs4all.nl (xs9) krijg ik het juiste 2001:980:etc adres voor de
naam. Maar ssh -6 (op de juiste port, met de juiste user) geeft
Permission Denied.
O bij mij werkt dat wel maar je moet het wel open zetten in de Fritz.
Dat heb ik. Hoef 'm toch niet te rebooten?
Loading Image...
Rob
2017-03-02 19:09:17 UTC
Permalink
Post by A. Dumas
Post by Rob
Post by A. Dumas
Port forwarding over IPv4 werkt prima: ik definieer een externe en
interne port in Fritz en ik kan ssh'en van buiten naar binnen. "Buiten"
is nu shell.xs4all.nl maar laatst ook een Ziggo-aansluiting.
Nu probeer ik hetzelfde via IPv6, maar het werkt niet. Ik heb op mijn
eigen domein een AAAA-record gemaakt voor de server, dat werkt: op
shell.xs4all.nl (xs9) krijg ik het juiste 2001:980:etc adres voor de
naam. Maar ssh -6 (op de juiste port, met de juiste user) geeft
Permission Denied.
O bij mij werkt dat wel maar je moet het wel open zetten in de Fritz.
Dat heb ik. Hoef 'm toch niet te rebooten?
https://ewoud.home.xs4all.nl/misc/fritzipv6port.png
Nee dat moet werken volgens mij. Ik heb 2 hosts maar 1 heb ik helemaal
open gezet en de ander alleen poort 22. Daar staat dan vervolgens weer
een eigen filter in met een source adres wat ik wil doorlaten.
(dat ondersteunt Fritz niet)
Miquel van Smoorenburg
2017-03-02 21:53:58 UTC
Permalink
Post by A. Dumas
OpenSSH_6.7p1 Debian-5+deb8u3, OpenSSL 1.0.1t 3 May 2016
debug1: Reading configuration data /home/x/xsuser/.ssh/config
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: Connecting to server.mijndomein [2001:980:etc] port 12345.
debug1: connect to address 2001:980:etc port 12345: Permission denied
ssh: connect to host server.mijndomein port 12345: Permission denied
Run 'tcpdump -n tcp port 2200' op je linux doos als je dit doet, dan
zie je of en wat er voor packets binnenkomen.

Mike.
A. Dumas
2017-03-02 22:55:25 UTC
Permalink
Post by Miquel van Smoorenburg
Run 'tcpdump -n tcp port 2200' op je linux doos als je dit doet, dan
zie je of en wat er voor packets binnenkomen.
Aja bedankt, dat soort dingen weet ik niet zo snel. De verbosity is
zeker anders met of zonder redirect naar file? Zonder: eindeloze lijst
in een paar seconden, met: maar een paar regels (geen verschil met -vv).

Hoe dan ook, tijdens korte capture met succesvolle connectie vanaf xs9
over ipv4 zijn er 51 regels met "194.109.21.9" en 62 zonder. Tijdens
mislukte connectie over ipv6 zijn er 0 regels met "888" (adres van xs9
is 2001:888:0:1::9) en 9 zonder. Dus ik denk niet dat er iets aankomt.

Systeemlog in de webinterface van Fritz (ook met "All") zegt niks over
dit soort verbindingen. Misschien wel in een debug/service capture? Hoe
ging dat ook alweer, 1 of andere lua pagina geloof ik.
Miquel van Smoorenburg
2017-03-03 10:03:03 UTC
Permalink
Post by A. Dumas
Post by Miquel van Smoorenburg
Run 'tcpdump -n tcp port 2200' op je linux doos als je dit doet, dan
zie je of en wat er voor packets binnenkomen.
Aja bedankt, dat soort dingen weet ik niet zo snel. De verbosity is
zeker anders met of zonder redirect naar file? Zonder: eindeloze lijst
in een paar seconden, met: maar een paar regels (geen verschil met -vv).
Nee, de verbosity is zeker niet anders. Je doet iets raars :)

-n = geen DNS resolving van adressen op packets
tcp port 2200 = letterlijk wat het zegt

als je dan een stroom packets ziet ben je 'tcp port 2200' vergeten,
of heb je heel veel andere lopende connecties naar poort 2200. In
het laatste geval kan je beter testen op een andere poort die je
alleen voor deze debug sessie gebruikt.
Post by A. Dumas
Hoe dan ook, tijdens korte capture met succesvolle connectie vanaf xs9
over ipv4 zijn er 51 regels met "194.109.21.9" en 62 zonder. Tijdens
mislukte connectie over ipv6 zijn er 0 regels met "888" (adres van xs9
is 2001:888:0:1::9) en 9 zonder. Dus ik denk niet dat er iets aankomt.
Daar lijkt het op.
Post by A. Dumas
Systeemlog in de webinterface van Fritz (ook met "All") zegt niks over
dit soort verbindingen. Misschien wel in een debug/service capture? Hoe
ging dat ook alweer, 1 of andere lua pagina geloof ik.
fritz.box/support.lua => packet trace

Die files kan je uitlezen met het fantastische pakket 'wireshark'.

Je kan wireshark ook gebruiken voor live tracing op je PC, ipv tcpdump.

Of je kan doen "tcpdump -w outputfile.pcap tcp port 2200" en dan
outputfile.pcap inladen in wireshark.

Mike.
A. Dumas
2017-03-03 10:14:08 UTC
Permalink
Post by Miquel van Smoorenburg
Post by A. Dumas
Aja bedankt, dat soort dingen weet ik niet zo snel. De verbosity is
zeker anders met of zonder redirect naar file? Zonder: eindeloze lijst
in een paar seconden, met: maar een paar regels (geen verschil met -vv).
Nee, de verbosity is zeker niet anders. Je doet iets raars :)
Ja, ik snap nu wat er gebeurde: hij is headless en ik zat tegelijkertijd
op een ssh-connectie om de dump te starten, dus dat gaf een enorme
feedbackloop op de terminaloutput. Met redirect naar file nauwelijks
output dus ook nauwelijks feedback :)

Heb nog niet ge-lua-t of ge-wiresharkt, ben voorlopig beetje ontmoedigd
dat het waarschijnlijk ergens zit waar ik er niks aan kan doen.
Misschien vanavond. Bedankt.
Miquel van Smoorenburg
2017-03-03 13:55:49 UTC
Permalink
Post by A. Dumas
Heb nog niet ge-lua-t of ge-wiresharkt, ben voorlopig beetje ontmoedigd
dat het waarschijnlijk ergens zit waar ik er niks aan kan doen.
Misschien vanavond. Bedankt.
Probeer 'tcpctraceroute6', voorbeeld:

* open poort:
$ tcptraceroute6 -n www.surfnet.nl 80
traceroute to surfnet.nl (2001:610:188:410:145:100:190:243) from 2001:888:0:1::9, port 80, from port 35574, 30 hops max, 60 bytes packets
1 2001:888:0:1::1 0.627 ms 0.324 ms 0.571 ms
2 2001:888:1:4000::1 0.412 ms 0.473 ms 0.462 ms
3 2001:7f8:1::a500:1103:2 0.947 ms 1.001 ms 0.860 ms
4 2001:610:f01:9216::218 1.415 ms 0.982 ms 1.417 ms
5 2001:610:188:994:145:97:20:249 1.244 ms 1.450 ms 1.185 ms
6 2001:610:188:410:145:100:190:243 1.523 ms [open] 1.517 ms 1.370 ms

* firewalled port:

$ tcptraceroute6 -n www.surfnet.nl 4000
traceroute to surfnet.nl (2001:610:508:108:192:87:108:15) from 2001:888:0:1::9, port 4000, from port 35186, 30 hops max, 60 bytes packets
1 2001:888:0:1::1 0.400 ms 0.235 ms 0.289 ms
2 2001:888:1:4006::1 0.674 ms 0.561 ms 0.577 ms
3 2001:7f8:1::a500:1103:1 0.866 ms 1.045 ms 1.044 ms
4 2001:610:e08:80::81 1.853 ms 1.069 ms 1.163 ms
5 2001:610:f01:7012::14 2.505 ms 2.682 ms 2.396 ms
6 2001:610:508:108:192:87:108:15 1.903 ms !A 1.964 ms !A 2.022 ms !A

* niks luisterend op de port (closed):

$ tcptraceroute6 -n www.bit.nl 4000
traceroute to http-bit-ev-new.lb.network.bit.nl (2001:7b8:3:5::80:19) from 2001:888:0:1::9, port 4000, from port 35941, 30 hops max, 60 bytes packets
1 2001:888:0:1::1 0.348 ms 0.740 ms 0.285 ms
2 2001:888:1:4000::1 1.293 ms 0.883 ms 0.620 ms
3 2001:7f8:1::a501:2859:1 2.252 ms 2.212 ms 2.411 ms
4 2001:7b8:3:5::80:19 2.149 ms [closed] 2.354 ms 2.433 ms

Mike.
A. Dumas
2017-03-03 13:01:00 UTC
Permalink
Post by Miquel van Smoorenburg
testen op een andere poort
Los van tcpdump dacht ik dat maar eens te proberen. Eerst ipv6 port 22
opengezet naar m'n Mac, jawel, dat werkt gewoon! Enthousiast de
listen-port op een RPi ook teruggezet naar 22, ipv6 regel toegevoegd
voor port 22 ... permission denied :( Port 22000 regel verwijderd, 22
laten staan; nog steeds niks.

Raspbian met laatste updates, nieuwste 4.9 kernel met rpi-update.
Miquel van Smoorenburg
2017-03-03 13:57:12 UTC
Permalink
Post by A. Dumas
Post by Miquel van Smoorenburg
testen op een andere poort
Los van tcpdump dacht ik dat maar eens te proberen. Eerst ipv6 port 22
opengezet naar m'n Mac, jawel, dat werkt gewoon! Enthousiast de
listen-port op een RPi ook teruggezet naar 22, ipv6 regel toegevoegd
voor port 22 ... permission denied :( Port 22000 regel verwijderd, 22
laten staan; nog steeds niks.
Raspbian met laatste updates, nieuwste 4.9 kernel met rpi-update.
Hmmm .. en je mac heeft een EUI64 adres, en je raspberry pi een
zelf ingeteld static adres? Probeer het eens met het EUI64 adres
van je pi.

Mike.
A. Dumas
2017-03-03 15:31:05 UTC
Permalink
Post by Miquel van Smoorenburg
Hmmm .. en je mac heeft een EUI64 adres, en je raspberry pi een
zelf ingeteld static adres? Probeer het eens met het EUI64 adres
van je pi.
Ahaaaa inderdaad, dat is een verschil tussen de Mac en de Pi: Mac heeft
een op MAC gebaseerd global ipv6 adres (dat zal dus wel EUI64 zijn, ik
zag overeenkomsten maar heb het niet nagerekend) en de Pi niet. Maar die
heeft ook maar één global adres, de andere is link, er is geen temporary
adres zoals op de Mac.

Ik zal wel een config-file kunnen aanpassen om (ook) EUI64-adressen te
genereren op Debian/Raspbian? Ik zal eens zoeken.

Conclusie is dus misschien dat Fritz 6.52 alleen MAC-gebaseerd cq.
alleen naar EUI64-adressen poorten kan openzetten. Jammer.
A. Dumas
2017-03-03 17:51:43 UTC
Permalink
Post by A. Dumas
Conclusie is dus misschien dat Fritz 6.52 alleen MAC-gebaseerd cq.
alleen naar EUI64-adressen poorten kan openzetten. Jammer.
Ik heb geprobeerd op de FB bij de ipv6 "port forwarding" definitie de
interface ID aan te passen, naar hetzelfde als het global ipv6 adres van
de Pi, maar dat werkte (ook) niet.
A. Dumas
2017-03-03 18:23:30 UTC
Permalink
Post by Miquel van Smoorenburg
Hmmm .. en je mac heeft een EUI64 adres, en je raspberry pi een
zelf ingeteld static adres? Probeer het eens met het EUI64 adres
van je pi.
Yep, dat was het. In /etc/dhcpcd.conf "slaac private" veranderd in
"slaac hwaddr" en nu werkt het. Bedankt!

Het melden waard bij AVM, lijkt me. Moet/kan ik dat doen of werkt het
beter als jij/jullie dat doen?
Rob
2017-03-03 14:33:54 UTC
Permalink
Post by A. Dumas
Post by Miquel van Smoorenburg
testen op een andere poort
Los van tcpdump dacht ik dat maar eens te proberen. Eerst ipv6 port 22
opengezet naar m'n Mac, jawel, dat werkt gewoon! Enthousiast de
listen-port op een RPi ook teruggezet naar 22, ipv6 regel toegevoegd
voor port 22 ... permission denied :( Port 22000 regel verwijderd, 22
laten staan; nog steeds niks.
Raspbian met laatste updates, nieuwste 4.9 kernel met rpi-update.
Oh dan werkt dat wellicht niet meer, ze zijn ssh toegang tot de Pi
sterk aan het inperken omdat de default situatie voor onwetende gebruikers
kennelijk niet safe was.

Kan zomaar zijn dat de Pi alleen nog ssh vanaf het lokale netwerk doet.
Je probeert toch niet als root in te loggen? Want dat mag meestal ook
niet meer.
A. Dumas
2017-03-03 15:20:33 UTC
Permalink
Post by Rob
Post by A. Dumas
Raspbian met laatste updates, nieuwste 4.9 kernel met rpi-update.
Oh dan werkt dat wellicht niet meer, ze zijn ssh toegang tot de Pi
sterk aan het inperken omdat de default situatie voor onwetende gebruikers
kennelijk niet safe was.
Ja, maar voor zover ik weet is dat nu alleen: sshd niet starten in
standaardinstallatie. Nooit iets gelezen over blokkeren van WAN. Ik zie
ook niks in /etc/ssh/sshd_config wat daar op lijkt (zie onder). Ik wou
zeggen: en ipv4 werkt wel vanaf xs9, maar dat is natuurlijk geforward
naar het LAN. Ik zie in elk geval niks in /var/log/auth.log, ook niet
met "LogLevel DEBUG3" in sshd_config.
Post by Rob
Kan zomaar zijn dat de Pi alleen nog ssh vanaf het lokale netwerk doet.
Je probeert toch niet als root in te loggen? Want dat mag meestal ook
niet meer.
Nee, gewoon user pi. Mijn aanpassing in sshd_config is alleen de port en
"PasswordAuthentication no", en voor nu "LogLevel DEBUG3":

# Package generated configuration file
# See the sshd_config(5) manpage for details

# What ports, IPs and protocols we listen for
Port 22000
# 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
HostKey /etc/ssh/ssh_host_ecdsa_key
HostKey /etc/ssh/ssh_host_ed25519_key
#Privilege Separation is turned on for security
UsePrivilegeSeparation yes

# Lifetime and size of ephemeral version 1 server key
KeyRegenerationInterval 3600
ServerKeyBits 1024

# Logging
SyslogFacility AUTH
LogLevel DEBUG3

# Authentication:
LoginGraceTime 120
PermitRootLogin without-password
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

# 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
Rob
2017-03-03 15:41:10 UTC
Permalink
Post by A. Dumas
Post by Rob
Post by A. Dumas
Raspbian met laatste updates, nieuwste 4.9 kernel met rpi-update.
Oh dan werkt dat wellicht niet meer, ze zijn ssh toegang tot de Pi
sterk aan het inperken omdat de default situatie voor onwetende gebruikers
kennelijk niet safe was.
Ja, maar voor zover ik weet is dat nu alleen: sshd niet starten in
standaardinstallatie. Nooit iets gelezen over blokkeren van WAN.
Ik heb wel eens een Pi image gehad wat zelfs op IPv4 de toegang tot
services beperkte tot het LAN subnet, maar dat was geen standaard
Raspbian volgens mij. Ik geloof dat het XBMC was.
A. Dumas
2017-03-03 18:35:12 UTC
Permalink
Arrrgh :)

http://xs4all.ipv6.narkive.com/QeDFxFVk/ipv6-privacy-extensions-vs-fritzbox-firewall
Geert Jan
2017-03-03 21:48:31 UTC
Permalink
Post by A. Dumas
http://xs4all.ipv6.narkive.com/QeDFxFVk/ipv6-privacy-extensions-vs-fritzbox-fire
wall

Dat gedoe met privacy lijkt vooral bedoeld te zijn voor SLAAC,
waarbij er een vaste relatie is tussen de laatste 8 bytes van
het IPv6 adres en de machine (specifiek: het MAC adres van de machine).

Dus, als je je laptop op een vreemd netwerk gebruikt is te achterhalen
dat het dezelfde machine is, op een ander netwerk, omdat de laatste
8 bytes identiek zijn.

Dat lijkt me voor een server, die vanuit "buiten" bereikbaar is,
geen probleem. Ik zet die dingen dan ook vast met statische IP adressen.

Hint: je kunt in die 8 bytes op diverse manieren het corresponderende
IPv4 adres kwijt. Bijvoorbeeld: IPv4: 192.0.2.1,
IPv6: 2001:db8::192:0:2:1. Hiermee maak je de administratie eenvoudig.

Geert Jan
A. Dumas
2017-03-03 21:59:03 UTC
Permalink
Post by Geert Jan
Post by A. Dumas
http://xs4all.ipv6.narkive.com/QeDFxFVk/ipv6-privacy-extensions-vs-fritzbox-fire
wall
Dat gedoe met privacy lijkt vooral bedoeld te zijn voor SLAAC,
waarbij er een vaste relatie is tussen de laatste 8 bytes van
het IPv6 adres en de machine (specifiek: het MAC adres van de machine).
Dus, als je je laptop op een vreemd netwerk gebruikt is te achterhalen
dat het dezelfde machine is, op een ander netwerk, omdat de laatste
8 bytes identiek zijn.
Dat lijkt me voor een server, die vanuit "buiten" bereikbaar is,
geen probleem. Ik zet die dingen dan ook vast met statische IP adressen.
Hint: je kunt in die 8 bytes op diverse manieren het corresponderende
IPv4 adres kwijt. Bijvoorbeeld: IPv4: 192.0.2.1,
IPv6: 2001:db8::192:0:2:1. Hiermee maak je de administratie eenvoudig.
Ja, nee, het maakt mij ook niet uit of ik nou het ene of het andere
vaste adres heb. Probleem was dat ik niet begreep waarom een poort
openen in de Fritz Box niet werkte. Het *moet* dus kennelijk het op MAC
gebaseerde adres zijn. En daarvoor moest ik de slaac setting in
dhcpcd.conf veranderen.
Rob
2017-03-04 07:24:27 UTC
Permalink
Post by A. Dumas
Ja, nee, het maakt mij ook niet uit of ik nou het ene of het andere
vaste adres heb. Probleem was dat ik niet begreep waarom een poort
openen in de Fritz Box niet werkte. Het *moet* dus kennelijk het op MAC
gebaseerde adres zijn. En daarvoor moest ik de slaac setting in
dhcpcd.conf veranderen.
Inderdaad gebruik ik ook altijd die adressen (dhcpcd niet), kennelijk
is dat dan essentieel. Bij Frits snappen ze het functionele verschil
tussen IP adressen en MAC adressen niet, zie ook de blamages mbt het
routeren van subnetten waarbij ze kwamen met een release die een uniek
MAC adres per IP adres eiste. Zo iets bedenk je alleen als je probeert
om het newbie-friendly te maken zonder de impact te snappen.
Philip Homburg
2017-03-04 11:41:52 UTC
Permalink
Post by Geert Jan
Hint: je kunt in die 8 bytes op diverse manieren het corresponderende
IPv4 adres kwijt. Bijvoorbeeld: IPv4: 192.0.2.1,
IPv6: 2001:db8::192:0:2:1. Hiermee maak je de administratie eenvoudig.
Zelfs 2001:db8::192.0.2.1 werkt :-)
--
We just programmed the computers to revive us when it was all over... they
were index linked to the [...] stock market prices you see, so that we'd
be revived when everybody else had rebuilt the economy enough to be able to
afford our rather expensive services again. -- Slartibartfast in THHGTTG
Geert Jan
2017-03-04 14:38:40 UTC
Permalink
Post by Philip Homburg
Zelfs 2001:db8::192.0.2.1 werkt :-)
Klopt, maar ifconfig maakt er daarna een bende van:
#ifconfig em0 inet6 2001:db8::192.0.2.1
#ifconfig em0
...
inet6 2001:db8::c000:201 prefixlen 64

Vandaar dat ik meestal de "andere" notatie kies.

Geert Jan

Loading...