Discussion:
SSH commands run as user nobody
(too old to reply)
Timothy Beyer
2012-05-07 09:22:38 UTC
Permalink
Dear List,

All of the remote ssh commands that I execute (pull/push/sync/clone) try to run as the user "nobody". This is a big problem, because I need to make sure that other users on my machine cannot login to the web interface, (eg. I want "nobody" and "anonymous" to have no capabilities) and I want to use my named username of "beyert".

After performing the clone over sshfs, which works fine (although sshfs gives database errors for pull/push/sync), I set the remote-url command as follows:

ssh://beyert@[my-domain]:[my-port]//the/remote/path/scripts.fossil

I have tried every variation of the password notation that I know of, namely:

ssh://beyert@[my-domain]:[my-port]//the/remote/path/scripts.fossil
ssh://beyert:*@[my-domain]:[my-port]//the/remote/path/scripts.fossil
ssh://beyert:[my-password]@[my-domain]:[my-port]//the/remote/path/scripts.fossil

With my secure settings for "nobody" with no capabilities, I get the following error:

"Error: not authorized to read"

I only was able to get the pull/push/sync to work once I gave "nobody" "gio" capabilities, which allowed other users on my machine to see the repository. When I looked at the usage logs, that sync operation was recorded as belonging to user "nobody", whereas all of my other repository commands belong to "beyert".

I don't understand why it isn't using the user "beyert", which has "s" capabilities? I also tried setting the environment variable REMOTE_USER to "beyert", which didn't help.

On both sides, the command "fossil user default" gives "beyert", and my UNIX user on both machines is "beyert".

I'm using FreeBSD 9.0-RELEASE on both machines, with a snapshot from 2012-03-17. Should I use a newer snapshot?

Regards,
Tim
Martin Gagnon
2012-05-07 09:48:54 UTC
Permalink
Post by Timothy Beyer
Dear List,
All of the remote ssh commands that I execute (pull/push/sync/clone) try to run as the user "nobody". This is a big problem, because I need to make sure that other users on my machine cannot login to the web interface, (eg. I want "nobody" and "anonymous" to have no capabilities) and I want to use my named username of "beyert".
"Error: not authorized to read"
I only was able to get the pull/push/sync to work once I gave "nobody" "gio" capabilities, which allowed other users on my machine to see the repository. When I looked at the usage logs, that sync operation was recorded as belonging to user "nobody", whereas all of my other repository commands belong to "beyert".
I don't understand why it isn't using the user "beyert", which has "s" capabilities? I also tried setting the environment variable REMOTE_USER to "beyert", which didn't help.
On both sides, the command "fossil user default" gives "beyert", and my UNIX user on both machines is "beyert".
I'm using FreeBSD 9.0-RELEASE on both machines, with a snapshot from 2012-03-17. Should I use a newer snapshot?
Yes, this as been resolve recently. Now you have all capabilities via ssh, since one which have ssh access can do whatever he want with the .fossil file.
--
Martin G.
Timothy Beyer
2012-05-07 09:54:46 UTC
Permalink
At Mon, 7 May 2012 05:48:54 -0400,
Post by Martin Gagnon
Post by Timothy Beyer
I'm using FreeBSD 9.0-RELEASE on both machines, with a snapshot from 2012-03-17. Should I use a newer snapshot?
Yes, this as been resolve recently. Now you have all capabilities via ssh, since one which have ssh access can do whatever he want with the .fossil file.
--
Martin G.
Thanks! I'll update fossil right away.

Tim
Timothy Beyer
2012-05-07 10:20:31 UTC
Permalink
At Mon, 7 May 2012 05:48:54 -0400,
Post by Martin Gagnon
Yes, this as been resolve recently. Now you have all capabilities via ssh, since one which have ssh access can do whatever he want with the .fossil file.
--
Martin G.
I just tried the version from fossil (2012-05-05 13:53:37 UTC), re-cloned via
sshfs due to the same issues, and then set the remote-url to the appropriate
ssh path, and the "Error: not authorized to read" remains. I also did a
rebuild on the repository.

Tim
Martin Gagnon
2012-05-07 10:51:19 UTC
Permalink
Post by Timothy Beyer
At Mon, 7 May 2012 05:48:54 -0400,
Post by Martin Gagnon
Yes, this as been resolve recently. Now you have all capabilities via ssh, since one which have ssh access can do whatever he want with the .fossil file.
--
Martin G.
I just tried the version from fossil (2012-05-05 13:53:37 UTC), re-cloned via
sshfs due to the same issues, and then set the remote-url to the appropriate
ssh path, and the "Error: not authorized to read" remains. I also did a
rebuild on the repository.
Have you update server side as well?
--
Martin G.
Timothy Beyer
2012-05-07 20:29:46 UTC
Permalink
At Mon, 7 May 2012 06:51:19 -0400,
Post by Martin Gagnon
Have you update server side as well?
Here is the output of fossil version on the server:

This is fossil version 1.22 [7fb59a67dc] 2012-05-05 13:53:37 UTC

Here is the output of fossil version on the client:

This is fossil version 1.22 [7fb59a67dc] 2012-05-05 13:53:37 UTC

