Mailing List Archive

On Thu, 11 May 2000, Pekka Savola wrote:

> Hello all,
>
> I wonder if this is an oversight/bug/feature, but here it goes.

...

> 2.0beta1 was the one I used before, and that printed FROM field properly.
> Now, every connection gets '-'.

It works for me. Can you describe your environment some more?

-d

--
| "Bombay is 250ms from New York in the new world order" - Alan Cox
| Damien Miller - http://www.mindrot.org/
| Email: djm@mindrot.org (home) -or- djm@ibs.com.au (work)

> > 2.0beta1 was the one I used before, and that printed FROM field properly.
> > Now, every connection gets '-'.
>
> It works for me. Can you describe your environment some more?

This is heavily updated (from src.rpm's) Redhat Linux 5.1 running 2.2.15
kernel.

I tried to diagnose this a bit, some results below. I hope all of you
forgive me for spamming the list. Hopefully these are of any use. ;)

When running 2.0beta and 2.1 in debug mode, the following differences came
up:

--- Non-working 2.1: ---
[...]
Accepted password for pekkas from 10.0.0.1 port 1022
debug: PAM setting rhost to "other.box"
debug: session_new: init
debug: session_new: session 0
debug: Allocating pty.
debug: Received request for X11 forwarding with auth spoofing.
debug: bind port 6010: Address already in use
debug: fd 7 setting O_NONBLOCK [extra]
debug: channel 0: new [X11 inet listener]
debug: PAM setting tty to "/dev/ttyp3"
debug: PAM establishing creds
debug: Entering interactive session.
debug: Setting controlling tty using TIOCSCTTY.
debug: server_init_dispatch_13
debug: server_init_dispatch_15
debug: tvp!=NULL kid 0 mili 10
[...]
--- Working 2.0beta: ---
Accepted password for pekkas from 10.0.0.1 port 1022
debug: PAM setting rhost to "other.box"
debug: session_new: init
debug: session_new: session 0
debug: Allocating pty.
debug: Received request for X11 forwarding with auth spoofing.
debug: bind port 6010: Address already in use
debug: channel 0: new [X11 inet listener]
debug: PAM setting tty to "/dev/ttyp3"
debug: PAM establishing creds
debug: Entering interactive session.
debug: server_init_dispatch_13
debug: server_init_dispatch_15
debug: Setting controlling tty using TIOCSCTTY.
debug: tvp!=NULL kid 0 mili 10
[...]
---
Note: setver_init_dispatch was done before setting controlling
tty. Also, O_NONBLOCK wasn't used in 2.0beta.

Because I fear this won't help any, I did some stracing with command:
'strace -v -f -otmp.log ./sshd -d -p 2022' and diagnosed the logs.

General overview (I concentrated on wtmp/utmp -- wtmp seemed fine):
----- 'grep utmp tmp.log' on non-working 2.1 -----
9895 open("/var/run/utmp", O_RDWR) = 10
9895 open("/var/run/utmp", O_RDWR) = 10
9903 open("/var/run/utmp", O_RDWR) = 5
9915 open("/var/run/utmp", O_RDWR) = -1 EACCES (Permission denied)
9915 open("/var/run/utmp", O_RDONLY) = 3
9918 open("/var/run/utmp", O_RDWR) = -1 EACCES (Permission denied)
9918 open("/var/run/utmp", O_RDONLY) = 5
9918 open("/var/run/utmp", O_RDWR) = -1 EACCES (Permission denied)
9918 open("/var/run/utmp", O_RDONLY) = 6
9895 open("/var/run/utmp", O_RDWR) = 5
-----
----- 'grep utmp tmp.log' on working 2.0beta -----
11939 open("/var/run/utmp", O_RDWR) = 10
11939 open("/var/run/utmp", O_RDWR) = 10
11941 open("/var/run/utmp", O_RDWR) = 5
11953 open("/var/run/utmp", O_RDWR) = -1 EACCES (Permission denied)
11953 open("/var/run/utmp", O_RDONLY) = 3
11939 open("/var/run/utmp", O_RDWR) = 5
-----

