Re: ideas 2

[Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>]

: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 
:-1" command.
:
:/usr/src/crypto/openssh/sshd_config
:
:-       #Protocol 2,1
:+       Protocol 2
:
:
:/usr/src/crypto/openssh/ssh_config
:
:-       #   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.
:
:/usr/src/crypto/openssh/sshd_config
:
:-       #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.
:
:src/etc/rc.d/sshd
:
:-	/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.
:
:/usr/src/crypto/openssh/version.h
:
:-	#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 
:you.
 
     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 !
:
:	Ed

    Keep going!

					-Matt
					Matthew Dillon 
					<dillon@xxxxxxxxxxxxx>