I just issued another "fossil all rebuild" on both the client and the server to
make sure that I didn't miss anything.

I am still getting the "Error: not authorized to read" error.

First I tried just rebuilding on the client side, then trying the sync, which
didn't work, giving the same error.

Then I tried closing the repository on the client side, re-cloning under sshfs
again, changing the remote-url (where it prompted me for the password as
normally, then issuing the "fossil sync" command. Basically, it displays the
Sent: packets as it should, then it gives the "Error: not authorized to read",
then it prints the received packets.

In my testing, the sync never actually updated the repository until I gave
"nobody" expanded permissions, in which the latest revisions were updated on
the "timeline" command.

Maybe the fix is in a branch other than "trunk"? Should I try another branch
when installing from the fossil repository?

Possibly unrelated:

Maybe my issue is specific to FreeBSD? I am testing this under /bin/sh shell (I
have my shell even changed to /bin/sh at the moment on the server side to
ensure the proper behavior) because the ssh commands do not work under tcsh at
all...

Tim
Matt Welland
2012-05-07 20:37:39 UTC
Permalink
Regarding ssh transport for fossil: I've been trying to get ssh to work
with fsecure and on Linux (openssh) and I have never had any luck. If
someone using fossil ssh for clone, sync etc. with different user(s) or
different hosts at either end of the pipe could post their exact setup and
settings I will try again as I really need this to work.
Post by Timothy Beyer
At Mon, 7 May 2012 06:51:19 -0400,
Post by Martin Gagnon
Have you update server side as well?
This is fossil version 1.22 [7fb59a67dc] 2012-05-05 13:53:37 UTC
This is fossil version 1.22 [7fb59a67dc] 2012-05-05 13:53:37 UTC
I just issued another "fossil all rebuild" on both the client and the server to
make sure that I didn't miss anything.
I am still getting the "Error: not authorized to read" error.
First I tried just rebuilding on the client side, then trying the sync, which
didn't work, giving the same error.
Then I tried closing the repository on the client side, re-cloning under sshfs
again, changing the remote-url (where it prompted me for the password as
normally, then issuing the "fossil sync" command. Basically, it displays the
Sent: packets as it should, then it gives the "Error: not authorized to read",
then it prints the received packets.
In my testing, the sync never actually updated the repository until I gave
"nobody" expanded permissions, in which the latest revisions were updated on
the "timeline" command.
Maybe the fix is in a branch other than "trunk"? Should I try another branch
when installing from the fossil repository?
Maybe my issue is specific to FreeBSD? I am testing this under /bin/sh shell (I
have my shell even changed to /bin/sh at the moment on the server side to
ensure the proper behavior) because the ssh commands do not work under tcsh at
all...
Tim
_______________________________________________
fossil-users mailing list
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Timothy Beyer
2012-05-07 20:46:05 UTC
Permalink
At Mon, 7 May 2012 13:37:39 -0700,
[1 <multipart/alternative (7bit)>]
[1.1 <text/plain; ISO-8859-1 (7bit)>]
[1.2 <text/html; ISO-8859-1 (quoted-printable)>]
Regarding ssh transport for fossil: I've been trying to get ssh to work with fsecure and on Linux (openssh) and I
have never had any luck. If someone using fossil ssh for clone, sync etc. with different user(s) or different hosts
at either end of the pipe could post their exact setup and settings I will try again as I really need this to work.
Glad to know that I'm not the only one.

Have you had any luck with sshfs? It works very well on my machine for clone
and open, but for sync/pull/push it gives SQLite database errors. If I could
get that working for sync/pull/push, then I would be perfectly happy with just
using sshfs.

Regards,
Tim
Lluís Batlle i Rossell
2012-05-07 20:58:20 UTC
Permalink
Post by Matt Welland
Regarding ssh transport for fossil: I've been trying to get ssh to work
with fsecure and on Linux (openssh) and I have never had any luck. If
someone using fossil ssh for clone, sync etc. with different user(s) or
different hosts at either end of the pipe could post their exact setup and
settings I will try again as I really need this to work.
iirc, fossil can work bad if you have a .bashrc or .bash_profile that outputs
text or things like that. I remember having troubles with this.
Post by Matt Welland
Post by Timothy Beyer
At Mon, 7 May 2012 06:51:19 -0400,
Post by Martin Gagnon
Have you update server side as well?
This is fossil version 1.22 [7fb59a67dc] 2012-05-05 13:53:37 UTC
This is fossil version 1.22 [7fb59a67dc] 2012-05-05 13:53:37 UTC
I just issued another "fossil all rebuild" on both the client and the server to
make sure that I didn't miss anything.
I am still getting the "Error: not authorized to read" error.
First I tried just rebuilding on the client side, then trying the sync, which
didn't work, giving the same error.
Then I tried closing the repository on the client side, re-cloning under sshfs
again, changing the remote-url (where it prompted me for the password as
normally, then issuing the "fossil sync" command. Basically, it displays the
Sent: packets as it should, then it gives the "Error: not authorized to read",
then it prints the received packets.
In my testing, the sync never actually updated the repository until I gave
"nobody" expanded permissions, in which the latest revisions were updated on
the "timeline" command.
Maybe the fix is in a branch other than "trunk"? Should I try another branch
when installing from the fossil repository?
Maybe my issue is specific to FreeBSD? I am testing this under /bin/sh shell (I
have my shell even changed to /bin/sh at the moment on the server side to
ensure the proper behavior) because the ssh commands do not work under tcsh at
all...
Tim
_______________________________________________
fossil-users mailing list
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
_______________________________________________
fossil-users mailing list
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Richard Hipp
2012-05-07 22:23:01 UTC
Permalink
I tried a number of approaches to implementing ssh:. I finally settled on
the following:

(1) Run the "ssh" command using system() to get a shell on the remote
system.
(2) Send an "echo" command and get the reply. Hopefully this will move
past the welcome banner.
(3) Run "fossil http" on the remote side.
(4) Start sending HTTP requests from the local side to the remote, and
accepting replies back.
(5) After the last reply is received, shut down the SSH pipe.

All of the above is pretty fragile based on what flavor of SSH you are
running locally and on the remote, what kind of banner messages are issued
by the remote, how the various SSH implementations handle password
management and authentication, quirks and idiosyncrasies of both systems
and their SSH implementation, etc. It works in many instances, but it is
brittle and there are still issues.

If you have a non-working scenario and can suggest changes to make the
system more robust, then please contribute.
--
D. Richard Hipp
***@sqlite.org
Matt Welland
2012-05-08 17:21:25 UTC
Permalink
Post by Richard Hipp
I tried a number of approaches to implementing ssh:. I finally settled on
(1) Run the "ssh" command using system() to get a shell on the remote
system.
(2) Send an "echo" command and get the reply. Hopefully this will move
past the welcome banner.
(3) Run "fossil http" on the remote side.
(4) Start sending HTTP requests from the local side to the remote, and
accepting replies back.
(5) After the last reply is received, shut down the SSH pipe.
All of the above is pretty fragile based on what flavor of SSH you are
running locally and on the remote, what kind of banner messages are issued
by the remote, how the various SSH implementations handle password
management and authentication, quirks and idiosyncrasies of both systems
and their SSH implementation, etc. It works in many instances, but it is
brittle and there are still issues.
If you have a non-working scenario and can suggest changes to make the
system more robust, then please contribute.
Thanks for the detailed overview. I'll spend some time debugging with this
in mind. Basically I as understand it now the connection is via std in/out
over ssh and any extraneous output from the shell can break things.

What I'm currently seeing is the following:

chlr11723> fossil clone
ssh://host.com/tmp/mrwellan/blah/fossils/test.fossiltest.fossil
ssh -e none -T host.com
ssh: Reflection for Secure IT 6.1.2.1 (build 3005) on x86_64-suse-linux-gnu
(64-bit)
fossil: ssh connection failed: []

But "ssh host.com ls" works fine. I'll do more digging ....
--
Post by Richard Hipp
D. Richard Hipp
_______________________________________________
fossil-users mailing list
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Natacha Porté
2012-05-08 17:41:05 UTC
Permalink
Hello,
Post by Matt Welland
Post by Richard Hipp
I tried a number of approaches to implementing ssh:. I finally settled on
(1) Run the "ssh" command using system() to get a shell on the remote
system.
(2) Send an "echo" command and get the reply. Hopefully this will move
past the welcome banner.
(3) Run "fossil http" on the remote side.
(4) Start sending HTTP requests from the local side to the remote, and
accepting replies back.
(5) After the last reply is received, shut down the SSH pipe.
[...]
[...]
chlr11723> fossil clone
ssh://host.com/tmp/mrwellan/blah/fossils/test.fossiltest.fossil
ssh -e none -T host.com
ssh: Reflection for Secure IT 6.1.2.1 (build 3005) on x86_64-suse-linux-gnu
(64-bit)
fossil: ssh connection failed: []
But "ssh host.com ls" works fine. I'll do more digging ....
You are probably already aware of this, but please note that there are
significant differences between `ssh host command` (like in your last
line) and sending "command" through `ssh host` (like what fossil does).

Among relevant differences are at least that `ssh host command` does not
invoke a shell, sshd's fork invokes exec on the command directly, so
your `ssh host.com ls` runs /bin/ls instead of a shell's builtin ls.
Moreover, by default `ssh host` creates a pty on the remote side, while
`ssh host command` provdes `command` with non-pty-ish file descriptors
for standard I/O.

To be honest, I can't think of any reason to bother with welcome
banners, ptys, shells and their respective init files, except when there
are some important environment variables that *have* to come from remote
side (and cannot come from local side or sshd config).

Of course, I'm not seeing the big picture, so I'm probably missing
something, and I might over-estimate my past bad experiences with pty
and shell layers.


Hoping this helps,
Natacha
Richard Hipp
2012-05-08 17:52:04 UTC
Permalink
Post by Natacha Porté
Hello,
Post by Matt Welland
Post by Richard Hipp
I tried a number of approaches to implementing ssh:. I finally
settled on
Post by Matt Welland
Post by Richard Hipp
(1) Run the "ssh" command using system() to get a shell on the remote
system.
(2) Send an "echo" command and get the reply. Hopefully this will move
past the welcome banner.
(3) Run "fossil http" on the remote side.
(4) Start sending HTTP requests from the local side to the remote, and
accepting replies back.
(5) After the last reply is received, shut down the SSH pipe.
[...]
[...]
chlr11723> fossil clone
ssh://host.com/tmp/mrwellan/blah/fossils/test.fossiltest.fossil
ssh -e none -T host.com
ssh: Reflection for Secure IT 6.1.2.1 (build 3005) on
x86_64-suse-linux-gnu
Post by Matt Welland
(64-bit)
fossil: ssh connection failed: []
But "ssh host.com ls" works fine. I'll do more digging ....
You are probably already aware of this, but please note that there are
significant differences between `ssh host command` (like in your last
line) and sending "command" through `ssh host` (like what fossil does).
Among relevant differences are at least that `ssh host command` does not
invoke a shell, sshd's fork invokes exec on the command directly, so
your `ssh host.com ls` runs /bin/ls instead of a shell's builtin ls.
Moreover, by default `ssh host` creates a pty on the remote side, while
`ssh host command` provdes `command` with non-pty-ish file descriptors
for standard I/O.
To be honest, I can't think of any reason to bother with welcome
banners, ptys, shells and their respective init files, except when there
are some important environment variables that *have* to come from remote
side (and cannot come from local side or sshd config).
Of course, I'm not seeing the big picture, so I'm probably missing
something, and I might over-estimate my past bad experiences with pty
and shell layers.
I wrote that code 18 months ago and I don't remember the details. (One
tends to purge bad experiences from ones memory.) But I seem to recall
that not having a pty caused problems, though I don't remember what those
problems were. Maybe I'm mistaken, though. Trying again to implement "ssh
host command" seems like a worthwhile experiment. (An experiment for
someone else - I have too many other projects going right this moment.)
Maybe I had some unrelated mistake in the code that prevented it from
working on my first attempt.
Post by Natacha Porté
Hoping this helps,
Natacha
_______________________________________________
fossil-users mailing list
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
--
D. Richard Hipp
***@sqlite.org
Lluís Batlle i Rossell
2012-05-08 17:58:36 UTC
Permalink
Post by Richard Hipp
Post by Natacha Porté
Among relevant differences are at least that `ssh host command` does not
invoke a shell, sshd's fork invokes exec on the command directly, so
your `ssh host.com ls` runs /bin/ls instead of a shell's builtin ls.
Moreover, by default `ssh host` creates a pty on the remote side, while
`ssh host command` provdes `command` with non-pty-ish file descriptors
for standard I/O.
I wrote that code 18 months ago and I don't remember the details. (One
tends to purge bad experiences from ones memory.) But I seem to recall
that not having a pty caused problems, though I don't remember what those
problems were. Maybe I'm mistaken, though. Trying again to implement "ssh
host command" seems like a worthwhile experiment. (An experiment for
someone else - I have too many other projects going right this moment.)
Maybe I had some unrelated mistake in the code that prevented it from
working on my first attempt.
fossil uses "ssh -T", which disables pty creation. But it should use "ssh host
command", for the reasons I exposed in the just sent letter. :)

