Mailing List Archive

Marc.Haber-lists@gmx.de (Marc Haber) writes:

> Hi!
>
> When I try to use scp from or to a machine that runs openssh-1.2pre16
> on Debian Linux, I keep getting the error message "scp: command not
> found". Executing "ssh this-host echo \$PATH" yields
> "/usr/bin:/bin:/usr/sbin:/sbin:" which might be set in config.h.
>
> sshd is installed to /usr/local/stow/openssh-1.2pre16/sbin, scp to
> /usr/local/stow/openssh-1.2pre16/bin; both programs are then symlinked
> so that they can be found in /usr/local/[s]bin.

I suggest you install the debian package, rather than build it
yourself. You can grab it thus:

apt-get install ssh

Then it'll just work (or you get to report a bug to me ;-)

It shouldn't be too long before 1.2pre17 gets into the
non-us.debian.org archive, but if you're desperate, look here:

http://www.hands.com/~phil/debian/openssh/ssh_1.2pre17-1_i386.deb

Cheers, Phil.

>When I try to use scp from or to a machine that runs openssh-1.2pre16
>on Debian Linux, I keep getting the error message "scp: command not
>found". Executing "ssh this-host echo \$PATH" yields

I worked around this problem by doing

ln -s /usr/local/bin/scp /usr/bin

Perhaps not the most elegant fix, since most people probably expect
that when they do a ssh remote execution, they'll get the same PATH
they'd get if they logged in. Dunno how to do that without rereading
the user's profile each time, though.

--Phil

On 10 Dec 1999 17:50:13 +0000, you wrote:
>I suggest you install the debian package, rather than build it
>yourself. You can grab it thus:
>
> apt-get install ssh
>
>Then it'll just work (or you get to report a bug to me ;-)

Nope. slink here. The binary package depends on libc6.1, the source
package doesn't build because stropts.h is in libc6-dev from potato,
but not in slink's.

Greetings
Marc

--
-------------------------------------- !! No courtesy copies, please !! -----
Marc Haber | " Questions are the | Mailadresse im Header
Karlsruhe, Germany | Beginning of Wisdom " | Fon: *49 721 966 32 15
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fax: *49 721 966 31 29

On Fri, 10 Dec 1999 11:35:01 -0800, you wrote:
>I worked around this problem by doing
>
>ln -s /usr/local/bin/scp /usr/bin
>
>Perhaps not the most elegant fix,

Clumsy and ugly, yes ;-)

I'd only do that if no other solution comes up.

Greetings
Marc

--
-------------------------------------- !! No courtesy copies, please !! -----
Marc Haber | " Questions are the | Mailadresse im Header
Karlsruhe, Germany | Beginning of Wisdom " | Fon: *49 721 966 32 15
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fax: *49 721 966 31 29

Marc.Haber-lists@gmx.de (Marc Haber) writes:

> On 10 Dec 1999 17:50:13 +0000, you wrote:
> >I suggest you install the debian package, rather than build it
> >yourself. You can grab it thus:
> >
> > apt-get install ssh
> >
> >Then it'll just work (or you get to report a bug to me ;-)
>
> Nope. slink here. The binary package depends on libc6.1, the source
> package doesn't build because stropts.h is in libc6-dev from potato,
> but not in slink's.

So how are you building it yourself?

The Debian diff doesn't contain any references to stropts.h, so I've
not introduced that dependency.

If you're having to tweak something to make it build, I'd appreciate it
if you'd apply the same tweak to the debian source and tell me what
needs to be done, because I'd like the debian source to build on slink
too.

Cheers, Phil.

On 13 Dec 1999 17:06:52 +0000, you wrote:
>Marc.Haber-lists@gmx.de (Marc Haber) writes:
>> On 10 Dec 1999 17:50:13 +0000, you wrote:
>> >I suggest you install the debian package, rather than build it
>> >yourself. You can grab it thus:
>> >
>> > apt-get install ssh
>> >
>> >Then it'll just work (or you get to report a bug to me ;-)
>>
>> Nope. slink here. The binary package depends on libc6.1, the source
>> package doesn't build because stropts.h is in libc6-dev from potato,
>> but not in slink's.
>
>So how are you building it yourself?

Looks like that stropts.h reference was included in pre17 and I have
built pre16. The pre17 patch does seem to apply to pre16 as well, with
the exception of some hunks failing in Makefile.in. Unfortunately, the
old patches are not archived on the openssh ftp server.