And respective 'grep -2 utmp tmp.log' outputs:
----- non-working 2.1 -----
9895 stat("/dev/ttyp2", {st_dev=makedev(8, 5), st_ino=386210, st_mode=S_IFCHR|0620, st_nlink=1, st_uid=501, st_gid=5, st_blksize=4096, st_blocks=0, st_rdev=makedev(3, 2), st_atime=2000/05/11-14:54:08, st_mtime=2000/05/11-14:54:14, st_ctime=2000/05/11-14:50:46}) = 0
9895 close(10) = 0
9895 open("/var/run/utmp", O_RDWR) = 10
9895 lseek(10, 0, SEEK_SET) = 0
9895 fcntl(10, F_SETLKW, {type=F_RDLCK, whence=SEEK_SET, start=0, len=0}) = 0
--
9895 stat("/dev/ttyp2", {st_dev=makedev(8, 5), st_ino=386210, st_mode=S_IFCHR|0620, st_nlink=1, st_uid=501, st_gid=5, st_blksize=4096, st_blocks=0, st_rdev=makedev(3, 2), st_atime=2000/05/11-14:54:08, st_mtime=2000/05/11-14:54:14, st_ctime=2000/05/11-14:50:46}) = 0
9895 close(10) = 0
9895 open("/var/run/utmp", O_RDWR) = 10
9895 lseek(10, 0, SEEK_SET) = 0
9895 fcntl(10, F_SETLKW, {type=F_RDLCK, whence=SEEK_SET, start=0, len=0}) = 0
--
9903 stat("/dev/ttyp3", {st_dev=makedev(8, 5), st_ino=386211, st_mode=S_IFCHR|0620, st_nlink=1, st_uid=501, st_gid=5, st_blksize=4096, st_blocks=0, st_rdev=makedev(3, 3), st_atime=2000/05/11-14:52:30, st_mtime=2000/05/11-14:52:30, st_ctime=2000/05/11-14:54:14}) = 0
9903 close(5) = 0
9903 open("/var/run/utmp", O_RDWR) = 5
9903 lseek(5, 0, SEEK_SET) = 0
9903 fcntl(5, F_SETLKW, {type=F_RDLCK, whence=SEEK_SET, start=0, len=0}) = 0
--
9915 stat("/dev/ttyp3", {st_dev=makedev(8, 5), st_ino=386211, st_mode=S_IFCHR|0620, st_nlink=1, st_uid=501, st_gid=5, st_blksize=4096, st_blocks=0, st_rdev=makedev(3, 3), st_atime=2000/05/11-14:52:30, st_mtime=2000/05/11-14:54:15, st_ctime=2000/05/11-14:54:14}) = 0
9915 close(3) = 0
9915 open("/var/run/utmp", O_RDWR) = -1 EACCES (Permission denied)
9915 open("/var/run/utmp", O_RDONLY) = 3
9915 lseek(3, 0, SEEK_SET) = 0
9915 fcntl(3, F_SETLKW, {type=F_RDLCK, whence=SEEK_SET, start=0, len=0}) = 0
--
9918 lseek(3, 0, SEEK_SET) = 0
9918 read(3, "531883.40 525611.77\n", 1023) = 20
9918 open("/var/run/utmp", O_RDWR) = -1 EACCES (Permission denied)
9918 open("/var/run/utmp", O_RDONLY) = 5
9918 lseek(5, 0, SEEK_SET) = 0
9918 fcntl(5, F_SETLK, {type=F_RDLCK, whence=SEEK_SET, start=0, len=0}) = 0
--
9895 write(2, "debug: tvp!=NULL kid 0 mili 10\n", 31) = 31
9895 select(9, [6 7 8], [], NULL, {0, 10000} <unfinished ...>
9918 open("/var/run/utmp", O_RDWR) = -1 EACCES (Permission denied)
9895 <... select resumed> ) = 0 (Timeout)
9895 select(9, [6 7 8], [6], NULL, NULL) = 1 (out [6])
9895 write(6, "\0\0\0\227\304m\244\221\3320\t]\221\2567\222:\213\232\237"..., 156) = 156
9895 select(9, [6 7 8], [], NULL, NULL <unfinished ...>
9918 open("/var/run/utmp", O_RDONLY) = 6
9918 lseek(6, 0, SEEK_SET) = 0
9918 fcntl(6, F_SETLK, {type=F_RDLCK, whence=SEEK_SET, start=0, len=0}) = 0
--
9895 write(2, "debug: Received exit confirmatio"..., 35) = 35
9895 write(2, "debug: session_pty_cleanup: sess"..., 57) = 57
9895 open("/var/run/utmp", O_RDWR) = 5
9895 lseek(5, 0, SEEK_SET) = 0
9895 fcntl(5, F_SETLKW, {type=F_RDLCK, whence=SEEK_SET, start=0, len=0}) = 0
-----
----- working 2.0 beta -----
11939 stat("/dev/ttyp2", {st_dev=makedev(8, 5), st_ino=386210, st_mode=S_IFCHR|0620, st_nlink=1, st_uid=501, st_gid=5, st_blksize=4096, st_blocks=0, st_rdev=makedev(3, 2), st_atime=2000/05/11-15:04:16, st_mtime=2000/05/11-15:04:23, st_ctime=2000/05/11-14:50:46}) = 0
11939 close(10) = 0
11939 open("/var/run/utmp", O_RDWR) = 10
11939 lseek(10, 0, SEEK_SET) = 0
11939 fcntl(10, F_SETLKW, {type=F_RDLCK, whence=SEEK_SET, start=0, len=0}) = 0
--
11939 stat("/dev/ttyp2", {st_dev=makedev(8, 5), st_ino=386210, st_mode=S_IFCHR|0620, st_nlink=1, st_uid=501, st_gid=5, st_blksize=4096, st_blocks=0, st_rdev=makedev(3, 2), st_atime=2000/05/11-15:04:16, st_mtime=2000/05/11-15:04:23, st_ctime=2000/05/11-14:50:46}) = 0
11939 close(10) = 0
11939 open("/var/run/utmp", O_RDWR) = 10
11939 lseek(10, 0, SEEK_SET) = 0
11939 fcntl(10, F_SETLKW, {type=F_RDLCK, whence=SEEK_SET, start=0, len=0}) = 0
--
11941 stat("/dev/ttyp3", {st_dev=makedev(8, 5), st_ino=386211, st_mode=S_IFCHR|0620, st_nlink=1, st_uid=501, st_gid=5, st_blksize=4096, st_blocks=0, st_rdev=makedev(3, 3), st_atime=2000/05/11-15:01:08, st_mtime=2000/05/11-15:01:08, st_ctime=2000/05/11-15:04:23}) = 0
11941 close(5) = 0
11941 open("/var/run/utmp", O_RDWR) = 5
11941 lseek(5, 0, SEEK_SET) = 0
11941 fcntl(5, F_SETLKW, {type=F_RDLCK, whence=SEEK_SET, start=0, len=0}) = 0
--
11953 stat("/dev/ttyp3", {st_dev=makedev(8, 5), st_ino=386211, st_mode=S_IFCHR|0620, st_nlink=1, st_uid=501, st_gid=5, st_blksize=4096, st_blocks=0, st_rdev=makedev(3, 3), st_atime=2000/05/11-15:01:08, st_mtime=2000/05/11-15:04:24, st_ctime=2000/05/11-15:04:23}) = 0
11953 close(3) = 0
11953 open("/var/run/utmp", O_RDWR) = -1 EACCES (Permission denied)
11953 open("/var/run/utmp", O_RDONLY) = 3
11953 lseek(3, 0, SEEK_SET) = 0
11953 fcntl(3, F_SETLKW, {type=F_RDLCK, whence=SEEK_SET, start=0, len=0}) = 0
--
11939 write(2, "debug: Received exit confirmatio"..., 35) = 35
11939 write(2, "debug: session_pty_cleanup: sess"..., 57) = 57
11939 open("/var/run/utmp", O_RDWR) = 5
11939 lseek(5, 0, SEEK_SET) = 0
11939 fcntl(5, F_SETLKW, {type=F_RDLCK, whence=SEEK_SET, start=0, len=0}) = 0
-----

HTH, Regards
--
Pekka Savola "Tell me of difficulties surmounted,
Pekka.Savola@netcore.fi not those you stumble over and fall"

On Thu, 11 May 2000, Damien Miller wrote:

> It works for me. Can you describe your environment some more?

I have the same problems. FROM field in utmp/wtmp are empty, but in
lastlog is ok...

System is Slackware 7.0 (glic-2.1.2).

Cheers,
Bole

On Tue, 16 May 2000, Bosko Radivojevic wrote:

> System is Slackware 7.0 (glic-2.1.2).
^^^^ ---> glibc ;)