Btw now I'm recalling that I also had troubles with fossil over ssh... I'll try
to remember all the details.

Regards,
Lluís.
Lluís Batlle i Rossell
2012-05-08 18:04:42 UTC
Permalink
Post by Lluís Batlle i Rossell
Btw now I'm recalling that I also had troubles with fossil over ssh... I'll try
to remember all the details.
Ah, found it. All my troubles I had in mind came from this tricky point:
http://www.fossil-scm.org/index.html/tktview?name=115e95ac11 (last comment @
2011-02-16 20:42:19 UTC).

I've been looking at this thread, that had information about fossil and ssh:
http://www.mail-archive.com/fossil-***@lists.fossil-scm.org/msg03727.html

Regards,
Lluís.
Matt Welland
2012-05-08 20:04:08 UTC
Permalink
Post by Lluís Batlle i Rossell
Post by Richard Hipp
Post by Natacha Porté
Among relevant differences are at least that `ssh host command` does
not
Post by Richard Hipp
Post by Natacha Porté
invoke a shell, sshd's fork invokes exec on the command directly, so
your `ssh host.com ls` runs /bin/ls instead of a shell's builtin ls.
Moreover, by default `ssh host` creates a pty on the remote side, while
`ssh host command` provdes `command` with non-pty-ish file descriptors
for standard I/O.
I wrote that code 18 months ago and I don't remember the details. (One
tends to purge bad experiences from ones memory.) But I seem to recall
that not having a pty caused problems, though I don't remember what those
problems were. Maybe I'm mistaken, though. Trying again to implement
"ssh
Post by Richard Hipp
host command" seems like a worthwhile experiment. (An experiment for
someone else - I have too many other projects going right this moment.)
Maybe I had some unrelated mistake in the code that prevented it from
working on my first attempt.
fossil uses "ssh -T", which disables pty creation. But it should use "ssh host
command", for the reasons I exposed in the just sent letter. :)
This is actually what I originally assumed fossil was doing under the hood,
i.e. something like "ssh host fossil http". I'd like to experiment with
that possibility but is it a dead end? I.e. is there some reason why it
will never work?