However, it looks like the debian patched build process needs some
gnome files:
|gcc -g -O2 -Wall -DETCDIR=\"/etc/ssh\" -DSSH_PROGRAM=\"/usr/bin/ssh\" -DSSH_ASKPASS_DEFAULT=\"/usr/lib/ssh/ssh-askpass\" -DHAVE_CONFIG_H `gnome-config --cflags gnome gnomeui` -o gnome-ssh-askpass gnome-ssh-askpass.c `gnome-config --libs gnome gnomeui`
|/bin/sh: gnome-config: command not found
|/bin/sh: gnome-config: command not found
|gnome-ssh-askpass.c:39: gnome.h: No such file or directory
|gnome-ssh-askpass.c:40: X11/Xlib.h: No such file or directory
|gnome-ssh-askpass.c:41: gdk/gdkx.h: No such file or directory
|make[1]: *** [gnome-ssh-askpass] Error 1
|make[1]: Leaving directory `/mnt/main8/home/mh/devel/userspace/openssh-1.2pre17/openssh-1.2pre16'
|make: *** [build-stamp] Error 2
|mh@torres[40/538]:~/devel/userspace/openssh-1.2pre17/openssh-1.2pre16$

Is this imperative? My server system doesn't even have a GUI
installed, so I feel that the compile should go through on minimal
systems as well.

I don't have a clue about libc issues, but I'd really like to see
openssh compiling on systems with older libc versions as well. Is it
very hard to have configure detect older libc versions as well and to
disable features that need 6.1 in that case?

Greetings
Marc

--
-------------------------------------- !! No courtesy copies, please !! -----
Marc Haber | " Questions are the | Mailadresse im Header
Karlsruhe, Germany | Beginning of Wisdom " | Fon: *49 721 966 32 15
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fax: *49 721 966 31 29

Marc.Haber-lists@gmx.de (Marc Haber) writes:

> However, it looks like the debian patched build process needs some
> gnome files:

Just edit the ``--with-gnome-askpass'' out of the ./configure line in
debian/rules

> Is this imperative? My server system doesn't even have a GUI
> installed, so I feel that the compile should go through on minimal
> systems as well.

I have to make it build everything that's available, because it's best
to have it fail with an error than for me to generate an empty
package (it I happen to have removed a required library, say).

Most of what happens during a debian build is equivalent to:

make -f debian/rules build

If it fails on something you don't care about, you can normally get
round it by editing debian/rules

> I don't have a clue about libc issues, but I'd really like to see
> openssh compiling on systems with older libc versions as well. Is it
> very hard to have configure detect older libc versions as well and to
> disable features that need 6.1 in that case?

Try deleting the three lines:

#ifdef HAVE_DEV_PTMX
#include <sys/stropts.h>
#endif /* HAVE_DEV_PTMX */

in pty.c

They're surplus to requirements anyway, since stropts.h is included
again (this time checking if you have it) about 10 lines below.

Cheers, Phil.
--
Boycott Amazon! --- http://linuxtoday.com/stories/13652.html

On Fri, 10 Dec 1999 16:32:28 GMT, you wrote:
>When I try to use scp from or to a machine that runs openssh-1.2pre16
>on Debian Linux, I keep getting the error message "scp: command not
>found". Executing "ssh this-host echo \$PATH" yields
>"/usr/bin:/bin:/usr/sbin:/sbin:" which might be set in config.h.

This issue still hasn't been addressed. I don't have a clue what where
to search.

Greetings
Marc

--
-------------------------------------- !! No courtesy copies, please !! -----
Marc Haber | " Questions are the | Mailadresse im Header
Karlsruhe, Germany | Beginning of Wisdom " | Fon: *49 721 966 32 15
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fax: *49 721 966 31 29

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Fri, 24 Dec 1999, Marc Haber wrote:

> On Fri, 10 Dec 1999 16:32:28 GMT, you wrote:
> >When I try to use scp from or to a machine that runs
> >openssh-1.2pre16 on Debian Linux, I keep getting the error message
> >"scp: command not found". Executing "ssh this-host echo \$PATH"
> >yields "/usr/bin:/bin:/usr/sbin:/sbin:" which might be set in
> >config.h.
>
> This issue still hasn't been addressed. I don't have a clue what
> where to search.

This is a little tricky. When you execute scp, your local copy of
scp executes another instance of scp on the server end.

The remote copy of scp could have been installed anywhere, and
there is little the client could do to the path (it could be
anywhere).

A possible solution would be to hardcode an explicit path at
configure time, but this would only work if the client and the
server were configured the same. I am not keen to include this
kludge. (a more elegant solution would be welcomed, though).

Have you tried editing your /etc/profile (or similar) and simply
including the path to scp in there?

Regards,
Damien Miller

- --
| "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)


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.0 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE4Y+yNormJ9RG1dI8RArBRAJ4211JL8JUlBtZttn6AVQXvumH4GgCgznRk
A4UO3TyMJyRu+5XV/yOZhT4=
=8cf/
-----END PGP SIGNATURE-----

Hmm ... two solutions come to mind:

(1) Allow a configuration item in /etc/ssh/sshd_config to specify the
default PATH for connecting ssh sessions. I'm not so familiar
with the protocol, but it might even be possible to specify
different PATHs for interactive/noninteractive ssh sessions.

(2) Allow a configuration item in ~/.ssh/config to specify a PATH to
pass to the remote shell. The local scp would pass a command
like `env PATH=x:y:z; scp ...' to execute the remote scp. This
is a bit trickier than [1], but does give control to the client.