Bye

> On Thu, 11 May 2000, Damien Miller wrote:
>
> > It works for me. Can you describe your environment some more?
>
> I have the same problems. FROM field in utmp/wtmp are empty, but in
> lastlog is ok...
>
> System is Slackware 7.0 (glic-2.1.2).
>

I figured this out. When merging stuff to create portable openssh, it
seems some autoconf stuff got changed and this causes the breakage.
I didn't do a complete analysis of this (because my eye isn't
autoconf-trained and it looked like a mess (playing with ossh_cv_* and
ac_cv_* in 'configure').

It seems that if you don't have utmpx.h and your utmp.h does contain
connecting hostname, autoconf doesn't configure required options AT ALL.
Only utmp definition by autoconf in here was '#define HAVE_UTMP_H 1'
Adding these (as created properly in 2.0beta1) to config.h afterwards made
the compiling go well, and the bug disappeared:

-----
#define HAVE_HOST_IN_UTMP 1
#define HAVE_ADDR_IN_UTMP 1
#define HAVE_ADDR_V6_IN_UTMP 1
#define HAVE_PID_IN_UTMP 1
#define HAVE_TYPE_IN_UTMP 1
#define HAVE_TV_IN_UTMP 1
#define HAVE_ID_IN_UTMP 1
-----

