For many cases, the default configuration file is provided by a package directly. In such cases, you can extract the specific file from the package, thus easily recovering the file.
To check if a package provides the file, run
dpkg -S on the full path of the file. For example:
$ dpkg -S /etc/ssh/sshd_config /etc/ssh/ssh_config /etc/sudoers
dpkg-query: no path found matching pattern /etc/ssh/sshd_config
Provided by a package
As we can see,
/etc/ssh/sshd_config is not directly provided by any package, but the other two are provided by
sudo respectively. So, if you wished to recover
/etc/ssh/ssh_config, first get the package:
apt-get download openssh-client
Now, you can either extract the file directly to its intended location, or to its intended location relative to the current directory instead of
/, if you wished to compare and contrast, or manually merge them or something. For the former:
dpkg-deb --fsys-tarfile openssh-client_*.deb | sudo tar x ./etc/ssh/ssh_config -C /
-C / tells
tar to extract after changing to
/, which means the target file will get replaced. If you remove it,
tar will extract to the current directory, meaning
./etc/ssh/ssh_config will exist in your current directory.
If for some reason
sudo doesn't work, use
pkexec instead. If
pkexec doesn't work either, reboot to recovery mode, mount
rw. If that doesn't work...
Created by a package
/etc/ssh/sshd_config? It doesn't seem to be provided by any package, so how did it appear?
In this case (and in many other such cases, another example being
/etc/modules), the file was created using a package maintainer script while installation. This is often done when the configuration file needs to be changed due to user responses to queries. OpenSSH, for example, asks if
PermitRootLogin should be changed to
no, in newer versions, among other things.
To identify such cases, try greping through the maintainer scripts. Typically you would only need to look
postinst, but if you don't have any luck with
preinst as well:
grep -l /etc/ssh/sshd_config /var/lib/dpkg/info/*.postinst
In this case, we're in luck:
$ grep /etc/ssh/sshd_config /var/lib/dpkg/info/*.postinst -l
Only one file matched, and as luck would have it, it contains code to create a default configuration file:
cat <<EOF > /etc/ssh/sshd_config
# Package generated configuration file
# See the sshd_config(5) manpage for details
# What ports, IPs and protocols we listen for
# Use these options to restrict which interfaces/protocols sshd will bind to
# HostKeys for protocol version 2
#Privilege Separation is turned on for security
# Lifetime and size of ephemeral version 1 server key
# Don't read the user's ~/.rhosts and ~/.shosts files
# For this to work you will also need host keys in /etc/ssh_known_hosts
# similar for protocol version 2
# Uncomment if you don't trust ~/.ssh/known_hosts for RhostsRSAAuthentication
# To enable empty passwords, change to yes (NOT RECOMMENDED)
# Change to yes to enable challenge-response passwords (beware issues with
# some PAM modules and threads)
# Change to no to disable tunnelled clear text passwords
# Kerberos options
# GSSAPI options
# 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'.
Typically, this is what you would see (another example,
cat > /path/to/the/file <<EOF
# default contents
So, you can look for this code and get the contents from the script directly.
No such script? You can still try poking through the filelists of related packages to see if anything hits, but at this point, I see no easily generalizable method (short of reinstallation on transient environments, like a chroot or a VM or a live USB).
In the long run, keep your configuration under version control. Any VCS worth its salt can save the day here, and the
etckeeper utility considerably simplifies the task of keeping
/etc in a VCS.