I disagree, being that there's a command and associated config entry to backup config to a remote ssh server. This config option requires key based authentication. It would seem that the backup function puts this in- scope as a bug. Everyone who uses the remote configuration backup to an external ssh box is affected.

It is not a bug but a feature request.
Only keys in /etc/ssh are copied. The keys in the home user directory were never copied.

PR for 1.5:
https://github.com/vyos/vyos-1x/pull/3372
Combined PRs for backport to 1.4 of T5839, T5660, T6276 pending.

@Viacheslav can you create root task maybe and we consolidate related tasks under it

@Viacheslav @c-po can you guys review this PR

PR: https://github.com/vyos/vyos-1x/pull/3371

This would be the key's themselves and known_hosts, stored in the non-root user folder. The prompt during upgrade seems to indicate it'll copy them over. However, whenever I upgrade, I have to manually perform ssh-keygen and ssh-copy-id again for my backup server to allow my config backup to work.

we talking about athorized_keys or known_hosts?

You are right - I wonder why it didn't work when I tested it back then. (Most likely I forgot to write "comment")

I explored implementing this feature, turns out it is already available.
Correct syntax for commit messages is commit comment "example message".

Probably related: https://vyos.dev/T5388

Your account had associated activities so as per GDPR, it was anonymized instead

Your account had associated activities so as per GDPR, it was anonymized instead

Tested as working in: VyOS 1.5-rolling-202404250020

PR: https://github.com/vyos/vyos-1x/pull/3369

PR https://github.com/vyos/vyos-1x/pull/3368

vyos@r4# compare 
[interfaces]
+ wireless wlan0 {
+     address "192.0.2.5/32"
+ }

PR: https://github.com/vyos/vyos-1x/pull/3367

It is impossible to set several addresses, but it is possible 0.0.0.0
Limits of the accel-ppp

looks good for VyOS 1.5-rolling-202404260019 and VyOS 1.4-stable-202404120309

vyos@r4# set system config-management commit-archive location scp://vyos:[email protected]/tmp/
vyos@r4# 
[edit]
vyos@r4# commit
Archiving config...
  scp://192.168.255.11/tmp/ Unable to upload "scp://vyos:[email protected]/tmp//config.boot-r4.vyos.local.20240426_153518": [Errno 101] Network is unreachable
run-parts: /etc/commit/post-hooks.d/02vyos-commit-archive exited with return code 1
[edit]
vyos@r4#

It looks working on VyOS 1.5-rolling-202404260019

set system domain-name 'vyos.local'
set system host-name 'r4'
set system static-host-mapping host-name r4.vyos.local inet '100.64.0.14'

So if all packages needed are in fact the vyos-build/packages then this should be fairly simple to build and make your own APT repo off of.

Perhaps those changes should be within the firewall context?

Hi Giggum,
our previous solution was IPv4 only and not so nice integrated in VyOS,
therefore there are several reasons why a rework is a good idea.

In T6258#185013, @Apachez wrote:

Im thinking since sysctl can be changed after the system have completed its boot shouldnt the "system sysctl" be runned among the last tasks according to "/usr/libexec/vyos/priority.py", which would also fix this issue ?

@adestis did your previous solution account for non-IP address characters in a given blocklist? For example the https://www.spamhaus.org/drop/dropv6.txt list has a bunch of stuff that would need to be ignored.

Im thinking since sysctl can be changed after the system have completed its boot shouldnt the "system sysctl" be runned among the last tasks according to "/usr/libexec/vyos/priority.py", which would also fix this issue ?

If all of this would be done by the build script (download sources, apply patches, build binary packages and copy them to a local filesystem) there would be no problem.
I can't even see the list of packages in that 403 Forbidden repo - all of it blocked completely, not just access to binary packages.

Good.
So, all code is in github.
you need to spend bit of time and learn how to build packages and make them into repo
after you point vyos-build to that repo and good to go
it's time consuming, but once you have set it up, after it will not require that much time

@Apachez, there is no easy way to fix anything related to sysctl, until one component depends on another.
Especially, for example, if we have to deal with "dynamic" interfaces.
Globally, this task is still open and could contain subtasks.
Thanks!

In T6266#184977, @sarthurdev wrote:

Possibly would make sense for CLI to fall under firewall global-options?

Note that "base_reachable_time_ms" is still valid while "base_reachable_time" is obsolete.

OK, so where can I find the source (without the artwork) with the necessary patches and working build scripts (to build from the LTS, not rolling branch - just to be clear)? No problem to use my own CPU cycles and bandwidth and disk space, I can wait longer for the build to finish, sometimes (on sunny days) I even have some free electricity :) - in fact I would even prefer to build the binaries myself (of any packages not directly copied from Debian) rather than trust an external repo. And no problem, you've just got the 868th star from me, I simply didn't know this is something that matters. I have never distributed the LTS images to third parties, just using them internally. Yes, for some small scale production use (single-person business, running a very small local ISP for a few hundreds of customers) as a BGP router and PPPoE server (the latter replacing MikroTik because of their unfinished IPv6 support), not big enough to be able to afford a subscription.