Of course, this isn't the "proper" way to do this, but at least the
problem is pinpointed to configure script making wrong decisions now..

Regards,
--
Pekka Savola "Tell me of difficulties surmounted,
Pekka.Savola@netcore.fi not those you stumble over and fall"

Hello all,

I had more time to dig into this problem. Configure script would print
stuff like:
checking for ut_host field in utmp.h... ossh_cv_utmp_h_has_ut_host

instead of:
checking for ut_host field in utmp.h... yes

This is caused by discontinuation of an undocumented feature of
/bin/sh. If you have bash-2.x as your /bin/sh, the configure script goes
wrong.

I patched configure and aclocal.m4. The method used works for both bash1
and bash2, so the changes should be backward compatible. I tested this
syntax on a couple of Redhat boxes and on Irix.

Regards,
Pekka

--- configure Sat May 20 08:48:05 2000
+++ configure.fixed Tue May 23 17:59:14 2000
@@ -2957,7 +2957,7 @@

fi

- ossh_result=`eval "echo "$"$ossh_varname"`
+ eval ossh_result=\$${ossh_varname}
if test -n "`echo $ossh_varname`"; then
echo "$ac_t""$ossh_result" 1>&6
if test "x$ossh_result" = "xyes"; then
@@ -2997,7 +2997,7 @@

fi

- ossh_result=`eval "echo "$"$ossh_varname"`
+ eval ossh_result=\$${ossh_varname}
if test -n "`echo $ossh_varname`"; then
echo "$ac_t""$ossh_result" 1>&6
if test "x$ossh_result" = "xyes"; then
@@ -3037,7 +3037,7 @@

fi

- ossh_result=`eval "echo "$"$ossh_varname"`
+ eval ossh_result=\$${ossh_varname}
if test -n "`echo $ossh_varname`"; then
echo "$ac_t""$ossh_result" 1>&6
if test "x$ossh_result" = "xyes"; then
@@ -3077,7 +3077,7 @@

fi

- ossh_result=`eval "echo "$"$ossh_varname"`
+ eval ossh_result=\$${ossh_varname}
if test -n "`echo $ossh_varname`"; then
echo "$ac_t""$ossh_result" 1>&6
if test "x$ossh_result" = "xyes"; then
@@ -3117,7 +3117,7 @@

fi

- ossh_result=`eval "echo "$"$ossh_varname"`
+ eval ossh_result=\$${ossh_varname}
if test -n "`echo $ossh_varname`"; then
echo "$ac_t""$ossh_result" 1>&6
if test "x$ossh_result" = "xyes"; then
@@ -3157,7 +3157,7 @@

fi

- ossh_result=`eval "echo "$"$ossh_varname"`
+ eval ossh_result=\$${ossh_varname}
if test -n "`echo $ossh_varname`"; then
echo "$ac_t""$ossh_result" 1>&6
if test "x$ossh_result" = "xyes"; then
@@ -3197,7 +3197,7 @@

