Update and locally modified files

H

hannsmattes

Hi,

running freebsd-update fetch install, I'm getting

Code: 
The following files are affected by updates. No changes have
been downloaded, however, because the files have been modified
locally:
/etc/ssh/sshd_config
Pressing "q" I'm told that there are no updates needed and available. If I move the modified config (Yes, I've enabled UseBlacklist), the freebsd-update is running quietly.

Though it doesn't seem to be much of a problem, I'd like to know the reason for the behaviour, that i haven't observed before.

Regards Hanns
 
Last edited by a moderator:
So if we just continue on with the update and it leaves our /etc/ssh/sshd_config intact, are we still vulnerable to the security hole we're trying to patch?

I don't mind manually changing the config file if I know what to do.
 
Cool, thank you very much!

I like the way the Apache package handles this situation. If there are no substantial differences during an update, it will just overwrite a config file. If there are differences, it will drop a *.sample file in the same directory so you can see what changed.

At any rate, thanks again for calming my fears.
 
Nevertheless - I don't get it. Why does freebsd-update complain 'bout an obviously irrelevant change - why does ist complain at all? config-Files are made to be modified.

clueless Hanns
 
Hi!
I also have this problem. My file is sshd_config eq. the source file. The patch didn't help.
Actually, the file did not differ from the original one except for the date in the commented-out parameter.

???? :(
 
I had the same issue, ignored it for a while, then went and looked for an "original" file.
I found /usr/src/crypto/openssh/sshd_config

I ran diff on the two files too, and there were only differences in the comments/dates and some uncommented lines at the end which apparently are not needed anyway now, in my case.
ie
Code: 
X11Forwarding yes
X11UseLocalHost yes
X11DisplayOffset 10

I copied the one from /etc/ssh/sshd_config to /etc/ssh/sshd_config.original
Then I copied the one from /usr/src to /etc/ssh and tested that everything still worked as expected.
It did, so I'm happy. If you try it, do backup the original file, just in case and make sure you do it at the physical console. You really don't want ssh going pear-shaped if on a remote connection :)

You may need to install /usr/src if you don't have those files or at least get the archive and extract the relevant file.
 
I have just run into this with my 1st fresh install of freebsd 13.2 (others have been upgrades).

The only change I made to /etc/ssh/ssd_config was
---#PermitRootLogin no
+++PermitRootLogin yes
...in order to allow passwordless ssh access to the server with my normal login credential.

just re-instating the changed line allows
Code: 
freebsd-update fetch
to run without a a warning, and
Code: 
freebsd-update install
to actually update.

Of course I have to log on as a non-root user, become root, and re-edit /etc/ssh/sshd_config to allow myself passwordless logon as root with an ssh key.

This seems sub-optimal. What do I need to do to allow updates to proceed without the 'song and dance'?
 
bisi said:
This seems sub-optimal. What do I need to do to allow updates to proceed without the 'song and dance'?
Click to expand...
There have been a few discussions specifically about sshd_config, I think this is the first time in a long time the file actually has been changed.
I think it will be addressed in future updates, but a work around is keep a copy of the unmodified file, call it something like sshd_config.bak, modify the file as needed, then simply copy your modified version, then copy the original back into place in the future before running freebsd-update.
 
mer said:
There have been a few discussions specifically about sshd_config, I think this is the first time in a long time the file actually has been changed.
I think it will be addressed in future updates, but a work around is keep a copy of the unmodified file, call it something like sshd_config.bak, modify the file as needed, then simply copy your modified version, then copy the original back into place in the future before running freebsd-update.
Click to expand...
Exactly the workaround I settled on. Can confirm that if you remember to replace your bogus (unmodified) sshd_config file before you reboot with the one you really want (allowing root login with ssh key), then you don't have to rely on the secondary, non-root-user ID, that is a member of the wheel group in order to log on to the remote system.
 
  • Like
Reactions: mer
You must log in or register to reply here.
Back
Top