Re: Request: remove ssh1 fallback
Thus spake Lucky Green [EMAIL PROTECTED]: ... remove ssh1 fallback from the default ... David Schultz [EMAIL PROTECTED] wrote: Removing SSH 1 ... is going to break compatibility ... Tim Kientzle [EMAIL PROTECTED]: POLA: before breaking compatibility, warn people. ... Warning: switching to less-secure SSH1 protocol David Schultz wrote: I think you're missing the point. Warnings are fine, but there is little good reason to disable SSH1 entirely. _I_ was actually arguing against disabling SSH1. I'm on your side. If one end of the connection is forced to fall back to SSH1, it's almost certainly because the user at the other end _doesn't_have_any_other_option_. I don't really agree with this point. SSH2 and OpenSSH compile most everywhere now. I would argue that if one end is forced to fall back, it's because the admins of that system either don't know about SSH1's problems or don't believe those problems merit upgrades. I know SSH1 is insecure, and therefore I don't use it. Unfortunately, not everyone is so knowledgable. A brief warning would help spread the news and (hopefully) help accelerate the transition to SSH2. ... you'd better have a better reason to do it than ``it lets people do things that are insecure.'' So do rsh, telnet, hosts.equiv, vipw, et al. Yes, although telnet and rsh are both disabled in default FreeBSD installations in 4.7 at least and probably earlier. So far, I've not heard a lot of complaints. (But there have been several years now of pounding the 'telnet is evil' mantra into people's heads.) Tim Kientzle To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Request: remove ssh1 fallback
Thus spake Tim Kientzle [EMAIL PROTECTED]: Thus spake Lucky Green [EMAIL PROTECTED]: ... remove ssh1 fallback from the default ... David Schultz [EMAIL PROTECTED] wrote: Removing SSH 1 ... is going to break compatibility ... POLA: before breaking compatibility, warn people. It's simple to modify the ssh client so that it emits a warning message before downgrading Warning: switching to less-secure SSH1 protocol On the server side, you could certainly log a warning; there may be a way to notify the connecting user as well. The logged warning could even include a very brief reference to the setting required to disable SSH1 entirely. I think you're missing the point. Warnings are fine, but there is little good reason to disable SSH1 entirely. If one end of the connection is forced to fall back to SSH1, it's almost certainly because the user at the other end _doesn't_have_any_other_option_. You're proposing to kick legitimate users off of everyone's FreeBSD boxen because you know better than they do about security. I know SSH1 is insecure, and therefore I don't use it. But I'm not about to unleash a surprise on everyone who uses a machine without SSH2 just so I can hammer the idea into their heads. Breaking POLA isn't a sin, but you'd better have a better reason to do it than ``it lets people do things that are insecure.'' So do rsh, telnet, hosts.equiv, vipw, et al. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Request: remove ssh1 fallback
Thus spake Lucky Green [EMAIL PROTECTED]: I therefore believe that the 5.0 release represents a perfect opportunity to remove ssh1 fallback from the default distribution of FreeBSD and hope the FreeBSD team will consider this change. Making SSH 2 the default is one thing. Removing SSH 1 as a fallback altogether is going to break compatibility with other systems like you'd never believe. For example, I regularly need to SSH into Solaris boxen running SSH 1. These machines aren't secure anyway, and since there's nothing I can do about it, I don't want any surprises when I upgrade. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Request: remove ssh1 fallback
Thus spake Lucky Green [EMAIL PROTECTED]: I therefore believe that the 5.0 release represents a perfect opportunity to remove ssh1 fallback from the default distribution of FreeBSD and hope the FreeBSD team will consider this change. Making SSH 2 the default is one thing. Removing SSH 1 as a fallback altogether is going to break compatibility with other systems like you'd never believe. For example, I regularly need to SSH into Solaris boxen running SSH 1. These machines aren't secure anyway, and since there's nothing I can do about it, I don't want any surprises when I upgrade. I think he was suggesting removing it from the sshd server, not the client. You can always specify the protocol on the command line with the client even if it didn't fall back... and again he's suggesting it for the default configuration, you can always change the configuration. I'm not necessarily for this change I just want to be sure what change is being suggested :) -Steve To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Request: remove ssh1 fallback
Thus spake Steven Ames [EMAIL PROTECTED]: Making SSH 2 the default is one thing. Removing SSH 1 as a fallback altogether is going to break compatibility with other systems like you'd never believe. For example, I regularly need to SSH into Solaris boxen running SSH 1. These machines aren't secure anyway, and since there's nothing I can do about it, I don't want any surprises when I upgrade. I think he was suggesting removing it from the sshd server, not the client. You can always specify the protocol on the command line with the client even if it didn't fall back... and again he's suggesting it for the default configuration, you can always change the configuration. I'm not necessarily for this change I just want to be sure what change is being suggested :) In either case, you break compatibility. Say I wanted to SSH from those Solaris boxen to my home machine, for example. (I don't, but that's not the point.) If my SSH server didn't have the SSH 1 fallback, there's nothing I could do from the command line to allow me to log in. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Request: remove ssh1 fallback
On Wed 23 Oct, David Schultz wrote: In either case, you break compatibility. Say I wanted to SSH from those Solaris boxen to my home machine, for example. (I don't, but that's not the point.) If my SSH server didn't have the SSH 1 fallback, there's nothing I could do from the command line to allow me to log in. I think he means setting the default configuration to disable the fallback; so you would be able to configure it manually to allow SSH1, but the default install would disallow it. Andrew To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Request: remove ssh1 fallback
Steven Ames wrote: Thus spake Lucky Green [EMAIL PROTECTED]: I therefore believe that the 5.0 release represents a perfect opportunity to remove ssh1 fallback from the default distribution of FreeBSD and hope the FreeBSD team will consider this change. Making SSH 2 the default is one thing. Removing SSH 1 as a fallback altogether is going to break compatibility with other systems like you'd never believe. For example, I regularly need to SSH into Solaris boxen running SSH 1. These machines aren't secure anyway, and since there's nothing I can do about it, I don't want any surprises when I upgrade. I think he was suggesting removing it from the sshd server, not the client. You can always specify the protocol on the command line with the client even if it didn't fall back... and again he's suggesting it for the default configuration, you can always change the configuration. I'm not necessarily for this change I just want to be sure what change is being suggested :) What if the client machine is a SSH1 Solaris (or Windows) box going into a FreeBSD rackmount? It should *at least* be available as a command line option to the daemon; since some boxes *don't have* consoles at all, it would have the same effect of turning them into a doorstop to disable this flag, once it's available, by default (right now, it just provides both). The problem with interoperability is that it's not unidirectional. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Request: remove ssh1 fallback
Andrew Mishchenko wrote: On Wed 23 Oct, David Schultz wrote: In either case, you break compatibility. Say I wanted to SSH from those Solaris boxen to my home machine, for example. (I don't, but that's not the point.) If my SSH server didn't have the SSH 1 fallback, there's nothing I could do from the command line to allow me to log in. I think he means setting the default configuration to disable the fallback; so you would be able to configure it manually to allow SSH1, but the default install would disallow it. So I upgrade, and I can't get back into the box from my SSH1 client machine to reenable SSH1 services on the box. Genius! 8-) 8-). -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
RE: Request: remove ssh1 fallback
David wrote: Thus spake Steven Ames [EMAIL PROTECTED]: Making SSH 2 the default is one thing. Removing SSH 1 as a fallback altogether is going to break compatibility with other systems like you'd never believe. For example, I regularly need to SSH into Solaris boxen running SSH 1. These machines aren't secure anyway, and since there's nothing I can do about it, I don't want any surprises when I upgrade. I think he was suggesting removing it from the sshd server, not the client. You can always specify the protocol on the command line with the client even if it didn't fall back... and again he's suggesting it for the default configuration, you can always change the configuration. I'm not necessarily for this change I just want to be sure what change is being suggested :) In either case, you break compatibility. Say I wanted to SSH from those Solaris boxen to my home machine, for example. (I don't, but that's not the point.) If my SSH server didn't have the SSH 1 fallback, there's nothing I could do from the command line to allow me to log in. My apologies if I my request was unclear: I am indeed only proposing to remove ssh1 fallback mode from the default configuration file of sshd, not from the default configuration of the ssh client. This change would not impact any users of existing FreeBSD installations as client or server. If somebody installs a fresh installation of FreeBSD 5.0 on a machine it would out-of-the-box support login by ssh2 only. Anybody that wishes to enable ssh1 on this fresh install remains able to do so. An upgrade shouldn't break your ssh settings regardless. Yes, this change would, out of the box, potentially come as a noticeable surprise for a small number of users: a user that needs to be able to log into a 5.0 box from a machine on which ssh2 is not available would manually need to enable ssh1 login in their sshd_config file. But I would argue that permitting ssh1 login into a machine should be a conscious act taken by the administrator by editing the config file, not something that a distribution should enable by default in a new install. Hope that helps somewhat clarify the scope of my request, --Lucky Green To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Request: remove ssh1 fallback
- Original Message - From: Terry Lambert [EMAIL PROTECTED] So I upgrade, and I can't get back into the box from my SSH1 client machine to reenable SSH1 services on the box. Genius! 8-) 8-). Its somewhat less than genious not to look over any new config files you've installed to make sure they do what you expect. That's blind trust. Not genius. A genius may have read the UPDATING file and been forwarned :) -Steve To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Request: remove ssh1 fallback
On Wed, Oct 23, 2002 at 02:16:26PM -0500, Steven Ames wrote: - Original Message - From: Terry Lambert [EMAIL PROTECTED] So I upgrade, and I can't get back into the box from my SSH1 client machine to reenable SSH1 services on the box. Genius! 8-) 8-). Its somewhat less than genious not to look over any new config files you've installed to make sure they do what you expect. That's blind trust. Not genius. A genius may have read the UPDATING file and been forwarned :) I think it's safe to say that if you do a remote upgrade to 5.0 and miss this change (if it happens), you're probably going to have missed several other more important change. A source upgrade from 4.x to 5.x is definatly not for the faint of heart or the non detail oriented. -- Brooks -- Any statement of the form X is the one, true Y is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 msg44840/pgp0.pgp Description: PGP signature
Re: Request: remove ssh1 fallback
Steven Ames wrote: From: Terry Lambert [EMAIL PROTECTED] So I upgrade, and I can't get back into the box from my SSH1 client machine to reenable SSH1 services on the box. Genius! 8-) 8-). Its somewhat less than genious not to look over any new config files you've installed to make sure they do what you expect. That's blind trust. Not genius. A genius may have read the UPDATING file and been forwarned :) No, a genius would have set up the upgrade software to interactively question the user about whether they wanted to leave that facility enabled, based on the upgrade software's understanding that the upgrade process would in fact disable features, and if there was a moral equivalent to upgrade -y, then everything that was enabled would be left enabled, even if that meant adding command line options into the rc.conf entry for the sshd arguments. Do Not Change Behaviour On Upgrade Without Eplicit User Approval(tm). -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Request: remove ssh1 fallback
Brooks Davis wrote: I think it's safe to say that if you do a remote upgrade to 5.0 and miss this change (if it happens), you're probably going to have missed several other more important change. A source upgrade from 4.x to 5.x is definatly not for the faint of heart or the non detail oriented. I'm talking a binary upgrade, using the sysinstall upgrade option. Check the mailing list archives around 4.3-RELEASE, when it was discovered that /etc/pam.conf didn't get ssh lines added to it on upgrades, and people were getting locked out of boxes left and right (predates other entries). Changing behaviour on an upgrade, without the user's consent, is a bad thing (note: *consent*, not *knowledge*: it's not up to the user to know about everything some programmer has diddled into non-operability in the two years since FreeBSD 5.x was branched). -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Request: remove ssh1 fallback
Check the mailing list archives around 4.3-RELEASE, when it was discovered that /etc/pam.conf didn't get ssh lines added to it on upgrades, and people were getting locked out of boxes left and right (predates other entries). Changing behaviour on an upgrade, without the user's consent, is a bad thing (note: *consent*, not *knowledge*: it's not up to the user to know about everything some programmer has diddled into non-operability in the two years since FreeBSD 5.x was branched). Isn't that what UPDATING is for and wouldn't between 4.x and 5.x be better than 5.x and 5.x+n? -- David W. Chapman Jr. [EMAIL PROTECTED] Raintree Network Services, Inc. www.inethouston.net [EMAIL PROTECTED] FreeBSD Committer www.FreeBSD.org To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Request: remove ssh1 fallback
On Wed, Oct 23, 2002 at 12:56:55PM -0700, Terry Lambert wrote: Brooks Davis wrote: I think it's safe to say that if you do a remote upgrade to 5.0 and miss this change (if it happens), you're probably going to have missed several other more important change. A source upgrade from 4.x to 5.x is definatly not for the faint of heart or the non detail oriented. I'm talking a binary upgrade, using the sysinstall upgrade option. A binary upgrade to 5.0 isn't going to be much better. If you just do it, it's going to leave you with most of the problems described in UPDATING. You're still going to have to remember to delete things from your includes directories if you want C++ to work, your pam.conf will be obsolete, the names of some devices will be different, etc. You can argue that the upgrade option shouldn't change anything until you're blue in the face, but that's not going to change reality. -- Brooks -- Any statement of the form X is the one, true Y is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 msg44844/pgp0.pgp Description: PGP signature
Re: Request: remove ssh1 fallback
On Wed 23 Oct, Terry Lambert wrote: What if the client machine is a SSH1 Solaris (or Windows) box going into a FreeBSD rackmount? It should *at least* be available as a command line option to the daemon; since some boxes *don't have* consoles at all, it would have the same effect of turning them into a doorstop to disable this flag, once it's available, by default (right now, it just provides both). What could be done with reasonable safety is leave current configs as they are, not changing anything for people upgrading, but setting the default behavior for default installs to no SSH1. Andrew To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Request: remove ssh1 fallback
On Wed, 23 Oct 2002, Andrew Mishchenko wrote: On Wed 23 Oct, Terry Lambert wrote: What if the client machine is a SSH1 Solaris (or Windows) box going into a FreeBSD rackmount? It should *at least* be available as a command line option to the daemon; since some boxes *don't have* consoles at all, it would have the same effect of turning them into a doorstop to disable this flag, once it's available, by default (right now, it just provides both). What could be done with reasonable safety is leave current configs as they are, not changing anything for people upgrading, but setting the default behavior for default installs to no SSH1. Andrew I heard of something like that before. Oh yeah, mergemaster(8). -Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Request: remove ssh1 fallback
David W. Chapman Jr. wrote: Changing behaviour on an upgrade, without the user's consent, is a bad thing (note: *consent*, not *knowledge*: it's not up to the user to know about everything some programmer has diddled into non-operability in the two years since FreeBSD 5.x was branched). Isn't that what UPDATING is for and wouldn't between 4.x and 5.x be better than 5.x and 5.x+n? No. The UPDATING file is for people updating their system by building and installing the world from source code. The UPDATING file is not really visible on the CDROM, or on the system, until /usr/src is installed. If you update a system with an existing /usr/src, sysinstall's upgrade option will refuse to install new source code in /usr/src, so you won't get the UPDATING file there, either. Even if the file did get installed as part of the upgrade option, if you booted off the CDROM for the upgrade, you can't deal with the issues listed in the file until after you reboot. In fact, since there is a history of ABI changes, you will not be able to deal with the contents of the UPDATING file except before you install any binaries that may required a new interface -- or the UPDATING file itself. It's a catch-22, even if you don't boot the CDROM, and do the upgrade from a copy of sysinstall that you obtained from another machine that you have already upgraded (since it's nested to vnconfig'ed devices deep on the CDROM, and practically unavailabe otherwise). If you want to change the default for new installs, fine with me (though I'm sure it will piss some people off); but don't break existing functionality on already installed systems that are upgraded. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Request: remove ssh1 fallback
Andrew Mishchenko wrote: On Wed 23 Oct, Terry Lambert wrote: What if the client machine is a SSH1 Solaris (or Windows) box going into a FreeBSD rackmount? It should *at least* be available as a command line option to the daemon; since some boxes *don't have* consoles at all, it would have the same effect of turning them into a doorstop to disable this flag, once it's available, by default (right now, it just provides both). What could be done with reasonable safety is leave current configs as they are, not changing anything for people upgrading, but setting the default behavior for default installs to no SSH1. This still changes a machine that works into a machine that doesn't work. How is that an upgrade? -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Request: remove ssh1 fallback
Brooks Davis wrote: On Wed, Oct 23, 2002 at 12:56:55PM -0700, Terry Lambert wrote: Brooks Davis wrote: I think it's safe to say that if you do a remote upgrade to 5.0 and miss this change (if it happens), you're probably going to have missed several other more important change. A source upgrade from 4.x to 5.x is definatly not for the faint of heart or the non detail oriented. I'm talking a binary upgrade, using the sysinstall upgrade option. A binary upgrade to 5.0 isn't going to be much better. If you just do it, it's going to leave you with most of the problems described in UPDATING. You're still going to have to remember to delete things from your includes directories if you want C++ to work, your pam.conf will be obsolete, the names of some devices will be different, etc. I thought 5.0-RELEASE wouldn't suck. Now you are saying that it will, and the fact that it will is justification for making it suck even more by breaking existing installed 4.7-RELEASE machines that get upgraded to 5.0-RELEASE. I really don't buy the It's OK to suck if someone else sucks rationalization (I had enough of that when doing the code review on NFS and NUC for UnixWare, thanks). You can argue that the upgrade option shouldn't change anything until you're blue in the face, but that's not going to change reality. I'm not saying that it shouldn't change implementation, I'm saying that it shouldn't change configuration. Upgrade is the whole reason we went to a central rc.conf thing in the first place, isn't it? Yes, it's really easy to break a lot of things, and then hope someone will follow along after you, cleaning up your mess, but it's not a reasonable attitude. If someone wants to drop support for an older protocol in a server that currently supports the older protocol, the way to deal with it is to deprecate, not delete, the older protocol. Specifically, if someone wants to not support ssh1 by default in sshd, then it is the job of that someone to make sure that legacy support can be enabled by a command line option, in order to deperecate the protocol (instead of yanking the rug out from everyone who uses it). It is also the job of that someone to add code to the upgrade process to, minimally, if the system being upgraded supports ssh1 by default, then automatically add the command line option to configuration, so that the behaviour does not change on existing systems. A non-minimal job would have the upgrade process query the user whether or not to disable ssh1 -- with a default of No. Note that this only becomes a problem when someone wants to change a default behaviour -- and it *rightly* becomes the problem of the one wanting to make the change. There is no such thing as bitrot. There is only a person who makes a hash of something, instead of doing a complete job. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Request: remove ssh1 fallback
* De: Terry Lambert [EMAIL PROTECTED] [ Data: 2002-10-23 ] [ Subjecte: Re: Request: remove ssh1 fallback ] [snipped] You're essentially arguing that upgrade should not change anything, but somehow that moving old stuff out of the way should be done? How is it exactly that you propose we take care of the include namespace breakage that GCC has introduced in an automated way, without possibly doing the wrong thing? If we're going to account for people modding their system then we have to leave it up to them, and the people who don't mod even, really, their rc.conf, to nuke the includes stuff. Besides, upgrading a production system in-place is almost never worth the effort it entails, on any system. Version skew, security issues, etc., all make this a less-than-enjoyable option. If you want specifics, I'll be glad to elaborate, but you don't have to be Terr^W^H Kreskin to figure it out. juli. -- Juli Mallett [EMAIL PROTECTED] | FreeBSD: The Power To Serve Will break world for fulltime employment. | finger [EMAIL PROTECTED] http://people.FreeBSD.org/~jmallett/ | Support my FreeBSD hacking! To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Request: remove ssh1 fallback
Juli Mallett wrote: * De: Terry Lambert [EMAIL PROTECTED] [ Data: 2002-10-23 ] [ Subjecte: Re: Request: remove ssh1 fallback ] [snipped] You're essentially arguing that upgrade should not change anything, but somehow that moving old stuff out of the way should be done? No. I'm arguing that configuration dictates behaviour, and perceived behaviour should not change. How is it exactly that you propose we take care of the include namespace breakage that GCC has introduced in an automated way, without possibly doing the wrong thing? The easiest approach would be the one SCO used, starting in 1986, where installed files are registered into a global database by component and version, and when an upgrade occurs, and the component is changed, those files which are from the previous component and not replaced by the new component are removed from the system. This is not something that can be dealt with this way at this late a date, unfortunately. It was probably a mistake to change the compiler version, without either dealing with this, or by versioning the include directories used, so that the new compiler could not see the older header files. Versioning the include directory is still an option, and would fix the problem (e.g. /usr/include/g++3_2_1). The fix would be both effective and immediate. If we're going to account for people modding their system then we have to leave it up to them, and the people who don't mod even, really, their rc.conf, to nuke the includes stuff. That's one option: make everyone do the labor, rather than having one person deal with it in source code. But it's not the most overall labor-efficient option. Besides, upgrading a production system in-place is almost never worth the effort it entails, on any system. Version skew, security issues, etc., all make this a less-than-enjoyable option. Then remove the upgrade option off the sysinstall menu, and be done with the issue: Upgrade not supported for 5.0. This isn't a realisitic option; even though you claim it is almost never worth the effort, I think most people want it anyway, despite what you think about the practice. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Request: remove ssh1 fallback
On Wed, Oct 23, 2002 at 03:29:30PM -0700, Terry Lambert wrote: Brooks Davis wrote: A binary upgrade to 5.0 isn't going to be much better. If you just do it, it's going to leave you with most of the problems described in UPDATING. You're still going to have to remember to delete things from your includes directories if you want C++ to work, your pam.conf will be obsolete, the names of some devices will be different, etc. I thought 5.0-RELEASE wouldn't suck. Now you are saying that it will, and the fact that it will is justification for making it suck even more by breaking existing installed 4.7-RELEASE machines that get upgraded to 5.0-RELEASE. I'm saying that trying to do an inplace upgrade will be fairly complicated. You will have to pay attention to what's going on and you will have to deal with things that have changed. If you don't read the release notes (which would certaintly mention this change if it were made), be prepared to get bitten. That's true of every other OS I've ever upgraded. As usual, your best bet is to do a fresh install. If you can't do that, you need to think long and hard before doing an upgrade. Most of the big features of 5.0 aren't going to do you a lot of good on a system that already works and is in production. For example, UFS2 is only useful if you can newfs your disks. In any case, this isn't the sort of thing you should leap into. If you do and things go badly, that's just too damn bad. -- Brooks msg44863/pgp0.pgp Description: PGP signature
Re: Request: remove ssh1 fallback
On Wed, 23 Oct 2002, Terry Lambert wrote: Then remove the upgrade option off the sysinstall menu, and be done with the issue: Upgrade not supported for 5.0. I think this is a *BRILLIANT* idea. Not supporting upgrade from 4.X to 5.0 will stave off loads of problems that will all be answered the same way, Does it happen on a clean install? -a To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Request: remove ssh1 fallback
On Wed, Oct 23, 2002 at 03:14:55PM -0700, Terry Lambert wrote: This still changes a machine that works into a machine that doesn't work. How is that an upgrade? I've no doubt some informed, good intentioned persons said the same thing when telnetd was no longer enabled by default. *shrug* Times change. Getting SSH2 compliant clients is pretty trivial in today's world on just about any platform. The machine continues to work. -Steve To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