fi

- ossh_result=`eval "echo "$"$ossh_varname"`
+ eval ossh_result=\$${ossh_varname}
if test -n "`echo $ossh_varname`"; then
echo "$ac_t""$ossh_result" 1>&6
if test "x$ossh_result" = "xyes"; then
@@ -3237,7 +3237,7 @@

fi

- ossh_result=`eval "echo "$"$ossh_varname"`
+ eval ossh_result=\$${ossh_varname}
if test -n "`echo $ossh_varname`"; then
echo "$ac_t""$ossh_result" 1>&6
if test "x$ossh_result" = "xyes"; then
@@ -3277,7 +3277,7 @@

fi

- ossh_result=`eval "echo "$"$ossh_varname"`
+ eval ossh_result=\$${ossh_varname}
if test -n "`echo $ossh_varname`"; then
echo "$ac_t""$ossh_result" 1>&6
if test "x$ossh_result" = "xyes"; then
@@ -3317,7 +3317,7 @@

fi

- ossh_result=`eval "echo "$"$ossh_varname"`
+ eval ossh_result=\$${ossh_varname}
if test -n "`echo $ossh_varname`"; then
echo "$ac_t""$ossh_result" 1>&6
if test "x$ossh_result" = "xyes"; then
@@ -3357,7 +3357,7 @@

fi

- ossh_result=`eval "echo "$"$ossh_varname"`
+ eval ossh_result=\$${ossh_varname}
if test -n "`echo $ossh_varname`"; then
echo "$ac_t""$ossh_result" 1>&6
if test "x$ossh_result" = "xyes"; then
@@ -3397,7 +3397,7 @@

fi

- ossh_result=`eval "echo "$"$ossh_varname"`
+ eval ossh_result=\$${ossh_varname}
if test -n "`echo $ossh_varname`"; then
echo "$ac_t""$ossh_result" 1>&6
if test "x$ossh_result" = "xyes"; then
--- aclocal.m4 Mon May 8 13:49:37 2000
+++ aclocal.m4.fixed Tue May 23 17:58:52 2000
@@ -22,7 +22,7 @@
eval "$ossh_varname=no" dnl
]) dnl
])
- ossh_result=`eval "echo "$"$ossh_varname"`
+ eval ossh_result=\$${ossh_varname}
if test -n "`echo $ossh_varname`"; then
AC_MSG_RESULT($ossh_result)
if test "x$ossh_result" = "xyes"; then
----------


--
Pekka Savola "Tell me of difficulties surmounted,
Pekka.Savola@netcore.fi not those you stumble over and fall"

Pekka Savola wrote:
>
> Hello all,
>
> I had more time to dig into this problem. Configure script would print
> stuff like:
> checking for ut_host field in utmp.h... ossh_cv_utmp_h_has_ut_host
>
> instead of:
> checking for ut_host field in utmp.h... yes
>
> This is caused by discontinuation of an undocumented feature of
> /bin/sh. If you have bash-2.x as your /bin/sh, the configure script goes
> wrong.
>
> I patched configure and aclocal.m4. The method used works for both bash1
> and bash2, so the changes should be backward compatible. I tested this
> syntax on a couple of Redhat boxes and on Irix.
>
> Regards,
> Pekka
>
> --- configure Sat May 20 08:48:05 2000
> +++ configure.fixed Tue May 23 17:59:14 2000
> @@ -2957,7 +2957,7 @@
>
> fi
>
> - ossh_result=`eval "echo "$"$ossh_varname"`
> + eval ossh_result=\$${ossh_varname}
> if test -n "`echo $ossh_varname`"; then
> echo "$ac_t""$ossh_result" 1>&6
> if test "x$ossh_result" = "xyes"; then

I suspect this change will break a lot of other systems. Remember there
are still machines out there that don't understand the $(command) syntax
(my stock Solaris with /bin/sh is one of them).

Is there another way to fix this and preserve the use of backticks?
--
Tom Bertelson "Any sufficiently advanced technology
RHI Consulting is indistinguishable from magic."
tbert@abac.com -- Arthur C. Clarke