Thanks,

Matt
-=-

Btw now I'm recalling that I also had troubles with fossil over ssh... I'll
Post by Lluís Batlle i Rossell
try
to remember all the details.
Regards,
Lluís.
_______________________________________________
fossil-users mailing list
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Lluís Batlle i Rossell
2012-05-08 20:09:23 UTC
Permalink
Post by Matt Welland
Post by Lluís Batlle i Rossell
fossil uses "ssh -T", which disables pty creation. But it should use "ssh host
command", for the reasons I exposed in the just sent letter. :)
This is actually what I originally assumed fossil was doing under the hood,
i.e. something like "ssh host fossil http". I'd like to experiment with
that possibility but is it a dead end? I.e. is there some reason why it
will never work?
If I understand all right, it will fail to work for people that put their fossil
binary into "~/bin", and their "~/bin" is loaded only by *login* startup
scripts. And it will fail for people that have stdout messages in their
*non-login* startup scripts.

For the rest, I imagine a single exec of 'fossil http' is enough for the needed
communication. If fossil requires more executions, it should at least run
"ssh host sh", and not "ssh host".

Best regards,
Lluís.
Leo Razoumov
2012-05-08 21:55:38 UTC
Permalink
Post by Lluís Batlle i Rossell
Post by Matt Welland
Post by Lluís Batlle i Rossell
fossil uses "ssh -T", which disables pty creation. But it should use "ssh host
command", for the reasons I exposed in the just sent letter. :)
This is actually what I originally assumed fossil was doing under the hood,
i.e. something like "ssh host fossil http". I'd like to experiment with
that possibility but is it a dead end? I.e. is there some reason why it
will never work?
If I understand all right, it will fail to work for people that put their fossil
binary into "~/bin", and their "~/bin" is loaded only by *login* startup
scripts. And it will fail for people that have stdout messages in their
*non-login* startup scripts.
Not quit right. According to the sshd (8) man page a ssh login
sequence is as follows:

