Peter Wemm wrote:
I hope we haven't changed the server default to stop forwarding.. the
security risk is to the client, not the remote sshd server, therefore it is
the client that should decide on whether to forward or not.
I seem to recall the server default being changed, then
On Thu, 20 Apr 2000, Kris Kennaway wrote:
I've tracked down what seems to be a bug in the new version of OpenSSL I
imported a week ago which affects the alpha platform. It *looks* like a
bug in OpenSSL's "bignum" library which might not have shown up for users
of the default openssl
In message [EMAIL PROTECTED] "Andrew Reilly" writes:
: Have you got "X11Forwarding yes"
Ahem. "ForwardX11 yes" is what's documented and is known to work.
Warner
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
On Thu, Apr 20, 2000 at 05:05:11PM -0700, Archie Cobbs wrote:
Kris Kennaway writes:
$ ssh [EMAIL PROTECTED]
Warning: Server lies about size of server host key: actual size is 1023 bits
vs. announced 1024.
Warning: This may be due to an old implementation of ssh.
Warning:
On Fri, Apr 21, 2000 at 01:25:20AM -0600, Warner Losh wrote:
In message [EMAIL PROTECTED] "Andrew Reilly" writes:
: Have you got "X11Forwarding yes"
Ahem. "ForwardX11 yes" is what's documented and is known to work.
Bzzzt. Man sshd(8):
X11Forwarding
Specifies whether X11
In message [EMAIL PROTECTED] "Andrew Reilly" writes:
: Bzzzt. Man sshd(8):
Ah, I'm confused and came in on the middle of a conversation. Never
mind.
: That's what I found out as a result of this conversation.
That's good to know!
Warner
To Unsubscribe: send mail to [EMAIL PROTECTED]
with
On Fri, 21 Apr 2000, Warner Losh wrote:
In message [EMAIL PROTECTED] "Andrew Reilly" writes:
: Have you got "X11Forwarding yes"
Ahem. "ForwardX11 yes" is what's documented and is known to work.
According to the documentation, ForwardX11 yes is for ssh configs and
X11Forwarding yes is for
On Fri, 21 Apr 2000, Andrew Reilly wrote:
What man ssh(1) doesn't tell you in this paragraph is that even
if you say "ForwardX11 yes" in ~/.ssh/config, you will not get
a proxy X session unless the server has "X11Forwarding yes" in
/etc/ssh/sshd_config. The default that my system
=== bin/csh/nls
cd /usr/src/bin/csh/nls ; make afterdistribute DESTDIR=/R/stage/trees/bin
=== bin/csh/nls/finnish
make: don't know how to make distribute. Stop
*** Error code 2
Stop in /usr/src/bin/csh/nls.
*** Error code 1
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL
On Fri, Apr 21, 2000 at 01:54:23PM +0200, Poul-Henning Kamp wrote:
=== bin/csh/nls
cd /usr/src/bin/csh/nls ; make afterdistribute DESTDIR=/R/stage/trees/bin
=== bin/csh/nls/finnish
make: don't know how to make distribute. Stop
Fix commited.
--
Andrey A. Chernov
[EMAIL PROTECTED]
Brian Fundakowski Feldman wrote:
On Thu, 20 Apr 2000, Chris Piazza wrote:
It's working from my 5.0 box to my 4.0-R box across town, too.
-Chris
Okay, give me some more info, please:
You're going from the 5.0 box to the 4.0 box. What's the /etc/hosts
look like on the 5.0 box?
Nickolay Dudorov wrote:
Me too
There is some problems with "/boot/loader". You can just
hit the key due to "|/-..." propelling and load "/boot/loader.old"
instead of "/boot/loader". (And the first thing I make on the
booted system - "cp /boot/loader.old /boot/loader.good" ;-)
Ah,
On Fri, 21 Apr 2000, Ben Smithurst wrote:
X11 forwarding is working for me now, but wasn't when I first tried
it. I found I was explicitly setting XAUTHORITY=~/.Xauthority in my
.zshrc file, so the temporary bits created in /tmp/ssh-foo/cookies by
ssh weren't being picked up. I missed the
Mike Pritchard writes:
Kris Kennaway writes:
$ ssh [EMAIL PROTECTED]
Warning: Server lies about size of server host key: actual size is 1023 bits
vs. announced 1024.
Warning: This may be due to an old implementation of ssh.
Warning: identity keysize mismatch: actual
Archie Cobbs wrote:
I presume the public key at freefall matches the public key
at machine-B. Try connecting back in the other direction
so that the 'known machines' settings are tested.
This only happens when going from machine A - machine B - freefall.
Machine A is 3.4-REL, machine B is
Julian Elischer writes:
I presume the public key at freefall matches the public key
at machine-B. Try connecting back in the other direction
so that the 'known machines' settings are tested.
Can't do that because of the firewall..
This only happens when going from machine A - machine B -
Archie Cobbs wrote:
What happens if you use TELNET to get to machine B?
does the ssh to freefall still misbehave?
(in other words.. what if machine A is not involved?)
Aha.. that works! (note: home directory is the same on A or B)
Looks like some of the environment that the 1st
On Thu, 20 Apr 2000, Dirk Roehrdanz wrote:
[ snippage ]
I get this message too whenever I mount a mfs filesystem.
The line in /etc/fstab is:
/dev/da0s1b /tmp mfs rw,async,-s327680 0
The output of "ls -l /dev/*da0s1b" is:
crw-r- 1 root operator 13,
=== bin/csh
install -c -s -o root -g wheel -m 555 csh /syv/release/bin
/syv/release/bin/tcsh - /syv/release/bin/csh
=== bin/csh/nls
=== bin/csh/nls/finnish
install -c -o root -g wheel -m 444 tcsh.cat
/syv/release/../usr/share/nls/fi_FI.ISO_8859-1/tcsh.cat
install:
On Fri, 21 Apr 2000, Archie Cobbs wrote:
This only happens when going from machine A - machine B - freefall.
Machine A is 3.4-REL, machine B is either 4.0-stable or 5.0-current
(as of a couple of days ago).
Hmm. It works for me going 5.0-C - 5.0-C - freefall using
openssh both times. Perhaps
On Fri, 21 Apr 2000, Brian Fundakowski Feldman wrote:
Sorry, no dice :( It doesn't seem to be that. All I've got left is
maybe sending out every bit of configuration info, and maybe someone
could figure it out. I doubt it, though, so I'm not gonna.
Silly question, but have you tried
On Fri, 21 Apr 2000, Archie Cobbs wrote:
Machine A is 3.4-REL, machine B is either 4.0-stable or 5.0-current
(as of a couple of days ago).
Hmm, I've just tried it with ssh-1.2.27 - openssh-1.2.3 - freefall, and
it still works. Maybe it's something about 1.2.26..let me know what
happens after
Kris Kennaway writes:
On Fri, 21 Apr 2000, Archie Cobbs wrote:
Machine A is 3.4-REL, machine B is either 4.0-stable or 5.0-current
(as of a couple of days ago).
Hmm, I've just tried it with ssh-1.2.27 - openssh-1.2.3 - freefall, and
it still works. Maybe it's something about 1.2.26..let
OpenSSL includes asm code for several platforms to speed up various
operations. Currently we don't build any of this - the attached patch
turns on asm code for Pentiums and above (it relies on an uncommitted
patch to sys.mk which defined MACHINE_CPU ?= i386). Set MACHINE_CPU to
"i586" or "i686"
On Fri, 21 Apr 2000, Warner Losh wrote:
In message [EMAIL PROTECTED] "Andrew Reilly" writes:
: Have you got "X11Forwarding yes"
Ahem. "ForwardX11 yes" is what's documented and is known to work.
While this whole thing is being discussed, does anyone know of either a
configuration variable
Can these be turned on at runtime?
My concern is that build systems that compile for other machines not
generate code dependent on the machine thats building the code.
On Fri, 21 Apr 2000, Kris Kennaway wrote:
OpenSSL includes asm code for several platforms to speed up various
operations.
On Sat, 22 Apr 2000, Matthew N. Dodd wrote:
Can these be turned on at runtime?
My concern is that build systems that compile for other machines not
generate code dependent on the machine thats building the code.
I probably meant TARGET_CPU, but that's easily taken care of.
Kris
In
On Fri, 21 Apr 2000, Chuck Robey wrote:
While this whole thing is being discussed, does anyone know of either a
configuration variable or environmental variable that ssh reads, that will
give the same effect as the -q flag, so that I can stop seeing those
stupid warnings about the size of
This thread began on -STABLE; I am moving it to -CURRENT and have
crossposted. Please, followups to -CURRENT.
On Sat, 22 Apr 2000, Jonathan Michaels wrote:
actually see bad blocks your disk is about to die. IIRC, the code was
suffering from bitrot and the drives that really needed it will
29 matches
Mail list logo