> > I patched configure and aclocal.m4. The method used works for both bash1
> > and bash2, so the changes should be backward compatible. I tested this
> > syntax on a couple of Redhat boxes and on Irix.

> > - ossh_result=`eval "echo "$"$ossh_varname"`
> > + eval ossh_result=\$${ossh_varname}
>
> I suspect this change will break a lot of other systems. Remember there
> are still machines out there that don't understand the $(command) syntax
> (my stock Solaris with /bin/sh is one of them).
>
> Is there another way to fix this and preserve the use of backticks?

Does

ossh_result=`eval echo \"\\\$$ossh_varname\"`

do the required trick? This works for me with Bash 1, 2 and Solaris sh.

Cheers,

Simon.

Yo All!

I just tried to connect to an OpenSSH 2.1.0p2 server from a
SecureCRT 3.0.3 client using ssh2 protocol. The server is on Linux
and the client is on Win98. It did not work. ssh1 protocol works.
And yes, I set SecureCRT to 3DES/MD5 and 3DES/SHA1 with the server
type set to "standard". So at least I am not repeating that mistake.

SecureCRT says:
"Corrupt or invalid host key or algorithm"

See below for a debug dump of the server side.

The only odd thing about my setup is a 2048 bit host key. Could
that be a problem? Any ideas?

RGDS
GARY
---------------------------------------------------------------------------
Gary E. Miller Rellim 20340 Empire Ave, Suite E-3, Bend, OR 97701
gem@rellim.com Tel:+1(541)382-8588 Fax: +1(541)382-8676

# sshd -d -p 240

debug: sshd version OpenSSH-2.1
debug: Seeding random number generator
debug: read DSA private key done
debug: Seeding random number generator
debug: Bind to port 240 on 0.0.0.0.
Server listening on 0.0.0.0 port 240.
Generating 768 bit RSA key.
debug: Seeding random number generator
debug: Seeding random number generator
RSA key generation complete.
debug: Server will not fork when running in debugging mode.
Connection from 208.139.26.70 port 1749
debug: Client protocol version 2.0; client software version 3.0 SecureCRT (tm), a product of Van Dyke Technologies, Inc.
Enabling compatibility mode for protocol 2.0
debug: Local version string SSH-1.99-OpenSSH-2.1
debug: Sending KEX init.
debug: done
debug: got kexinit string: diffie-hellman-group1-sha1
debug: got kexinit string: ssh-dss
debug: got kexinit string: 3des-cbc
debug: got kexinit string: 3des-cbc
debug: got kexinit string: hmac-md5
debug: got kexinit string: hmac-md5
debug: got kexinit string: none
debug: got kexinit string: none
debug: got kexinit string:
debug: got kexinit string:
debug: first kex follow == 0
debug: reserved == 0
debug: done read kexinit
debug: kex: client->server 3des-cbc hmac-md5 none
debug: kex: server->client 3des-cbc hmac-md5 none
debug: Wait SSH2_MSG_KEXDH_INIT.
debug: bits set: 508/1024
debug: bits set: 488/1024
debug: sig size 20 20
debug: send SSH2_MSG_NEWKEYS.
debug: done: send SSH2_MSG_NEWKEYS.
debug: Wait SSH2_MSG_NEWKEYS.
Received disconnect: 2: Corrupt or invalid host key or algorithm.
debug: Calling cleanup 0x805c49c(0x0)

Circa 2000-May-24 12:08:49 -0400 schrieb Tom Bertelson:

: Pekka Savola wrote:
: > This is caused by discontinuation of an undocumented feature of
: > /bin/sh. If you have bash-2.x as your /bin/sh, the configure script goes
: > wrong.

Pekka, what undocumented feature is that? The line that you replace
below is (mostly; see below) an incredibly common Bourne shell idiom.

: > I patched configure and aclocal.m4. The method used works for both bash1
: > and bash2, so the changes should be backward compatible. I tested this
: > syntax on a couple of Redhat boxes and on Irix.
: >
: > Regards,
: > Pekka
: >
: > --- configure Sat May 20 08:48:05 2000
: > +++ configure.fixed Tue May 23 17:59:14 2000
: > @@ -2957,7 +2957,7 @@
: >
: > fi
: >
: > - ossh_result=`eval "echo "$"$ossh_varname"`
^^^^^^^^^^^^^^^^^^^^^^^^^^^
This use of double quotes is confusing anyway and looks broken. It
ought to read:

ossh_result=`eval echo \$"$ossh_varname"`

or perhaps:

ossh_result=`eval echo \$\{"${ossh_varname}"\}`

: > + eval ossh_result=\$${ossh_varname}

Does this actually work? I thought 'eval' spawned a subshell, but i
may be misremembering. [Testing in bash-1.14.7....] Hmm, it does
actually work. I certainly find that to be a much less complex
expression and like it better. I would suggest the following, though:

eval ossh_result=\$\{${ossh_varname}\}

in the general case, since it's possible for ${ossh_varname} to expand
to more than one word (or for that matter, to a parameter expression
such as 'blah:-haha'.

: I suspect this change will break a lot of other systems. Remember there
: are still machines out there that don't understand the $(command) syntax
: (my stock Solaris with /bin/sh is one of them).
:
: Is there another way to fix this and preserve the use of backticks?

Tom, i don't see any $() expression in the above change. What are you
referring to?

--
jim knoble | jmknoble@jmknoble.cx | http://www.jmknoble.cx/

On Wed, May 24, 2000 at 05:30:46PM -0700, Gary E. Miller wrote:
> SecureCRT says:
> "Corrupt or invalid host key or algorithm"
>
> See below for a debug dump of the server side.
>
> The only odd thing about my setup is a 2048 bit host key. Could
> that be a problem? Any ideas?

yes, this could be the problem, please try a 1024 bit key.

> Pekka, what undocumented feature is that? The line that you replace
> below is (mostly; see below) an incredibly common Bourne shell idiom.

I'm not intimate with sh syntax, so I don't really know, but COMPAT file
with bash2 states the following:
----
1. Bash now uses a new quoting syntax, $"...", to do locale-specific
string translation. Users who have relied on the (undocumented)
behavior of bash-1.14 will have to change their scripts. For
instance, if you are doing something like this to get the value of
a variable whose name is the value of a second variable:

eval var2=$"$var1"

you will have to change to a different syntax.

This capability is directly supported by bash-2.0:

var2=${!var1}

This alternate syntax will work portably between bash-1.14 and bash-2.0:

eval var2=\$${var1}
----

> : I suspect this change will break a lot of other systems. Remember there
> : are still machines out there that don't understand the $(command) syntax
> : (my stock Solaris with /bin/sh is one of them).
> :
> : Is there another way to fix this and preserve the use of backticks?
>
> Tom, i don't see any $() expression in the above change. What are you
> referring to?

OpenSSH-2.0beta used internal autoconf macros to do this stuff. It
worked. I don't see why ossh's own aclocal.m4 stuff had to be defined
anyway. Perhaps there's some reason for it, but I sure can't figure it
out. :)

--
Pekka Savola "Tell me of difficulties surmounted,
Pekka.Savola@netcore.fi not those you stumble over and fall"

Jim Knoble wrote:
> : I suspect this change will break a lot of other systems. Remember there
> : are still machines out there that don't understand the $(command) syntax
> : (my stock Solaris with /bin/sh is one of them).
> :
> : Is there another way to fix this and preserve the use of backticks?
>
> Tom, i don't see any $() expression in the above change. What are you
> referring to?

Sorry, I've been poring over Makefiles and running into this problem
lately. I misread the braces as parens, jumped the gun, and, well,
enough said.

I guess it's time to switch to a bigger font for my windows :-( (And I
just had my eyes checked last week!)
--
Tom Bertelson "Any sufficiently advanced technology
RHI Consulting is indistinguishable from magic."
tbert@abac.com -- Arthur C. Clarke

On Fri, 26 May 2000, Gary E. Miller wrote:

> Yo Markus!
>
> On Fri, 26 May 2000, Markus Friedl wrote:
>
> > On Fri, May 26, 2000 at 02:22:35AM -0700, Gary E. Miller wrote:
> > > Yo Markus!
> > >
> > > I set up a 1024 bit key on the openssh end and I still could not
> > > connect from the SecureCRT client using ssh v2. So that was not
> > > it.
> > >
> > > ssh v2.1.23 had no problems with either key size.
> >
> > 2.1.23? on the server side?
> I meant 2.0.13 on the client side.
>
> > for me SecureCRT with 1024 bit DSA server key works,
> > 2048 but DSA does not, it shows the same error you did get.
> I will try it again. I could not figure out how to override the key
> on the command line and I might have made a mistake.
>
> RGDS
> GARY