1. If the login is on a tty, and no command has been
specified, prints last login time and
/etc/motd (unless prevented in the configuration file
or by ~/.hushlogin; see the FILES sec‐
tion).
2. If the login is on a tty, records login time.
3. Checks /etc/nologin; if it exists, prints contents and
quits (unless root).
4. Changes to run with normal user privileges.
5. Sets up basic environment.
6. Reads the file ~/.ssh/environment, if it exists, and
users are allowed to change their envi‐
ronment. See the PermitUserEnvironment option in
sshd_config(5).
7. Changes to user's home directory.
8. If ~/.ssh/rc exists, runs it; else if /etc/ssh/sshrc
exists, runs it; otherwise runs xauth.
The “rc” files are given the X11 authentication
protocol and cookie in standard input. See
SSHRC, below.
9. Runs user's shell or command.

You can put modified PATH=$HOME/bin:$PATH into ~/.ssh/environment or
~/.ssh/rc (warning: tricky!) . It will help sshd to find fossil if
the executable is in a non-standard location.

--Leo--
Lluís Batlle i Rossell
2012-05-08 22:09:36 UTC
Permalink
Post by Leo Razoumov
Post by Lluís Batlle i Rossell
Post by Matt Welland
Post by Lluís Batlle i Rossell
fossil uses "ssh -T", which disables pty creation. But it should use "ssh host
command", for the reasons I exposed in the just sent letter. :)
This is actually what I originally assumed fossil was doing under the hood,
i.e. something like "ssh host fossil http". I'd like to experiment with
that possibility but is it a dead end? I.e. is there some reason why it
will never work?
If I understand all right, it will fail to work for people that put their fossil
binary into "~/bin", and their "~/bin" is loaded only by *login* startup
scripts. And it will fail for people that have stdout messages in their
*non-login* startup scripts.
Not quit right. According to the sshd (8) man page a ssh login
9. Runs user's shell or command.
If I add "echo a" at the top of my .bashrc, I see this:

$ ssh localhost echo 1
a
1

And I can run "ssh localhost ulimit" fine. So ssh does not run the user command,
but the user shell + its rc script + command.

If it where not so, it wouldn't be possible to run: ssh host "cat < file"

But I don't know why the sshd man page does not say that though. :)

Regards,
Lluís.
Leo Razoumov
2012-05-08 22:57:02 UTC
Permalink
Post by Lluís Batlle i Rossell
Post by Leo Razoumov
Not quit right. According to the sshd (8) man page a ssh login
           9.   Runs user's shell or command.
$ ssh localhost echo 1
a
1
And I do not see the extra "a" because I have the following line in
the beginning of my ~/.bashrc

# If not running interactively, don't do anything
[ -z "$PS1" ] && return


Since your ~/.bashrc gets executed you can set correct PATH from
there. Either way, I think that "ssh host command" is a more natural
way than getting login shell and I don't mind to tweak my
~/.ssh/environment if needed.

--Leo--
Lluís Batlle i Rossell
2012-05-09 09:25:03 UTC
Permalink
Post by Leo Razoumov
And I do not see the extra "a" because I have the following line in
the beginning of my ~/.bashrc
# If not running interactively, don't do anything
[ -z "$PS1" ] && return
I said the *top* of my .bashrc ;)

