DragonFly kernel List (threaded) for 2004-07
Re: ideas 2
:2) By default ssh and sshd can automatically switch to the obsolete SSH
:protocol v1 if one of the two doesn't support v2. I'm asking to remove this
:automatic process, letting the user manually choose obsolete v1 using "ssh
:- #Protocol 2,1
:+ Protocol 2
:- # Protocol 2,1
:+ Protocol 2
I'm kinda on the fence on changing this. I've actually done this on
personal machines before but it always creates problems with programs
like 'scp' which do not have a '-1' option.
:3) Obsolete SSH protocol v1 key is only 768 bits long and it's regenerated
:every hour. Even if I suggest not to use v1, I think it can be better to
:increase the keysize to 1024.
:- #ServerKeyBits 768
:+ ServerKeyBits 1024
It is better not to mess with the older protocols. A v1 ssh client
might not be able to handle a 1024 bit key. In particular, before
the patent ran out there were a lot of clients that could not legally
handle 1024 bit keys. For people who still need to accept v1
connections, this could throw a wrench in the works.
:4) Given the fact the most people follow a method of jumping across release,
:instead of updating from scratch everytime, SSH v2 server keys can stay the
:same for more than one year. Even if it's not already known a method to
:decrypt a public key, I'm asking to make it more difficult incrementing the
:default keysize to 2048.
:- /usr/bin/ssh-keygen -t dsa -f /etc/ssh/ssh_host_dsa_key -N ''
:+ /usr/bin/ssh-keygen -t dsa -b 2048 -f /etc/ssh/ssh_host_dsa_key -N ''
:- /usr/bin/ssh-keygen -t rsa -f /etc/ssh/ssh_host_rsa_key -N ''
:+ /usr/bin/ssh-keygen -t rsa -b 2048 -f /etc/ssh/ssh_host_rsa_key -N ''
Again, I'm worried about compatibility.
:5) I would suggest to modify the current banner of sshd so that it would seems
:a clean installation of OpenSSH-portable. Using a special banner is a good
:way to let everyone know if you're vulnerable to some attacks. Like happened
:with Apache worms that were looking for particular versions/platform.
:- #define SSH_VERSION_ADDENDUM "DragonFly-20030916B"
:+ #define SSH_VERSION_ADDENDUM ""
A lot of people did this sort of thing with sendmail when sendmail
was going through a number of security issues a few years ago, but
it didn't stop the attacks. Also, there are other ways to detect
the ssh version number. I would rather not change this.
:6) DF is a complete OS and so you can have your own needs. This should let you
:ask for commits on external projects like OpenSSH-portable and OpenSSL. What
:I'm suggesting is to import their code as they release it and send them any
:patch so that they'll be the real maintainers of the code. This can be easy
:if you think at #ifdef and ./configure --host=DragonFlyBSD. This should save
:DF developers time and keep original authors working on their projects for
Well, we aren't going to do base system builds with ./configure.
./configure is always a moving target and basing a build on it is a
recipe for disaster. We have a pretty good system for handling
third party software in the base system that we've been slowly
moving towards and I think we are going to stick with it.
:7) On the IRC channel I was talking with someone about BIND removal.
:Obviously I would be happy to see removed a DNS _server_ from the base system,
:because very few people needs it and who want to install a DNS server would
:probably prefer another one (djbdns ?).
:I know that someone was looking at the problem of the resolving library and I
:hope this could be addressed with a small effort.
We aren't going to remove major software from the base system until we
have a new packaging system to move it into.
The resolver library built into libc is currently independant (I'm fairly
sure) of the bind dist in the base system.
:8) Please make /tmp cleaning at boot time a default setting. It's a good thing
:for privacy and security.
Well cleaning out /tmp at boot is a bad idea in general because while
the files are meant to be temporary, the last thing you ever want is for
a system reboot to blow them away. One could institute removal based
on a file age, and many do, but I'm not sure we should do it by default.
:This is not the end... I've some other unsaid ideas !