I'll leave judgments on their elegance to someone besides me. Perhaps
some combination of them would be practical....

--
jim knoble
jmknoble@pobox.com

På 1999-Dec-25 klokka 08:58:33 +1100 skrivet Damien Miller:

: This is a little tricky. When you execute scp, your local copy of
: scp executes another instance of scp on the server end.
:
: The remote copy of scp could have been installed anywhere, and
: there is little the client could do to the path (it could be
: anywhere).
:
: A possible solution would be to hardcode an explicit path at
: configure time, but this would only work if the client and the
: server were configured the same. I am not keen to include this
: kludge. (a more elegant solution would be welcomed, though).
:
: Have you tried editing your /etc/profile (or similar) and simply
: including the path to scp in there?

On Fri, Dec 24, 1999 at 08:44:11PM -0500, Jim Knoble wrote:
> Hmm ... two solutions come to mind:
> [...]

ssh(1) says:
Additionally, ssh reads $HOME/.ssh/environment, and adds lines
of the format ``VARNAME=value'' to the environment.

-markus

On Sat, 25 Dec 1999 08:58:33 +1100 (EST), you wrote:
>A possible solution would be to hardcode an explicit path at
>configure time, but this would only work if the client and the
>server were configured the same. I am not keen to include this
>kludge. (a more elegant solution would be welcomed, though).
>
>Have you tried editing your /etc/profile (or similar) and simply
>including the path to scp in there?

scp is in /usr/local/bin/scp and openssh has been configured with
--prefix=/usr/local/bin/.

_PATH_STDPATH is set to
"/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/sbin:/sbin:", but
executing "ssh this-host echo \$PATH" yields
"/usr/bin:/bin:/usr/sbin:/sbin:". I don't have the slightest idea
where that PATH is pulled from. It neither is the PATH set in the
server config nor the one set by /etc/profile on the server side.

Is that path generated at the client side? In that case, I might have
a problem since the client is a windows box with a pre-compiled
ssh/scp binary. Using the non-free ssh on the server side works.

Greetings
Marc

--
-------------------------------------- !! No courtesy copies, please !! -----
Marc Haber | " Questions are the | Mailadresse im Header
Karlsruhe, Germany | Beginning of Wisdom " | Fon: *49 721 966 32 15
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fax: *49 721 966 31 29