Regards,
Lluís.
Leo Razoumov
2012-05-09 23:43:56 UTC
Permalink
Post by Lluís Batlle i Rossell
And I do not see the extra "a"  because I have the following line in
the beginning of my ~/.bashrc
# If not running interactively, don't do anything
[ -z "$PS1" ] && return
I said the *top* of my .bashrc ;)
Regards,
Lluís.
Lluis,
the whole discussion is about how to suppress unwanted output stemming
from ~/.bashrc exectution (I agree, sshd man page is wrong) when "ssh
host command" is called. Checking for "$PS1" is a very simple way to
achieve this.

--Leo--

Martin Gagnon
2012-05-09 02:06:15 UTC
Permalink
Post by Lluís Batlle i Rossell
Post by Leo Razoumov
Post by Lluís Batlle i Rossell
Post by Matt Welland
Post by Lluís Batlle i Rossell
fossil uses "ssh -T", which disables pty creation. But it should use "ssh
host
command", for the reasons I exposed in the just sent letter. :)
This is actually what I originally assumed fossil was doing under the hood,
i.e. something like "ssh host fossil http". I'd like to experiment with
that possibility but is it a dead end? I.e. is there some reason why it
will never work?
If I understand all right, it will fail to work for people that put their fossil
binary into "~/bin", and their "~/bin" is loaded only by *login* startup
scripts. And it will fail for people that have stdout messages in their
*non-login* startup scripts.
Not quit right. According to the sshd (8) man page a ssh login
9. Runs user's shell or command.
$ ssh localhost echo 1
a
1
And I can run "ssh localhost ulimit" fine. So ssh does not run the user command,
but the user shell + its rc script + command.
If it where not so, it wouldn't be possible to run: ssh host "cat < file"
But I don't know why the sshd man page does not say that though. :)
This is for bash... But for ksh (default on OpenBSD and QNX for
instance) any echo on .kshrc or on .profile will *not* appear when
doing: "ssh host command" neither with "ssh -T host command".

There's a chance that sshd manpage expect ksh behavior since openssh is
developped by OpenBSD crowd and their system use ksh by default..
--
Martin G.
Lluís Batlle i Rossell
2012-05-09 09:26:43 UTC
Permalink
Post by Martin Gagnon
Post by Lluís Batlle i Rossell
Post by Leo Razoumov
9. Runs user's shell or command.
But I don't know why the sshd man page does not say that though. :)
This is for bash... But for ksh (default on OpenBSD and QNX for
instance) any echo on .kshrc or on .profile will *not* appear when
doing: "ssh host command" neither with "ssh -T host command".
There's a chance that sshd manpage expect ksh behavior since openssh is
developped by OpenBSD crowd and their system use ksh by default..
Ah very interesting.
And can you run: ssh host "cat < ~/.kshrc"
?

If so, it would mean the command is run by ksh, and not by sshd.

Regards,
Lluís.
Natacha Porté
2012-05-09 09:58:17 UTC
Permalink
Hello,
Post by Lluís Batlle i Rossell
Post by Martin Gagnon
Post by Lluís Batlle i Rossell
Post by Leo Razoumov
9. Runs user's shell or command.
But I don't know why the sshd man page does not say that though. :)
This is for bash... But for ksh (default on OpenBSD and QNX for
instance) any echo on .kshrc or on .profile will *not* appear when
doing: "ssh host command" neither with "ssh -T host command".
There's a chance that sshd manpage expect ksh behavior since openssh is
developped by OpenBSD crowd and their system use ksh by default..
Ah very interesting.
And can you run: ssh host "cat < ~/.kshrc"
?
If so, it would mean the command is run by ksh, and not by sshd.
Why resort to dubious experimentation when code source is available?
Truth lies in the source code. I gather the relevant code is at the end
of do_child() from session.c

/*
* If we have no command, execute the shell. In this case, the shell
* name to be passed in argv[0] is preceded by '-' to indicate that
* this is a login shell.
*/
if (!command) {
[...]
execve(shell, argv, env);
[...]
perror(shell);
exit(1);
}
/*
* Execute the command using the user's shell. This uses the -c
* option to execute the command.
*/
argv[0] = (char *) shell0;
argv[1] = "-c";
argv[2] = (char *) command;
argv[3] = NULL;
execve(shell, argv, env);
perrror(shell);
exit(1);
}


Greping across the source for `exec[a-z ]*(` provides with few enough
results to check them all; but the code flow for `ssh host command` is
quite simple, jumping from client code to server code through a
grep '"exec"'.


So I admit I was wrong, as far as I can tell `ssh host command` does
spawn a shell. I guess I was misled by my own dubious experimentation:
`ssh host pstree` showed pstree as a direct child of sshd, but it seems
my shell (zsh) uses exec() to run pstree, while sh and tcsh don't (and
so appear between sshd and pstree).

However I have no idea about the behavior of bash or ksh with regard to
banners or startup scripts.


