Re: SSH Must Die
Mike Silbersack wrote: On Sun, 13 May 2001, Peter Wemm wrote: Mike Silbersack wrote: 1. Is ssh working yet? Yes, it is working perfectly. The only problem is that it now works slightly differently to what people have expected. ie: it treats sshv1 rsa keys as totally seperate to sshv2 rsa keys. Let me rephrase: 1. Terry, is ssh working for you yet? The /etc/pam.conf additions have fixed some of the systems, but not all of them. The difference between the systems that work with the changes, and the onces which do not, is the precise upgrade process. The systems that work were booted from the CDROM, and upgraded via the sysinstall upgrade process. The systems which do not work were booted from the hard disk, and upgraded via the sysinstall upgrade process, using a copy of the sysinstall from one of the successfully upgraded systems (i.e. they were _not_ booted from CDROM, since the machines in question are rack-mounts without CDROMs in them). On the failing systems, I get: -- root% sshd error: ConnectionsPerPeriod has been deprecated! no RSA support in libssl and libcrypto. See ssl(8) Disabling protocol version 1 error: Could not load DSA host key: /etc/ssh/ssh_host_dsa_key Disabling protocol version 2 sshd: no hostkeys available -- exiting. sshd: no hostkeys available -- exiting. -- Ignore the lack of host keys: the key generation program has the same complaint about libssl and libcrypto. Running nm on the libraries in question shows RSA code is present. It would be nice if it would tell me how it is going about arriving at its erroneous conclusion. I have verified that all libraries in question on the working and non-working systems are, in fact, identical to each other. So are the ssh, sshd, and key generation tool. The earlier suggestion that I delete libcrypto.so.1 did not bear any fruit, either. Neither does replacing everything sshd and ssh is linked shared against, as well as the binaries themselves. There is just something strange about how SSH works, in combination with a boot vs. local run of the upgrade process. 8-(. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: SSH Must Die
Kris Kennaway wrote: On Sat, May 12, 2001 at 04:24:48PM -0700, Terry Lambert wrote: Jordan Hubbard wrote: ssh works just fine for me in 4.3. You must be doing something wrong. I used that sysinstall thing Jordan wrote to upgrade from a 4.2 to a 4.3 system. Is that what I'm doing wrong? ;^). sysinstall does a very minimal job of merging the contents of /etc. Certainly it could be improved (mergemaster works nicely when you have the source tree around). Your patches would be appreciated. I would be happy to rewrite the whole thing, if I could do a soft updates like license for the first year, and still be permitted distribute it as FreeBSD. I might even be willing to fix up that Java stuff, and run the Java version of InstallShield to do the work... I'm kind of annoyed that it looks like my patches for the KERNCONF haven't made it in, so that the next time I roll a 4.3-RELEASE CDROM with my own bits on it, I'm going to have exactly the same problem with not having a kernel.GENERIC (stomping GENERIC locally is not a viable option, since it would collide with repository changes to the GENERIC file). Makes me not want to fix other things in the code, like it's internal list of packages, rather than reading them from a file on the CDROM, and really bloating the program image considerably, or the use of the path instead of the description line when displaying packages to be installed, etc.. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: SSH Must Die
Matthew Jacob [EMAIL PROTECTED] writes: There's a very likely 3rd possibility: ssh works fine, but the upgrade process has holes that even traps the experienced. I'll confirm this. I've done several upgrades and fresh installs in the past 2 weeks, and sometimes the /etc/pam.conf does -not- get upgraded. I dunno why, nor am I likely to check, but I thought I'd provide another datapoint. -- Dave Hayes - Consultant - Altadena CA, USA - [EMAIL PROTECTED] The opinions expressed above are entirely my own He who angers you conquers you. --Elizabeth Kenny To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: SSH Must Die
Hello there! On Sat, 12 May 2001, Valentin Nechayev wrote: On -current, I watched identical problem with mystical ssh brokenness, with No RSA support in libcrypto and libssl message from ssh, after when all possible underwater stones were verified (including /dev/random and /dev/urandom, respect to markm@ reply). Unfortunately I had to make this system working in any way before I could do any diagnose, and it was completely rebuilt to RELENG_4. But, your case seems to be another. I'm facing the same problems with ssh on -current, though it's not a production machine but my home workstation, so I'm able to tweak it as I like. When 5.0-current was just installed, it booted ok, but when it was recompiled and installed (make world), it began to show these messages. I'm ready to perform needed tests - if there are any. # Alexey To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: SSH Must Die
David Taylor([EMAIL PROTECTED])@2001.05.13 21:16:33 +:
On Sun, 13 May 2001, Karsten W. Rohrbach wrote:
---
VERSION_NUMBER=`grep [$]FreeBSD: $0 | cut -d ' ' -f 4`
echo mergemaster version ${VERSION_NUMBER}
---
That would appear to be mergemaster grepping for the $FreeBSD$ line in
itself, then extracting the CVS revision number from that line.
ack, did i smoke something?
i had a long uptime, please excuse my late night brain dropout ;-)
sorry * for consuming your time!
/k
--
Obscenity is the crutch of inarticulate motherfuckers.
KR433/KR11-RIPE -- http://www.webmonster.de -- ftp://ftp.webmonster.de
[Key] [KeyID---] [Created-] [Fingerprint-]
GnuPG 0x2964BF46 2001-03-15 42F9 9FFF 50D4 2F38 DBEE DF22 3340 4F4E 2964 BF46
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: SSH Must Die
On Sun, May 13, 2001 at 11:14:05AM -0700, Doug Barton wrote: That said, I am working on some things to make mm handle cases where the user has not modified the files easier to deal with. We should have /etc/MD5SUM.install which contains the MD5 checksum of the installed files. The upgrade option could then use that to decide which files to spam and which need to be preserved. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: SSH Must Die
Kris Kennaway([EMAIL PROTECTED])@2001.05.12 19:33:54 +:
On Sat, May 12, 2001 at 04:24:48PM -0700, Terry Lambert wrote:
Jordan Hubbard wrote:
ssh works just fine for me in 4.3. You must be doing something
wrong.
I used that sysinstall thing Jordan wrote to upgrade
from a 4.2 to a 4.3 system.
Is that what I'm doing wrong? ;^).
sysinstall does a very minimal job of merging the contents of /etc.
Certainly it could be improved (mergemaster works nicely when you have
the source tree around). Your patches would be appreciated.
is there a way to make the upgrade process easier by doing the thing
mergemaster does but with an interface that does not kill the average
ordinary user with a simple prompt without really useful help
incantating strange phrases to summon the subprocesses that diff and
patch and apply the arcane magic?
the average luser cannot deal with diff outputs so it would make sense
to have a simple program displaying the old version in the upper and the
new in the lower part of the screen, allowing the user to choose what to
do next. i am not quite sure, but i think about it feeling like vim or
emacs in splitscreen mode editing version-tagged files.
btw, mergemaster's version number generation for the help/syntax page is
broken because it displays the number of the running kernel not the
version of mergemaster itself:
---
VERSION_NUMBER=`grep [$]FreeBSD: $0 | cut -d ' ' -f 4`
echo mergemaster version ${VERSION_NUMBER}
---
why is it this way? i would think about creating the version in the
build process and s/@TAG@/version/ it in the to-be-installed mergemaster
file.
Kris
--
A Puritan is someone who is deathly afraid that someone, somewhere, is
having fun.
KR433/KR11-RIPE -- http://www.webmonster.de -- ftp://ftp.webmonster.de
[Key] [KeyID---] [Created-] [Fingerprint-]
GnuPG 0x2964BF46 2001-03-15 42F9 9FFF 50D4 2F38 DBEE DF22 3340 4F4E 2964 BF46
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: SSH Must Die
Karsten W. Rohrbach wrote: is there a way to make the upgrade process easier by doing the thing mergemaster does but with an interface that does not kill the average ordinary user with a simple prompt without really useful help incantating strange phrases to summon the subprocesses that diff and patch and apply the arcane magic? the average luser cannot deal with diff outputs There is a school of thought that says if you cannot handle something as simple as a diff output you probably shouldn't be running unix. I'm all for making things simpler for users, but there is a level beyond which it's not possible to go without turning into windows. That said, I am working on some things to make mm handle cases where the user has not modified the files easier to deal with. so it would make sense to have a simple program displaying the old version in the upper and the new in the lower part of the screen, allowing the user to choose what to do next. i am not quite sure, but i think about it feeling like vim or emacs in splitscreen mode editing version-tagged files. As Kris said in his previous post, your patches are welcome. One problem with your approach however is that if you show the user all of both files they are very likely to miss important changes. Tools like diff were developed precisely because picking small changes out of large bodies of text is one thing that computers do well (or at least, better than humans). Also, with sdiff (which is what mm invokes to do the merge) it displays old and new on the left and right sides of the screen and gives you several options for how to merge the two together, including editing both old and new together. Check out the man page for sdiff. btw, mergemaster's version number generation for the help/syntax page is broken because it displays the number of the running kernel not the version of mergemaster itself: It's completely impossible for mm to get the number of the running kernel, whatever that is, as its version number. # mergemaster -h mergemaster version 1.18 . . . # ident /usr/sbin/mergemaster /usr/sbin/mergemaster: $FreeBSD: src/usr.sbin/mergemaster/mergemaster.sh,v 1.18 2001/03/29 14:04:19 asmodai Exp $ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: SSH Must Die
On Sun, 13 May 2001, Karsten W. Rohrbach wrote:
btw, mergemaster's version number generation for the help/syntax page is
broken because it displays the number of the running kernel not the
version of mergemaster itself:
---
VERSION_NUMBER=`grep [$]FreeBSD: $0 | cut -d ' ' -f 4`
echo mergemaster version ${VERSION_NUMBER}
---
That would appear to be mergemaster grepping for the $FreeBSD$ line in
itself, then extracting the CVS revision number from that line.
why is it this way? i would think about creating the version in the
build process and s/@TAG@/version/ it in the to-be-installed mergemaster
file.
The version is branded into the file during the cvs commit process, and is
extracted from the installed file when needed...
--
David Taylor
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: SSH Must Die
On Sat, 12 May 2001, Terry Lambert wrote: Erik Trulsson wrote: Exactly how is rpping it out of FreeBSD supposed to make ssh work? I don't necessarily want it to work or not work, I just want it to quit being a pain in my backside. If it can't be made to upgrade correctly, then ripping it out also satisfies the criteria necessary to achieve the intended goal. Ok, backing this thread up briefly, two quick questions: 1. Is ssh working yet? 2. Do you have multiple copies of ssh/sshd laying around the system in different places? I ask because the mergemaster /etc track this thread has taken seems offbase; pam.conf would cause authentication errors, not RSA-related errors, if I recall correctly. Mike Silby Silbersack To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: SSH Must Die
Mike Silbersack wrote: On Sat, 12 May 2001, Terry Lambert wrote: Erik Trulsson wrote: Exactly how is rpping it out of FreeBSD supposed to make ssh work? I don't necessarily want it to work or not work, I just want it to quit being a pain in my backside. If it can't be made to upgrade correctly, then ripping it out also satisfies the criteria necessary to achieve the intended goal. Ok, backing this thread up briefly, two quick questions: 1. Is ssh working yet? Yes, it is working perfectly. The only problem is that it now works slightly differently to what people have expected. ie: it treats sshv1 rsa keys as totally seperate to sshv2 rsa keys. The simplest thing is to do a ssh-keygen to generate a new RSA key and update ~/.ssh/authorized_keys2 once per remote machine that you connect to. Once that is done, it never bothers you again. You can change /etc/ssh/ssh_config so that it says 'Protocol 1,2', but that is avoiding the problem rather than using the more robust, cryptographically secure sshv2 wire protocol. Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] All of this is for nothing if we don't go to the stars - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: SSH Must Die
On Sun, 13 May 2001, Peter Wemm wrote: Mike Silbersack wrote: 1. Is ssh working yet? Yes, it is working perfectly. The only problem is that it now works slightly differently to what people have expected. ie: it treats sshv1 rsa keys as totally seperate to sshv2 rsa keys. Let me rephrase: 1. Terry, is ssh working for you yet? Mike Silby Silbersack To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: SSH Must Die
Le 2001-05-13, Peter Wemm écrivait : The simplest thing is to do a ssh-keygen to generate a new RSA key and update ~/.ssh/authorized_keys2 once per remote machine that you connect to. Once that is done, it never bothers you again. You can change /etc/ssh/ssh_config so that it says 'Protocol 1,2', but that is avoiding the problem rather than using the more robust, cryptographically secure sshv2 wire protocol. Ah. This seems to work around the very unfortunate situation described in PR bin/27264. It seems very strange that one has to change the setup on the *server* side to work around a regression on the client side. Why cannot one use the same RSA public key for v1 and v2 client authentication? Thomas. -- [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: SSH Must Die
Thomas Quinot wrote: Le 2001-05-13, Peter Wemm écrivait : The simplest thing is to do a ssh-keygen to generate a new RSA key and update ~/.ssh/authorized_keys2 once per remote machine that you connect to. Once that is done, it never bothers you again. You can change /etc/ssh/ssh_config so that it says 'Protocol 1,2', but that is avoiding the problem rather than using the more robust, cryptographically secure sshv2 wire protocol. Ah. This seems to work around the very unfortunate situation described in PR bin/27264. It seems very strange that one has to change the setup on the *server* side to work around a regression on the client side. Why cannot one use the same RSA public key for v1 and v2 client authentication? That is something that I'd like to know too. RSA keys are RSA keys, regardless of how they are encoded. Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] All of this is for nothing if we don't go to the stars - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
SSH Must Die
This whole ssh B.S. is very annoying. After an upgrade from 4.2 to 4.3 using a CDROM boot plus upgrade menu option, SSH stops working, for no good reason (_any_ reason is no good). It complains about RSA not being in libcrypto, even though nm shows that that claim is full of crap. Yes, I have /dev/random, and yes, I have it in my kernel, even though it makes my boots slow as hell. How do I update the whole thing, so that the problem goes away? Alternately, can we rip it bodily out of FreeBSD, and flush it down the toilet? -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: SSH Must Die
On Sat 2001-05-12 (04:24), Terry Lambert wrote: This whole ssh B.S. is very annoying. After an upgrade from 4.2 to 4.3 using a CDROM boot plus upgrade menu option, SSH stops working, for no good reason (_any_ reason is no good). It complains about RSA not being in libcrypto, even though nm shows that that claim is full of crap. Yes, I have /dev/random, and yes, I have it in my kernel, even though it makes my boots slow as hell. 4.3 doesn't have device random, or any way of building without it. How is it changing the speed of your boot? I've actually just done a 4.3 CD upgrade, but not from 4.2, and it worked. Can you give the modification times of your libcrypto and ssh, and make sure you're executing /usr/bin/ssh. And the output of 'ld /usr/bin/ssh'. Perhaps truss an ssh to a host and disconnect immediately. It might be failing after trying to open or read from /dev/urandom. Can you give the output of 'ls -l /dev/*random'? Maybe someone will have something useful to go on from the information above instead of it doesn't work. Neil -- Neil Blakey-Milner [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: SSH Must Die
On Saturday 12 May 2001 06:24, Terry Lambert wrote: This whole ssh B.S. is very annoying. After an upgrade from 4.2 to 4.3 using a CDROM boot plus upgrade menu option, SSH stops working, for no good reason (_any_ reason is no good). You did make the needed additions to /etc/pam.conf, didn't you? It complains about RSA not being in libcrypto, even though nm shows that that claim is full of crap. Yes, I have /dev/random, and yes, I have it in my kernel, even though it makes my boots slow as hell. How do I update the whole thing, so that the problem goes away? Alternately, can we rip it bodily out of FreeBSD, and flush it down the toilet? -- Terry What would we use for remote command line access if that happened? Josh To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: SSH Must Die
Sat, May 12, 2001 at 04:24:29, tlambert2 (Terry Lambert) wrote about SSH Must Die: This whole ssh B.S. is very annoying. After an upgrade from 4.2 to 4.3 using a CDROM boot plus upgrade menu option, SSH stops working, for no good reason (_any_ reason is no good). It complains about RSA not being in libcrypto, even though nm shows that that claim is full of crap. Yes, I have /dev/random, and yes, I have it in my kernel, even though it makes my boots slow as hell. Oh. The random device which needs entropy seed is -current artifact, isn't it? On -current, I watched identical problem with mystical ssh brokenness, with No RSA support in libcrypto and libssl message from ssh, after when all possible underwater stones were verified (including /dev/random and /dev/urandom, respect to markm@ reply). Unfortunately I had to make this system working in any way before I could do any diagnose, and it was completely rebuilt to RELENG_4. But, your case seems to be another. How do I update the whole thing, so that the problem goes away? Alternately, can we rip it bodily out of FreeBSD, and flush it down the toilet? Do you know another SSH implementation with good license? /netch To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: SSH Must Die
ssh works just fine for me in 4.3. You must be doing something wrong. - Jordan From: Terry Lambert [EMAIL PROTECTED] Subject: SSH Must Die Date: Sat, 12 May 2001 04:24:29 -0700 This whole ssh B.S. is very annoying. After an upgrade from 4.2 to 4.3 using a CDROM boot plus upgrade menu option, SSH stops working, for no good reason (_any_ reason is no good). It complains about RSA not being in libcrypto, even though nm shows that that claim is full of crap. Yes, I have /dev/random, and yes, I have it in my kernel, even though it makes my boots slow as hell. How do I update the whole thing, so that the problem goes away? Alternately, can we rip it bodily out of FreeBSD, and flush it down the toilet? -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: SSH Must Die
On Sat, May 12, 2001 at 07:23:20AM -0700, Jordan Hubbard wrote: ssh works just fine for me in 4.3. You must be doing something wrong. - Jordan From: Terry Lambert [EMAIL PROTECTED] Subject: SSH Must Die Date: Sat, 12 May 2001 04:24:29 -0700 This whole ssh B.S. is very annoying. After an upgrade from 4.2 to 4.3 using a CDROM boot plus upgrade menu option, SSH stops working, for no good reason (_any_ reason is no good). It complains about RSA not being in libcrypto, even though nm shows that that claim is full of crap. Yes, I have /dev/random, and yes, I have it in my kernel, even though it makes my boots slow as hell. How do I update the whole thing, so that the problem goes away? Alternately, can we rip it bodily out of FreeBSD, and flush it down the toilet? Exactly how is rpping it out of FreeBSD supposed to make ssh work? I think I had similar problems at some point between 4.2-R and 4.3-R. At some (fairly late IIRC) point inbetween the version numbers of some of the crypto libraries was increased. After a buildworld I had both lib.so.1 and lib.so.2 installed in /usr/lib. I think deleting/moving one of them (the .so.1 one IIRC) and then doing a new build/installworld with 'COMPAT4X=yes' in /etc/make.conf made things work correctly. I am afraid I don't remember the details exactly but it might be a starting point. -- Insert your favourite quote here. Erik Trulsson [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: SSH Must Die
Jordan Hubbard wrote: ssh works just fine for me in 4.3. You must be doing something wrong. I used that sysinstall thing Jordan wrote to upgrade from a 4.2 to a 4.3 system. Is that what I'm doing wrong? ;^). -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: SSH Must Die
Erik Trulsson wrote: Exactly how is rpping it out of FreeBSD supposed to make ssh work? I don't necessarily want it to work or not work, I just want it to quit being a pain in my backside. If it can't be made to upgrade correctly, then ripping it out also satisfies the criteria necessary to achieve the intended goal. I think I had similar problems at some point between 4.2-R and 4.3-R. At some (fairly late IIRC) point inbetween the version numbers of some of the crypto libraries was increased. After a buildworld I had both lib.so.1 and lib.so.2 installed in /usr/lib. I think deleting/moving one of them (the .so.1 one IIRC) and then doing a new build/installworld with 'COMPAT4X=yes' in /etc/make.conf made things work correctly. I am afraid I don't remember the details exactly but it might be a starting point. Yes, I see multiple installed copies of the libraries on my system. Since this is a cDROM from a make release, I expected to see that for compatability reasons. Are you saying that if I install the new compat4 stuff from the 4.3 CDROM, the problem will solve itself? I am willing to try that, but won't be able to tell you what happened until Monday. Thanks, -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: SSH Must Die
j wrote: On Saturday 12 May 2001 06:24, Terry Lambert wrote: This whole ssh B.S. is very annoying. After an upgrade from 4.2 to 4.3 using a CDROM boot plus upgrade menu option, SSH stops working, for no good reason (_any_ reason is no good). You did make the needed additions to /etc/pam.conf, didn't you? What additions are necessary between 4.2 and 4.3? I was under the impression that sysinstall was supposed to just do the right thing, and don't hassle me? If you have a dead chicken I should wave over my keyboard, hand it over! 8-). Alternately, can we rip it bodily out of FreeBSD, and flush it down the toilet? What would we use for remote command line access if that happened? I was always partial to telnet, but then I haven't really taken enough methamphetamines in my life (and the few I have taken were given to me by doctors) to make me as extraorfdinarily paranoid as most people seem to be these days. Of course, the idea that I'm being increasingly surrounded by mentally unstable speed freaks might be considered a paranoid fantasy by some, I suppose... 8-p. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: SSH Must Die
On Saturday 12 May 2001 18:40, Terry Lambert wrote: j wrote: On Saturday 12 May 2001 06:24, Terry Lambert wrote: This whole ssh B.S. is very annoying. After an upgrade from 4.2 to 4.3 using a CDROM boot plus upgrade menu option, SSH stops working, for no good reason (_any_ reason is no good). You did make the needed additions to /etc/pam.conf, didn't you? What additions are necessary between 4.2 and 4.3? I was under the impression that sysinstall was supposed to just do the right thing, and don't hassle me? If you have a dead chicken I should wave over my keyboard, hand it over! 8-). Make sure you have these lines in /etc/pam.conf sshdauthsufficient pam_skey.so sshdauthrequiredpam_unix.so try_first_pass sshdsession requiredpam_permit.so These lines are not in 4.2-rel and they are needed in 4.3-rel. Have fun. Josh To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: SSH Must Die
On Sat, May 12, 2001 at 04:31:29PM -0700, Terry Lambert wrote: Erik Trulsson wrote: Exactly how is rpping it out of FreeBSD supposed to make ssh work? I don't necessarily want it to work or not work, I just want it to quit being a pain in my backside. If it can't be made to upgrade correctly, then ripping it out also satisfies the criteria necessary to achieve the intended goal. I think I had similar problems at some point between 4.2-R and 4.3-R. At some (fairly late IIRC) point inbetween the version numbers of some of the crypto libraries was increased. After a buildworld I had both lib.so.1 and lib.so.2 installed in /usr/lib. I think deleting/moving one of them (the .so.1 one IIRC) and then doing a new build/installworld with 'COMPAT4X=yes' in /etc/make.conf made things work correctly. I am afraid I don't remember the details exactly but it might be a starting point. Yes, I see multiple installed copies of the libraries on my system. Since this is a cDROM from a make release, I expected to see that for compatability reasons. Are you saying that if I install the new compat4 stuff from the 4.3 CDROM, the problem will solve itself? I am willing to try that, but won't be able to tell you what happened until Monday. The compat4 stuff should install libraries in /usr/lib/compat/ After you have installed those, make sure that libraries found in /usr/lib/compat/ are not also installed in /usr/lib/ (E.g. if you have both /usr/lib/compat/libssl.so.1 and /usr/lib/libssl.so.1 then you should delete the latter.) And then you should use ldconfig or reboot to make sure that the right libraries are found. At least that fixed it for me but YMMV. (Might work with just removing the duplicate libraries from /usr/lib, except that if you have any binaries linked against the older versions they will probably stop working.) (No, I don't know why it wouldn't work with the older libraries residing in /usr/lib/ . It should have worked as I understand things. Well, everything works fine for me now anyway.) -- Insert your favourite quote here. Erik Trulsson [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: SSH Must Die
I used that sysinstall thing Jordan wrote to upgrade from a 4.2 to a 4.3 system. Is that what I'm doing wrong? ;^). Probably! Anybody would be the first to tell you that sysinstall's upgrade feature only gets you there unassisted maybe 3 times out of 5. The contents of /etc are side-stepped around, for example, they're not merged by any stretch of the imagination and I think there are a whole bunch of disclaimers in sysinstall to that effect. - Jordan To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: SSH Must Die
On Sat, May 12, 2001 at 04:24:48PM -0700, Terry Lambert wrote: Jordan Hubbard wrote: ssh works just fine for me in 4.3. You must be doing something wrong. I used that sysinstall thing Jordan wrote to upgrade from a 4.2 to a 4.3 system. Is that what I'm doing wrong? ;^). sysinstall does a very minimal job of merging the contents of /etc. Certainly it could be improved (mergemaster works nicely when you have the source tree around). Your patches would be appreciated. Kris PGP signature