On Fri, 24 Dec 1999 20:44:11 -0500, you wrote:
> (2) Allow a configuration item in ~/.ssh/config to specify a PATH to
> pass to the remote shell. The local scp would pass a command
> like `env PATH=x:y:z; scp ...' to execute the remote scp. This
> is a bit trickier than [1], but does give control to the client.

In quite some cases, the client system isn't under the user's control
and / or runs a ssh version different from openssh. I feel that this
needs to be solved on the server side.

Greetings
Marc

--
-------------------------------------- !! No courtesy copies, please !! -----
Marc Haber | " Questions are the | Mailadresse im Header
Karlsruhe, Germany | Beginning of Wisdom " | Fon: *49 721 966 32 15
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fax: *49 721 966 31 29

On 14 Dec 1999 16:54:43 +0000, you wrote:
>If it fails on something you don't care about, you can normally get
>round it by editing debian/rules

Normally, yes. However, if I configure without gnome-ssh-askpass, it
fails later when it tries to move the compiled file into the
subdirectory structure. I comment that out, and build fails during
dh_movefiles (which doesn't even have a man page). RTFS, delete the
askpass subdirectories in debian, and have build fail even later
because it _needs_ the askpass subdirectories.

Hence, not yet a building debian openssh on my system :-(

Greetings
Marc

--
-------------------------------------- !! No courtesy copies, please !! -----
Marc Haber | " Questions are the | Mailadresse im Header
Karlsruhe, Germany | Beginning of Wisdom " | Fon: *49 721 966 32 15
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fax: *49 721 966 31 29

On Sat, 25 Dec 1999, Marc Haber wrote:


> _PATH_STDPATH is set to
> "/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/sbin:/sbin:", but
> executing "ssh this-host echo \$PATH" yields
> "/usr/bin:/bin:/usr/sbin:/sbin:". I don't have the slightest idea
> where that PATH is pulled from. It neither is the PATH set in the
> server config nor the one set by /etc/profile on the server side.

This path is generated out of the std path from config.h. Perhaps
we should add in something into config.h.in for _STD_PATH to include
the $(bindir) from configure. I just don't have a clue how this
might happen, as I'm not that good at autoconf.

Ben

On Sat, 25 Dec 1999 22:55:16 -0500 (EST), you wrote:
>On Sat, 25 Dec 1999, Marc Haber wrote:
>> _PATH_STDPATH is set to
>> "/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/sbin:/sbin:", but
>> executing "ssh this-host echo \$PATH" yields
>> "/usr/bin:/bin:/usr/sbin:/sbin:". I don't have the slightest idea
>> where that PATH is pulled from. It neither is the PATH set in the
>> server config nor the one set by /etc/profile on the server side.
>
>This path is generated out of the std path from config.h.

This is obviously wrong or I am missing something very basic. See
above. I have hacked config.h so that _PATH_STDPATH _includes_
/usr/local/bin, but this doesn't seem to work.

Greetings
Marc

--
-------------------------------------- !! No courtesy copies, please !! -----
Marc Haber | " Questions are the | Mailadresse im Header
Karlsruhe, Germany | Beginning of Wisdom " | Fon: *49 721 966 32 15
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fax: *49 721 966 31 29

On Sat, 25 Dec 1999 14:43:58 GMT, you wrote:
>_PATH_STDPATH is set to
>"/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/sbin:/sbin:", but
>executing "ssh this-host echo \$PATH" yields
>"/usr/bin:/bin:/usr/sbin:/sbin:". I don't have the slightest idea
>where that PATH is pulled from. It neither is the PATH set in the
>server config nor the one set by /etc/profile on the server side.

In the mean time, I found out that this path comes from
/usr/include/paths.h which is included from config.h (thanks to Jim
Knoble for pointing that out in his Alert article.

I will try later today if preventing that include from happening will
solve the problem.

Greetings
Marc

--
-------------------------------------- !! No courtesy copies, please !! -----
Marc Haber | " Questions are the | Mailadresse im Header
Karlsruhe, Germany | Beginning of Wisdom " | Fon: *49 721 966 32 15
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fax: *49 721 966 31 29

That probably won't work the way you intend. Try the attached patch to
sshd.c instead (against 1.2.1pre21).

--
jim knoble
jmknoble@pobox.com

På 1999-Dec-26 klokka 13:59:08 +0000 skrivet Marc Haber:

: In the mean time, I found out that this path comes from
: /usr/include/paths.h which is included from config.h (thanks to Jim
: Knoble for pointing that out in his Alert article.
:
: I will try later today if preventing that include from happening will
: solve the problem.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Sun, 26 Dec 1999, Marc Haber wrote:

> In the mean time, I found out that this path comes from
> /usr/include/paths.h which is included from config.h (thanks to Jim
> Knoble for pointing that out in his Alert article.
>
> I will try later today if preventing that include from happening
> will solve the problem.

1.2.1pre22 will have a --with-default-path option with which you can
override this.

Damien

- --
| "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)


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.0 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE4Zp9QormJ9RG1dI8RAoMBAJ0X5bqx62+keicwlsZRFRuaBlHx4gCeNNTQ
jrufo/ElsPWNChrUYeUyaHw=
=ETle
-----END PGP SIGNATURE-----

On Mon, 27 Dec 1999 10:05:47 +1100 (EST), you wrote:
>On Sun, 26 Dec 1999, Marc Haber wrote:
>> In the mean time, I found out that this path comes from
>> /usr/include/paths.h which is included from config.h (thanks to Jim
>> Knoble for pointing that out in his Alert article.
>>
>> I will try later today if preventing that include from happening
>> will solve the problem.
>
>1.2.1pre22 will have a --with-default-path option with which you can
>override this.

Is it possible that this option is not currently honored by the
configure script? It shows up in the help, is accepted by configure
|./configure --with-default-path="/usr/local/bin:/usr/bin:/bin:/usr/local/sbin/:/usr/sbin:/sbin",
but the stdpath set in config.h still shows the normal path without
/local and grepping for "/local" over the sources doesn't give hits -
and the compiled sshd still sets the path to what is default.

I feel rather stupid here.

Greetings
Marc

--
-------------------------------------- !! No courtesy copies, please !! -----
Marc Haber | " Questions are the | Mailadresse im Header
Karlsruhe, Germany | Beginning of Wisdom " | Fon: *49 721 966 32 15
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fax: *49 721 966 31 29

On Tue, 28 Dec 1999, Marc Haber wrote:

> Is it possible that this option is not currently honored by the
> configure script? It shows up in the help, is accepted by configure
> |./configure --with-default-path="/usr/local/bin:/usr/bin:/bin:/usr/local/sbin/:/usr/sbin:/sbin",
> but the stdpath set in config.h still shows the normal path without
> /local and grepping for "/local" over the sources doesn't give hits -
> and the compiled sshd still sets the path to what is default.
>
> I feel rather stupid here.

Don't feel stupid. The configure script accepts the --with-default-path
option, but doesn't do anything with it. Since there is now a defines.h
that got broken away from config.h, I suspect that what should happen is
a rule in configure should write something like this to config.h. This
will allow us to override the _PATH_STDPATH if we want to, and not have
it redefined in defines.h if we have defined it.

#if HAVE_DEFAULT_PATH
# if defined (_PATH_STDPATH)
# undef _PATH_STDPATH
# endif
# define _PATH_STDPATH "<configured-path>"
#endif

I haven't figured out autoconf that well yet, so maybe someone who knows
it can hack this into configure.in.

Ben

On Tue, 28 Dec 1999 13:43:10 -0500 (EST), you wrote:
>Don't feel stupid. The configure script accepts the --with-default-path
>option, but doesn't do anything with it.

I see. This needs to be documented or other people will fall into that
trap.

>I haven't figured out autoconf that well yet, so maybe someone who knows
>it can hack this into configure.in.

Just to solve it _now_, can I safely put

#if HAVE_DEFAULT_PATH
# if defined (_PATH_STDPATH)
# undef _PATH_STDPATH
# endif
# define _PATH_STDPATH "_my_path_"
#endif

in config.h without breaking anything? Installing a broken sshd on the
machine in question will result in a 300 km drive :-(

btw, since this list is intended for developers, I believe that slowly
we need a openssh-unix-user mailing list.

Greetings
Marc

--
-------------------------------------- !! No courtesy copies, please !! -----
Marc Haber | " Questions are the | Mailadresse im Header
Karlsruhe, Germany | Beginning of Wisdom " | Fon: *49 721 966 32 15
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fax: *49 721 966 31 29

Marc.Haber-lists@gmx.de (Marc Haber) writes:

> On Tue, 28 Dec 1999 13:43:10 -0500 (EST), you wrote:
> >Don't feel stupid. The configure script accepts the --with-default-path
> >option, but doesn't do anything with it.
>
> I see. This needs to be documented or other people will fall into that
> trap.
>
> >I haven't figured out autoconf that well yet, so maybe someone who knows
> >it can hack this into configure.in.
>
> Just to solve it _now_, can I safely put
>
> #if HAVE_DEFAULT_PATH
> # if defined (_PATH_STDPATH)
> # undef _PATH_STDPATH
> # endif
> # define _PATH_STDPATH "_my_path_"
> #endif
>
> in config.h without breaking anything? Installing a broken sshd on the
> machine in question will result in a 300 km drive :-(

If you kill only the server process, you should be left with the ssh
session(s) on which you have already logged in (This is how the Debian
ssh packages ensure that you can do an upgrade via an ssh session
without cutting your own throat). The server process should have
written its PID into a pid file, the name of which will probably be
revealed by:

strings /usr/sbin/sshd | grep '\.pid'

Once you've done that, you can run a new server, and try logging in
again before you log out on the original session. If that fails, you
can back out by running the old server. Once you've proved it's all
working, you can move the sshd into place in /usr/sbin (or whatever).

If you're paranoid, you can always schedule a reboot in ten minutes
time before you start, so that if you kill your own session at least
things will recover. You'll need to remember to cancel the reboot if
things go well though.

Cheers, Phil.
--
Boycott Amazon! --- http://linuxtoday.com/stories/13652.html