Hi Gary,

What does SecureCRT say if you turn on Trace Options (File \ Trace
Options) before you connect?

-Daniel Prevett <dprevett@cs.unm.edu>

Yo Markus!

I set up a 1024 bit key on the openssh end and I still could not
connect from the SecureCRT client using ssh v2. So that was not
it.

ssh v2.1.23 had no problems with either key size.

You can get a 30 day trial copy of SecureCRT from www.vandyke.com.
Anyone outside of the 7 countries on the US hate list can get it
off ther web now. It is the best ssh I have found for Windows.

I just tried SecureCRT 3.1 Beta 1 with the same results.

RGDS
GARY

On Thu, 25 May 2000, Markus Friedl wrote:

> On Wed, May 24, 2000 at 05:30:46PM -0700, Gary E. Miller wrote:
> > SecureCRT says:
> > "Corrupt or invalid host key or algorithm"
> >
> > See below for a debug dump of the server side.
> >
> > The only odd thing about my setup is a 2048 bit host key. Could
> > that be a problem? Any ideas?
>
> yes, this could be the problem, please try a 1024 bit key.
>

---------------------------------------------------------------------------
Gary E. Miller Rellim 20340 Empire Ave, Suite E-3, Bend, OR 97701
gem@rellim.com Tel:+1(541)382-8588 Fax: +1(541)382-8676

On Fri, May 26, 2000 at 02:22:35AM -0700, Gary E. Miller wrote:
> Yo Markus!
>
> I set up a 1024 bit key on the openssh end and I still could not
> connect from the SecureCRT client using ssh v2. So that was not
> it.
>
> ssh v2.1.23 had no problems with either key size.

2.1.23? on the server side?

for me SecureCRT with 1024 bit DSA server key works,
2048 but DSA does not, it shows the same error you did get.

> You can get a 30 day trial copy of SecureCRT from www.vandyke.com.
> Anyone outside of the 7 countries on the US hate list can get it
> off ther web now. It is the best ssh I have found for Windows.
>
> I just tried SecureCRT 3.1 Beta 1 with the same results.

i'll try this one, too.

i tried SecureCRT 3.1beta1 and it works with 1024 but fails with 2048 bit keys.

On Fri, May 26, 2000 at 11:37:14AM +0200, Markus Friedl wrote:
> On Fri, May 26, 2000 at 02:22:35AM -0700, Gary E. Miller wrote:
> > Yo Markus!
> >
> > I set up a 1024 bit key on the openssh end and I still could not
> > connect from the SecureCRT client using ssh v2. So that was not
> > it.
> >
> > ssh v2.1.23 had no problems with either key size.
>
> 2.1.23? on the server side?
>
> for me SecureCRT with 1024 bit DSA server key works,
> 2048 but DSA does not, it shows the same error you did get.
>
> > You can get a 30 day trial copy of SecureCRT from www.vandyke.com.
> > Anyone outside of the 7 countries on the US hate list can get it
> > off ther web now. It is the best ssh I have found for Windows.
> >
> > I just tried SecureCRT 3.1 Beta 1 with the same results.
>
> i'll try this one, too.
>

Yo Markus!

On Fri, 26 May 2000, Markus Friedl wrote:

> On Fri, May 26, 2000 at 02:22:35AM -0700, Gary E. Miller wrote:
> > Yo Markus!
> >
> > I set up a 1024 bit key on the openssh end and I still could not
> > connect from the SecureCRT client using ssh v2. So that was not
> > it.
> >
> > ssh v2.1.23 had no problems with either key size.
>
> 2.1.23? on the server side?
I meant 2.0.13 on the client side.

> for me SecureCRT with 1024 bit DSA server key works,
> 2048 but DSA does not, it shows the same error you did get.
I will try it again. I could not figure out how to override the key
on the command line and I might have made a mistake.

RGDS
GARY
---------------------------------------------------------------------------
Gary E. Miller Rellim 20340 Empire Ave, Suite E-3, Bend, OR 97701
gem@rellim.com Tel:+1(541)382-8588 Fax: +1(541)382-8676