Hoping this helps,
Natacha
Lluís Batlle i Rossell
2012-05-09 10:12:47 UTC
Permalink
Post by Natacha Porté
Hello,
Post by Lluís Batlle i Rossell
Post by Martin Gagnon
Post by Lluís Batlle i Rossell
Post by Leo Razoumov
9. Runs user's shell or command.
But I don't know why the sshd man page does not say that though. :)
This is for bash... But for ksh (default on OpenBSD and QNX for
instance) any echo on .kshrc or on .profile will *not* appear when
doing: "ssh host command" neither with "ssh -T host command".
There's a chance that sshd manpage expect ksh behavior since openssh is
developped by OpenBSD crowd and their system use ksh by default..
Ah very interesting.
And can you run: ssh host "cat < ~/.kshrc"
?
If so, it would mean the command is run by ksh, and not by sshd.
So I admit I was wrong, as far as I can tell `ssh host command` does
`ssh host pstree` showed pstree as a direct child of sshd, but it seems
my shell (zsh) uses exec() to run pstree, while sh and tcsh don't (and
so appear between sshd and pstree).
Thank you for the source, Natacha. Nevertheless, notice that the tarballs are
different for openbsd and linux (portable). What did you look at? :)
Post by Natacha Porté
However I have no idea about the behavior of bash or ksh with regard to
banners or startup scripts.
I imagined it run the '-c', but I'm was confused why openssh runs the .bashrc
now, because if I add 'echo a' to the top of .bashrc, I don't see it when I run
"bash -c 'echo 1'" locally.

But the bash manpage clarifies this "cleverness":
Bash attempts to determine when it is being run with its standard input
connected to a network connection, as when executed by the remote shell daemon,
usually rshd, or the secure shell daemon sshd. If bash deter‐ mines it is
being run in this fashion, it reads and executes commands from ~/.bashrc, if
that file exists and is readable. It will not do this if invoked as sh.

As for ksh, in its manpage
http://www.rdg.ac.uk:8081/cgi-bin/cgiwrap/wsi14/poplog/man/1/ksh
I read that it runs always the scripts in the ENV variable, and the .profile
kind of scripts only if run as a login shell. This coincides with what bash
names "posix mode", and bash behaves that way too if enabling its posix mode.

Regards,
Lluís.
Natacha Porté
2012-05-09 10:31:53 UTC
Permalink
Post by Lluís Batlle i Rossell
Post by Natacha Porté
So I admit I was wrong, as far as I can tell `ssh host command` does
`ssh host pstree` showed pstree as a direct child of sshd, but it seems
my shell (zsh) uses exec() to run pstree, while sh and tcsh don't (and
so appear between sshd and pstree).
Thank you for the source, Natacha. Nevertheless, notice that the tarballs are
different for openbsd and linux (portable). What did you look at? :)
I checked on the sources on my own systems (FreeBSD 7 and FreeBSD 9),
since that's where I performed my experimentations, and I included the
location for other to search in the source of the binaries running in
their own systems as well. I don't expect porting to change such a
behavior though.

Anyway, for completeness, I have just downloaded OpenSSH tarballs v6.0
for OpenBSD and the portable version ("6.0p1"). The relevant code I
copied earlier is exactly the same in all the four versions I checked.


Natacha
Richard Hipp
2012-05-08 20:21:17 UTC
Permalink
Post by Matt Welland
This is actually what I originally assumed fossil was doing under the
hood, i.e. something like "ssh host fossil http". I'd like to experiment
with that possibility but is it a dead end? I.e. is there some reason why
it will never work?
There is no fundamental reason why what you say can't work. I just had
trouble getting it to work. You are welcomed to try it yourself. All of
the relevant code is in the "http_transport.c" source file. Search for
"g.urlIsSsh" to locate the relevant bits of code. It is not very
complicated. I welcome your patches if you can come up with a better
mechanism.
--
D. Richard Hipp
***@sqlite.org
Lluís Batlle i Rossell
2012-05-08 17:56:40 UTC
Permalink
Post by Natacha Porté
Post by Matt Welland
Post by Richard Hipp
I tried a number of approaches to implementing ssh:. I finally settled on
(1) Run the "ssh" command using system() to get a shell on the remote
system.
(2) Send an "echo" command and get the reply. Hopefully this will move
past the welcome banner.
(3) Run "fossil http" on the remote side.
(4) Start sending HTTP requests from the local side to the remote, and
accepting replies back.
(5) After the last reply is received, shut down the SSH pipe.
[...]
[...]
chlr11723> fossil clone
ssh://host.com/tmp/mrwellan/blah/fossils/test.fossiltest.fossil
ssh -e none -T host.com
ssh: Reflection for Secure IT 6.1.2.1 (build 3005) on x86_64-suse-linux-gnu
(64-bit)
fossil: ssh connection failed: []
But "ssh host.com ls" works fine. I'll do more digging ....
You are probably already aware of this, but please note that there are
significant differences between `ssh host command` (like in your last
line) and sending "command" through `ssh host` (like what fossil does).
Among relevant differences are at least that `ssh host command` does not
invoke a shell, sshd's fork invokes exec on the command directly, so
your `ssh host.com ls` runs /bin/ls instead of a shell's builtin ls.
Moreover, by default `ssh host` creates a pty on the remote side, while
`ssh host command` provdes `command` with non-pty-ish file descriptors
for standard I/O.
To be honest, I can't think of any reason to bother with welcome
banners, ptys, shells and their respective init files, except when there
are some important environment variables that *have* to come from remote
side (and cannot come from local side or sshd config).
Hello Natacha,

