1 files changed, 69 insertions, 0 deletions

diff --git a/debian/openssh-server.templates.master b/debian/openssh-server.templates.master
new file mode 100644
index 000000000..3f7f017fd
--- /dev/null
+++ b/debian/openssh-server.templates.master
@@ -0,0 +1,69 @@
+Template: ssh/new_config
+Type: boolean
+Default: true
+_Description: Generate new configuration file
+ This version of OpenSSH has a considerably changed configuration file from
+ the version shipped in Debian 'Potato', which you appear to be upgrading
+ from. I can now generate you a new configuration file
+ (/etc/ssh/sshd.config), which will work with the new server version, but
+ will not contain any customisations you made with the old version.
+ .
+ Please note that this new configuration file will set the value of
+ 'PermitRootLogin' to yes (meaning that anyone knowing the root password
+ can ssh directly in as root). It is the opinion of the maintainer that
+ this is the correct default (see README.Debian for more details), but you
+ can always edit sshd_config and set it to no if you wish.
+ .
+ It is strongly recommended that you let me generate a new configuration
+ file for you.
+
+Template: ssh/use_old_init_script
+Type: boolean
+Default: false
+_Description: Do you want to continue (and risk killing active ssh sessions)?
+ The version of /etc/init.d/ssh that you have installed, is likely to kill
+ all running sshd instances.  If you are doing this upgrade via an ssh
+ session, that would be a Bad Thing(tm).
+ .
+ You can fix this by adding "--pidfile /var/run/sshd.pid" to the
+ start-stop-daemon line in the stop section of the file.
+
+Template: ssh/insecure_rshd
+Type: note
+_Description: Warning: rsh-server is installed --- probably not a good idea
+ having rsh-server installed undermines the security that you were probably
+ wanting to obtain by installing ssh.  I'd advise you to remove that
+ package.
+
+Template: ssh/insecure_telnetd
+Type: note
+_Description: Warning: telnetd is installed --- probably not a good idea
+ I'd advise you to either remove the telnetd package (if you don't actually
+ need to offer telnet access) or install telnetd-ssl so that there is at
+ least some chance that telnet sessions will not be sending unencrypted
+ login/password and session information over the network.
+
+Template: ssh/encrypted_host_key_but_no_keygen
+Type: note
+_Description: Warning: you must create a new host key
+ There is an old /etc/ssh/ssh_host_key, which is IDEA encrypted. OpenSSH
+ can not handle this host key file, and I can't find the ssh-keygen utility
+ from the old (non-free) SSH installation.
+ .
+ You will need to generate a new host key.
+
+Template: ssh/disable_cr_auth
+Type: boolean
+Default: false
+_Description: Disable challenge-response authentication?
+ Password authentication appears to be disabled in your current OpenSSH
+ server configuration. In order to prevent users from logging in using
+ passwords (perhaps using only public key authentication instead) with
+ recent versions of OpenSSH, you must disable challenge-response
+ authentication, or else ensure that your PAM configuration does not allow
+ Unix password file authentication.
+ .
+ If you disable challenge-response authentication, then users will not be
+ able to log in using passwords. If you leave it enabled (the default
+ answer), then the 'PasswordAuthentication no' option will have no useful
+ effect unless you also adjust your PAM configuration in /etc/pam.d/ssh.