Re: VPN et demande de redirection de port
Bonjour, si le vpn est connecter sur un pc, la box, ne pourra rien faire pour toi. Si tu souhaites que l'ordi qui héberge le serveur web, soit accessible par le vpn sur le port 80 /443, il faut faire le port translating, sur le pc qui a le vpn, pour lui dire qu'il doit contacter le pc qui a l'ip 192.168.1.x sur son port 80/443 en interne. avec iptables, on peut faire comme ça: iptables -t nat -A PREROUTING -p tcp --dport 80 -i tun0 -j DNAT --to-destination 192.168.1.10:80 Ou avec nftable, on peut faire comme ça: nft add rule ip nat PREROUTING iifname "tun0" tcp dport 80 counter dnat to 192.168.1.10:80 "tun0" dans les 2 règles précédentes est à remplacé par la vrai interface du vpn. si ça ne fonctionne pas, il faut peut être un masquerade de l'interface du vpn avant. Bref, tout ça pour dire que la box n'entre plus en ligne de compte ici. Jerem Le 16/07/2022 à 03:39, Pierre ESTREM a écrit : Bonsoir, J'éi souscrit au VPN "Private Internet Access" et j'ai eu tenté d'acquérir une IP dédiée. Comme j'ai fait une bêtise je n'ai pas pu en profiter (j'ai perdu le "jeton" et le support n'a pas répondu ! :-( ). Mais j'ai pu activer un port qui m'est dédié avec la commande "piactl set requestportfoward true". L'ip de ceserveur et le port changent évidemment dynamiquement. A partir de là je sèche complètement : je n'arrive pas à utiliser le NAT de ma box pour par exemple pointer un serveur web qui ferait parti de mon LAN... Devrais-je passer par un service DNS ? Quels conseils me donneriez-vous ? Merci -- Pierre ESTREM
Re: root crontab @reboot for loop fails
On Sat 16 Jul 2022, at 05:30, Gareth Evans wrote: > Why isn't root's $PATH available to root crontab? ie. including the > link /sbin -> /usr/sbin? By which I mean: why can't root crontab do everything sudo can do? Thanks G
Re: root crontab @reboot for loop fails
Hi Greg, On Sat 16 Jul 2022, at 04:07, Greg Wooledge wrote: [...] > "Well, read the email that cron sends you and see what the errors are." [amongst others] /bin/sh: 1: zfs: not found suggests the need for /usr/sbin/zfs It seems reasonable that /usr/sbin/* should be available to root crontab. Why isn't root's $PATH available to root crontab? ie. including the link /sbin -> /usr/sbin? > "All your crontab entries run in parallel. OK thanks. Is this documented? $ man crontab then /parallel [ie search for "parallel"] returns nothing. > "If you wanted to run a bunch of commands a boot time, without setting > up systemd units for them, and proper dependencies, why didn't you just > use /etc/rc.local?" I was of the impression (which I think it is fair to say has been created) that systemd had done away with /etc/rc.local, and crontab @reboot is much simpler than systemd units and whatever dependencies there may be. > Figure out whether your commands are allowed to run in parallel [...] They are not. > If they're not, use a *script* [...] With /usr/bin/zfs, that's working, thank you. Best wishes, Gareth
Re: root crontab @reboot for loop fails
On Sat, Jul 16, 2022 at 03:49:09AM +0100, Gareth Evans wrote: > $ sudo crontab -l > [...] > @reboot for f in $(/usr/sbin/zfs list -t snap -o name|grep reboot); do > /usr/sbin/zfs destroy $f;done > @reboot /usr/sbin/zfs snap -r rpool@reboot > > > Prepending "/usr/sbin/" to "zfs" doesn't make a difference. Let me start by saying I don't know a single thing about ZFS. My first reaction to this thread of yours is, "Well, read the email that cron sends you and see what the errors are." But that's the easy and obvious reaction. My second reaction goes a little bit deeper: "All your crontab entries run in parallel. So your first line which has zfs in it, and your second line which also has zfs in it, those both run at the same time. Is that OK?" Since I have no idea what any of those ZFS commands do, I can't tell whether it's OK to have that race condition. I suspect it's not OK, but what do I know? My third reaction goes something like this: "If you wanted to run a bunch of commands a boot time, without setting up systemd units for them, and proper dependencies, why didn't you just use /etc/rc.local?" Using a crontab to duplicate the functionality of rc.local seems odd to me. Anyway, read your errors. They may tell you what's wrong. Figure out whether your commands are allowed to run in parallel. If they're not, use a *script*, instead of a bunch of parallel commands. That script could be /etc/rc.local, or it could be a separate script that you call from rc.local, or even call from crontab if you really insist.
Re: root crontab @reboot for loop fails
$ sudo crontab -l [...] @reboot for f in $(/usr/sbin/zfs list -t snap -o name|grep reboot); do /usr/sbin/zfs destroy $f;done @reboot /usr/sbin/zfs snap -r rpool@reboot Prepending "/usr/sbin/" to "zfs" doesn't make a difference. Thanks, Gareth
root crontab @reboot for loop fails
Hello, $ sudo crontab -l | grep reboot [...] [1] @reboot sleep 10; nmcli c up [2] @reboot for f in $(zfs list -t snap -o name|grep reboot); do zfs destroy $f;done [3] @reboot zfs snap -r rpool@reboot [1] succeeds, but [2,3] do not. Any ideas why would be gratefully received. Many thanks, Gareth
VPN et demande de redirection de port
Bonsoir, J'éi souscrit au VPN "Private Internet Access" et j'ai eu tenté d'acquérir une IP dédiée. Comme j'ai fait une bêtise je n'ai pas pu en profiter (j'ai perdu le "jeton" et le support n'a pas répondu ! :-( ). Mais j'ai pu activer un port qui m'est dédié avec la commande "piactl set requestportfoward true". L'ip de ceserveur et le port changent évidemment dynamiquement. A partir de là je sèche complètement : je n'arrive pas à utiliser le NAT de ma box pour par exemple pointer un serveur web qui ferait parti de mon LAN... Devrais-je passer par un service DNS ? Quels conseils me donneriez-vous ? Merci -- Pierre ESTREM
Re: SSH resources, specifically on certificates (certificate authentication)
On 7/15/22 05:32, Curt wrote: The question I ask myself preliminarily, before delving further into the matter, is whether certificate-based SSH authentication is appropriate for a home LAN with three users. +1 I decided SSH with publickey authentication and passphrase keys were plenty for my SOHO network. "SSH Mastery" by Lucas is the relevant title: https://mwl.io/nonfiction/tools#ssh That said, I have a Hurricane Electric domain hosting account and I have a Linode VPS with the Unibuiti Networks UniFi Controller (installed by a Linode community "stack script"). Both include LetsEncrypt certificates with automatic renewal for their https service. Hurricane Electric administers all of their services; I just use them. Linode administers their hypervisor. I administer and use the VPS. David
Re: avahi-daemon allow/deny interfaces question
On 7/15/22 00:31, Ram Ramesh wrote: On 7/14/22 09:15, Ram Ramesh wrote: Hi Ramesh, There are numerous reports (mostly old, afaics) of the issue you describe, but with various suggested reasons. I suspect the avahi related part is a consequence rather than a cause - I didn't think avahi was capable of disabling interfaces, the message looks like it's updating a table/list (etc) and "...no longer relevant..." messages appear in my syslog if I deliberately disconnect from wifi. Please can you provide syslog extracts from just before and during a time when this has happened, using: $ sudo cat /var/log/syslog | grep -i -E "avahi|network" (must be capital -E and no spaces around the | inside the speech marks) Is there anything that seems relevant in $ sudo dmesg -T ? Out of interest, did you try running for a while with just the power management tweak? Thanks, Gareth Yes, I believe I did. I did not use /sys/... power/control method. Instead, I kept the network alive by "ping -i 60 ". However, I am not 100% sure of this. So, I will revert some of my changes and get you the relevant logs. Thanks for your continued interested in this matter. Regards Ramesh Mmm... It has been about 10 hours since my reboot after removing "deny-interfaces=$extif," and I have not had the earlier issue of interface disappearing. I will let it run overnight to see. However, I think I wont be able to reproduce the problem. Earlier, I was trying to keep the interface alive with "ping -i 60 xxx" instead of setting "/sys/usb/ power/control" to "on". Not sure if that was not enough and $extif actually powered off in between pings and avahi-daemon was simply reporting this in daemon.log. However, kernel reset the interface status and (may be) dhclient was not written to handle this sort of issue. So, it simply could not work with the interface anymore as it was not initialized to perform DHCP. I wonder why this did not affect ping as it was chugging along without any issues. That is too many wild guesses and I am not sure why the problem does not exists now. I will update again later tomorrow when it has run another 12+ hours. Regards Ramesh No issues still. So, I will call this done for now and report again, if this shows up after a few days. Regards Ramesh
Re: How did I get into dependency hell and how do I get out?
On Fri, Jul 15, 2022 at 12:08:12PM -0400, Dan Ritter wrote: > Ottavio Caruso wrote: > > $ apt-cache policy libglib2.0-0 > > libglib2.0-0: > > Installed: 2.72.1-1 > > Candidate: 2.72.1-1 > > Version table: > > *** 2.72.1-1 100 > > 100 /var/lib/dpkg/status > > 2.66.8-1 500 > > 500 https://deb.debian.org/debian bullseye/main amd64 Packages > > That's a version from later-than-bullseye. Not only that, but it's also a version that's no longer present in any of Ottavio's sources. So, what I'm concluding is that Ottavio did something like this: 1) Decided to try installing some packages from testing or unstable. 2) Added testing or unstable to sources.list. 3) Installed stuff from testing or unstable. At least libglib2.0-0. 4) Removed testing or unstable from sources, thinking that this would let them keep a "stable system except for these few packages". This is what we call a Frankendebian. Once you've installed packages from testing or unstable, there is no going back. There is only going forward. You can continue "upgrading" the rest of the system to testing or unstable (whichever you chose), or you can reinstall everything using only stable sources. (Is that a 100% firm rule? No, of course not. There are certain packages, at certain moments in history, that can be downgraded to a stable version, or removed, or which can peacefully coexist with a stable system, despite being from a different release. But it takes an expert to identify such a unicorn.)
Re: How did I get into dependency hell and how do I get out?
Ottavio Caruso wrote: > Hi, > > > $ uname -a > Linux e130 5.18.0-0.bpo.1-amd64 #1 SMP PREEMPT_DYNAMIC Debian > 5.18.2-1~bpo11+1 (2022-06-14) x86_64 GNU/Linux > $ cat /etc/debian_version > 11.2 Your kernel is from backports, so you have at least some backports installed. What else is in your /etc/apt/sources.list /etc/apt/sources.list.d/* > The following packages have unmet dependencies: > libglib2.0-dev : Depends: libglib2.0-0 (= 2.66.8-1) but 2.72.1-1 is to be > installed > Depends: libglib2.0-bin (= 2.66.8-1) > Depends: libglib2.0-dev-bin (= 2.66.8-1) > E: Unable to correct problems, you have held broken packages. > > > > $ apt-cache policy libglib2.0-0 > libglib2.0-0: > Installed: 2.72.1-1 > Candidate: 2.72.1-1 > Version table: > *** 2.72.1-1 100 > 100 /var/lib/dpkg/status > 2.66.8-1 500 > 500 https://deb.debian.org/debian bullseye/main amd64 Packages That's a version from later-than-bullseye. > > $ apt-get -s -f install libglib2.0-0=2.66.8-1 > NOTE: This is only a simulation! > apt-get needs root privileges for real execution. > Keep also in mind that locking is deactivated, > so don't depend on the relevance to the real current situation! > Reading package lists... Done > Building dependency tree... Done > Reading state information... Done > The following packages were automatically installed and are no longer > required: Ignore this unless you do autoremove... > The following packages will be REMOVED: > caja caja-admin caja-rename caja-seahorse debian-system-adjustments > gstreamer1.0-packagekit gvfs-bin libglib2.0-bin mate-control-center > mate-desktop-environment mate-desktop-environment-core > mate-desktop-environment-extra mate-desktop-environment-extras > mate-dock-applet mate-menu mate-notification-daemon mate-power-manager > packagekit packagekit-tools > The following NEW packages will be installed: > notification-daemon > The following packages will be DOWNGRADED: > libglib2.0-0 > 0 upgraded, 1 newly installed, 1 downgraded, 21 to remove and 55 not These are things that I suspect are also from beyond bullseye. > Oops! How can I downgrade libglib2.0-0 without nuking most of the system? Remove extra repos from your sources; pin backports to on-demand only; apt update; downgrade libglib2.0-0, reinstall the packages from the "will be REMOVED" list. That will probably clear up your "no longer required" list, too. -dsr-
Re: How did I get into dependency hell and how do I get out?
Am Freitag, 15. Juli 2022, 17:47:30 CEST schrieb Ottavio Caruso: I could install libpulse-dev without any issues. However, it depends on libglib2.0-dev. If you need to install libglib2.0, then it might interfere with the system. I checked with aptitude and its ncurses surface (so I can see more), and the system I am running, is debian/stable. Hope this helps. Best Hans > Hi, > > > $ uname -a > Linux e130 5.18.0-0.bpo.1-amd64 #1 SMP PREEMPT_DYNAMIC Debian > 5.18.2-1~bpo11+1 (2022-06-14) x86_64 GNU/Linux > $ cat /etc/debian_version > 11.2 > > > $ apt-get -s install libpulse-dev > NOTE: This is only a simulation! >apt-get needs root privileges for real execution. >Keep also in mind that locking is deactivated, >so don't depend on the relevance to the real current situation! > Reading package lists... Done > Building dependency tree... Done > Reading state information... Done > Some packages could not be installed. This may mean that you have > requested an impossible situation or if you are using the unstable > distribution that some required packages have not yet been created > or been moved out of Incoming. > The following information may help to resolve the situation: > > The following packages have unmet dependencies: > libglib2.0-dev : Depends: libglib2.0-0 (= 2.66.8-1) but 2.72.1-1 is to > be installed >Depends: libglib2.0-bin (= 2.66.8-1) >Depends: libglib2.0-dev-bin (= 2.66.8-1) > E: Unable to correct problems, you have held broken packages. > > > > $ apt-cache policy libglib2.0-0 > libglib2.0-0: >Installed: 2.72.1-1 >Candidate: 2.72.1-1 >Version table: > *** 2.72.1-1 100 > 100 /var/lib/dpkg/status > 2.66.8-1 500 > 500 https://deb.debian.org/debian bullseye/main amd64 Packages > > $ apt-get -s -f install libglib2.0-0=2.66.8-1 > NOTE: This is only a simulation! >apt-get needs root privileges for real execution. >Keep also in mind that locking is deactivated, >so don't depend on the relevance to the real current situation! > Reading package lists... Done > Building dependency tree... Done > Reading state information... Done > The following packages were automatically installed and are no longer > required: >apache2-bin bamfdaemon caja-common caja-eiciel caja-extensions-common >caja-gtkhash caja-image-converter caja-open-terminal caja-sendto >caja-wallpaper dconf-editor engrampa engrampa-common eom eom-common >gir1.2-bamf-3 gir1.2-caja-2.0 gir1.2-eom-1.0 gir1.2-matepanelapplet-4.0 >gir1.2-pluma-1.0 gnome-system-tools gtkhash libapache2-mod-dnssd libapr1 >libaprutil1 libaprutil1-dbd-sqlite3 libaprutil1-ldap libb2-1 libbamf3-2 >libcpupower1 libcryptui0a libffi8 liblua5.3-0 > libmate-sensors-applet-plugin0 >libmate-slab0 libmate-window-settings1 liboobs-1-5 mate-applet-brisk-menu > mate-applets mate-applets-common mate-backgrounds mate-calc > mate-calc-common >mate-control-center-common mate-indicator-applet >mate-indicator-applet-common mate-media mate-media-common >mate-notification-daemon-common mate-sensors-applet >mate-sensors-applet-common mate-system-monitor mate-system-monitor-common > mate-themes mate-tweak mate-user-share mate-user-share-common pluma > pluma-common python-caja-common python3-caja seahorse-daemon > Use 'apt autoremove' to remove them. > The following additional packages will be installed: >notification-daemon > The following packages will be REMOVED: >caja caja-admin caja-rename caja-seahorse debian-system-adjustments >gstreamer1.0-packagekit gvfs-bin libglib2.0-bin mate-control-center >mate-desktop-environment mate-desktop-environment-core >mate-desktop-environment-extra mate-desktop-environment-extras >mate-dock-applet mate-menu mate-notification-daemon mate-power-manager >packagekit packagekit-tools > The following NEW packages will be installed: >notification-daemon > The following packages will be DOWNGRADED: >libglib2.0-0 > 0 upgraded, 1 newly installed, 1 downgraded, 21 to remove and 55 not > upgraded. > Remv mate-desktop-environment-extra [1.24.0+4] > Remv mate-desktop-environment-extras [1.24.0+4] > Remv mate-desktop-environment [1.24.0+4] > Remv mate-desktop-environment-core [1.24.0+4] > Remv caja-seahorse [1.18.5-1] > Remv caja [1.24.0-1] [caja-admin:amd64 caja-rename:amd64 ] > Remv caja-admin [0.0.3-1] [caja-rename:amd64 ] > Remv caja-rename [20.1.26-1] > Remv debian-system-adjustments [2022.03.09.1-elsie] > Remv gstreamer1.0-packagekit [1.2.2-2] > Remv gvfs-bin [1.46.2-1] > Remv packagekit-tools [1.2.2-2] > Remv packagekit [1.2.2-2] > Remv mate-power-manager [1.24.2-1] > Inst notification-daemon (3.20.0-4 Debian:11.4/stable [amd64]) > Remv mate-notification-daemon [1.24.1-1] > Remv libglib2.0-bin [2.72.1-1] [mate-control-center:amd64 > mate-dock-applet:amd64 mate-menu:amd64 ] > Remv mate-control-center [1.24.1-1] [mate-dock-applet:amd64 >
Re: SSH resources, specifically on certificates (certificate authentication)
On Friday, July 15, 2022 08:49:01 AM to...@tuxteam.de wrote: > On Fri, Jul 15, 2022 at 12:32:35PM -, Curt wrote: > > The question I ask myself preliminarily, before delving further into > > the matter, is whether certificate-based SSH authentication is > > appropriate for a home LAN with three users. > > Definitely not. Getting ahead of myself (because my next question / source of puzzlement will get into that), I will say "maybe". -- rhk If you reply: snip, snip, and snip again; leave attributions; avoid top posting; and keep it "on list". (Oxford comma included at no charge.) If you change topics, change the Subject: line. A picture is worth a thousand words -- divide by 10 for each minute of video (or audio) or create a transcript and edit it to 10% of the original.
3 more surprising (to me) things about ssh (was: Re: SSH resources, specifically on certificates (certificate authentication))
Thanks for the response, and to dsr as well. I won't really ask a question here, but I will make some comments -- not sure how / where to fit them in -- will try to intersperse below. Or maybe I'll just top post them here: Surprise 2: Another surprising thing to me (with the evolution of the surprise) -- my initial objective (until I came across certificates) was to learn about public key(pair) authentication with the intent to allow passwordless ssh between computers on my LAN. It was in the course of digging into that that I learned about things like the Diffie-Hellman key exchange and the use of a symmetric encryption algorithm for the exchange of bulk / payload data. Then I got to thinking that if ssh uses a symmetric algorithm for exchange of bulk data in (well, after) public key authentication, it probably does the same (that is, use symmetric encryption (with a shared secret encryption key)) after any other method of authentication, and that it probably also uses Diffie- Hellman key exchange (maybe with different inputs) in those other methods of authentication. (I'm assuming this is also the case for gssapi (one variation being Kerberos) authentication, in which I have absolutely no interest, at least at present.) Your post makes me much more confident that is the case. Surprise 3: Maybe it should not have been a surprise, but ssh turns out to be much more complex and flexible than I expected -- I've been trying to think of the best word to describe it and have been thinking of it as sort of a meta-protocol instead of just a protocol. I say that for a number of reasons (some that don't really justify the use of the prefix meta, but) * Variations of ssh, either within one implementation (e.g., openssh) or between implementations of ssh (by other vendors) can use a wide variety of actual encryption protocols (e.g., AES-128, AES-192, AES-256, RSA, ecDSA, ed25???. and a variety of others. And, next week, when somebody implements a new variation of ssh, they might use other protocols / algorithms. (Of course, some backward compatibility and handshaking is required so different implementations can talk to each other (to the extent possible) (one example is the openssh versions 1.0, 2.00, and 1.99, which I won't explain atm). * I mentioned it already in the previous bullet, but the other point I was going to make is that other vendors / implementors can implement variations of ssh which can use different encryption protocols (but again, need means of backward compatitbility / handshaking or such for inter-operability between implementations). Surprise 4: Even Diffie-Hellman is (or can be) more complex than I recall it being described in the Wikipedia article (but I may have forgotten some of what I read there). For example, in the variation used in public key(pair) authentication, in addition to the expected user and server public keypairs, there are things like a salt, and multiple iterations of some algorithm / process, and even a(n optional?) second set of public keypairs (ephemeral public keypairs, used once and thrown away, iiuc). This (the additional ephemeral keypairs) might be only in the variation of Diffie-Hellman known as triple Diffie-Hellman (3-DH).) (In at least one source I found, 3-DH is the thing that mentioned as providing forward security, but I think the bigger point is, as dsr pointed out, the generation of new session keys for each new "session" (which, afaict, can be done with things like a new salt (which I think is a random number) or a different number of iterations of some process (and that number of iterations might also be a random number), i.e., 3-DH is not necessarily required for forward security). And to elaborate a little (without me knowing the details) even in ssh (simple) password authentication, some variation of Diffie-Hellman (or Diffie- Hellman using different inputs -- maybe using the "host" public keypairs for both the client and server machines instead of using the server public keypair and a user public keypair (as in public key authenttication) with the user password thrown into the mix somewhere. I don't care too much about the actual details, it is enough for me (for now) to know (or at least think I know) that even the process for (simple) password authentication is fairly complex, secure(, and, (incidently) almost certainly uses some variation of Diffie-Hellman). (Oh, I could also mention that sometimes variations of Diffie-Hellman are referred to as being of different groups, some being more secure than others. I won't get into that at all -- I mean, I don't think I need to know any details. Oh, and sometimes, iiuc, that is referred to as Diffie-Hellman Group Exchange instead of Diffie-Hellman Key Exchange, which seems like at least a little bit of a misnomer to me.) Comments / clarifications / corrections welcome. Maybe my next post will pose the big question I
Re: SSH resources, specifically on certificates (certificate authentication)
On Fri, Jul 15, 2022 at 12:32:35PM -, Curt wrote: > On 2022-07-14, Dan Ritter wrote: > > > > If you've got a very large organization, you may want to support > > the infrastructure to generate new SSH certs for people daily, > > with expiration dates of 24 hours. Then you need to make sure > > that mechanism is working perfectly and has appropriate > > redundancy, so that you don't accidentally lock out the whole > > organization tomorrow. > > The question I ask myself preliminarily, before delving further into > the matter, is whether certificate-based SSH authentication is > appropriate for a home LAN with three users. Definitely not. OTOH -- would you like those managing your thousand-plus hosts and tens of thousands of IDs to learn "on the living organism"? Cheers -- t signature.asc Description: PGP signature
Re: SSH resources, specifically on certificates (certificate authentication)
On 2022-07-14, Dan Ritter wrote: > > If you've got a very large organization, you may want to support > the infrastructure to generate new SSH certs for people daily, > with expiration dates of 24 hours. Then you need to make sure > that mechanism is working perfectly and has appropriate > redundancy, so that you don't accidentally lock out the whole > organization tomorrow. The question I ask myself preliminarily, before delving further into the matter, is whether certificate-based SSH authentication is appropriate for a home LAN with three users. > -dsr- > >
Re: SSH resources, specifically on certificates (certificate authentication)
to...@tuxteam.de wrote: > See, asymmetrical encryption (e.g. RSA, Elliptic Curve) is far too expensive > to use on bulk data, so it typically is used to encrypt a key (generated on > the spot), called "session key". The latter is used to symmetrically (e.g. > AES) encrypt the bulk data. You use that style typically in the deferred > case. > > Perhaps there's even a security advantage in that, since the session key, > as being used for more data gives a potential cryptanalist more material > to chew on: then just the session key would be compromised, and you throw > that away for the next round. I don't know. The systems that throw it away and redo the DH exchange frequently are said to have "perfect forward security": an attacker who gains one session key doesn't get the next session key. -dsr-