I think the broadly used approach is that 'ssh host command' is not meant to
provide a login shell, while 'ssh host' should. A login shell distinguishes
several details, as could be interactivity, utmp entries, motd, ssh-agents, ...

But most relevant for this case, is that a login shell runs ".bash_profile", and
a non-login shell runs ".bashrc". non-interactive sessions should use non-login
shells, and .bashrc should never output strings to stdout/stderr.
".bash_profile", meant for login shells, can show you the monthly calendar on
stdout for example.

A common source of confusion, I think, is that 'xterm' by default does not
create login shells. And then some people that want messages at shell start make
their .bashrc show text on stdout, while this breaks any software using "ssh
host command" instructions. If you want text appearing at your xterm spawn, you
should configure your .Xdefaults with XTerm*loginShell: true, or call xterm with
"-ls".

That said, fossil should not do "ssh host", without command, because that's
meant to produce text for humans that fossil may fail to parse.

Regards,
Lluís.
Stephan Beal
2012-05-08 18:14:16 UTC
Permalink
Post by Lluís Batlle i Rossell
But most relevant for this case, is that a login shell runs
".bash_profile", and
a non-login shell runs ".bashrc". non-interactive sessions should use non-login
Slight correction - that's only for /bin/bash. Not everyone uses bash and
not all platforms default to it (e.g. solaris).

That said, fossil should not do "ssh host", without command, because that's
Post by Lluís Batlle i Rossell
meant to produce text for humans that fossil may fail to parse.
It's also used as a way of calling local scripts on remote hosts:

cat foo.sh | ssh host

vs:

cat foo.sh | ssh host 'cat > foo.sh; bash foo.sh'

vs scp + ssh
--
----- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal
Lluís Batlle i Rossell
2012-05-08 18:37:49 UTC
Permalink
Post by Stephan Beal
Post by Lluís Batlle i Rossell
But most relevant for this case, is that a login shell runs
".bash_profile", and
a non-login shell runs ".bashrc". non-interactive sessions should use non-login
Slight correction - that's only for /bin/bash. Not everyone uses bash and
not all platforms default to it (e.g. solaris).
Well, I imagine every shell has that clear distinction. In any case, there is
/etc/profile, ~/.profile, additional to ~/.bash_profile.

zsh does something similar on ~/.profile
csh/tcsh do the same: .tcshrc/.cshrc vs .login
Post by Stephan Beal
That said, fossil should not do "ssh host", without command, because that's
Post by Lluís Batlle i Rossell
meant to produce text for humans that fossil may fail to parse.
cat foo.sh | ssh host
It can work for most cases... unless your 'profile' script asks you for a
password :) But people mostly add output text to .bash_profile, jkkkkkkkkkkkkkk
cat foo.sh | ssh host | sort # Trying to use the output may be worse.

You should run:
cat foo.sh | ssh host sh | sort
Timothy Beyer
2012-05-09 00:18:40 UTC
Permalink
Dear list,

Here is a really ugly hack that fixed my problem for clone and pull/push/sync
trying to execute as "nobody". I elevate privileges to "s" in order to perform
each operation. Not sure if this is safe, but it works well enough for my
usage at the moment.

I think the reason why no one else has seen this problem is because I set
anonymous and nobody to have no privileges at all. (which I deem essential for
certain private repositories that I work on, such as for my /etc directory)

I know this patch is probably very dangerous, but it is here if anyone else
experiences this problem with ssh protocol support.

Any critiques are welcome. It isn't high quality enough for me to make a
branch, but if people are interested, I could try to polish it for inclusion.

--- src/xfer.c.orig 2012-05-07 03:02:24.000000000 -0700
+++ src/xfer.c 2012-05-08 17:11:00.000000000 -0700
@@ -860,6 +860,8 @@
}
g.zLogin = "anonymous";
login_set_anon_nobody_capabilities();
+ /* doesn't work here, not sure why..*/
+ /* login_set_capabilities("s", 0); */
login_check_credentials();
memset(&xfer, 0, sizeof(xfer));
blobarray_zero(xfer.aToken, count(xfer.aToken));
@@ -992,6 +994,10 @@
nErr++;
break;
}
+ /* this is actually needed here */
+ /* not high enough capabilities to run gimme */
+ /* login_set_capabilities("gio", 0); */
+ login_set_capabilities("s", 0);
login_check_credentials();
if( blob_eq(&xfer.aToken[0], "pull") ){
if( !g.perm.Read ){
@@ -1022,6 +1028,8 @@
*/
if( blob_eq(&xfer.aToken[0], "clone") ){
int iVers;
+ /* this is actually needed here to clone */
+ login_set_capabilities("s", 0);
login_check_credentials();
if( !g.perm.Clone ){
cgi_reset_content();
Continue reading on narkive:
Loading...