where is sftp-server
mikhail malamud
openssh/bin or openssh/sbin directory. Everything else appears in place. Did
I do somethign wrong during the install or sftp-server is not avaialble for
potable openssh.
Richard E. Silverman
Mikhail> I just compiled openssh-2.5.1p2.tar.gz and I cant see
Mikhail> sftp-server neither in openssh/bin or openssh/sbin
Mikhail> directory. Everything else appears in place. Did I do
Mikhail> somethign wrong during the install or sftp-server is not
Mikhail> avaialble for potable openssh.
It's in my copy of the distribution; I can't imagine why it wouldn't be in
yours...
--
Richard Silverman
sl...@shore.net
D. Stimits
I've been unable to get 2.5.1p2 sftp to function correctly on either RH
6.2 Linux or RH 7.1 beta. What I do have though is that sftp-server is
NOT in a standard search path, so it won't be found with "which". It is
in /usr/libexec/openssh/.
Note that when using sftp in to that machine, from itself or a remote
machine (and I believe it has been configured for use of sftp), I get an
error. Configuration of the tarball:
./configure \
--prefix=/usr \
--sysconfdir=/etc/ssh \
--with-tcp-wrappers \
--with-pam \
--with-ipv4-default \
--with-xauth=/usr/X11R6/bin \
--with-libs=-lcrypt \
--with-md5-passwords
The result appears to be a bug somewhere, reminiscent of an old bug I
read about somewhere about not using the last bit of a key or something
like that. The error I get from "sftp someuser@localhost" is:
Connecting to localhost...
someuser@localhost's password: <password entered>
Received message too long 772436852
This tells me that sftp is broken, or at least something to do with its
interactions with the keys. Can anyone comment on this? Has *anyone*
successfully used sftp-server on a Linux RH 6.2, RH 7.0, or RH 7.1 beta
machine?
D. Stimits, sti...@idcomm.com
Richard E. Silverman
D> The error I get from "sftp someuser@localhost" is: Connecting to
D> localhost... someuser@localhost's password: <password entered>
D> Received message too long 772436852
Try temporarily moving aside any shell startup or login files you have on
the server side (~/.bashrc, ~/.login, etc.).
--
Richard Silverman
sl...@shore.net
D. Stimits
It gets run as user "nobody", which does not have a login shell at all,
and no home directory, thus no ~/anything. One note, I finally got this
sftp to a different RH 6.2 host to work, but I can't sftp from this host
to itself. Something else that might matter, if I recall, the host that
fails had 1024 bit keys generated, whereas the host that it can sftp to
uses default sizes, 768 (or at least I think this is the scheme, rsa
being the key I am thinking of).
D. Stimits, sti...@idcomm.com
Richard E. Silverman
D> Something else that might matter, if I recall, the host that fails
D> had 1024 bit keys generated, whereas the host that it can sftp to
D> uses default sizes, 768 (or at least I think this is the scheme,
D> rsa being the key I am thinking of).
I doubt it has anything to do with key size. The message you're seeing is
coming from sftp-server, not ssh or sshd.
sftp-server is complaining about corrupt input -- which often happens
because of shell startup files inappropriately printing stuff to
stdout/err on non-interactive logins; that's why I made the suggestion.
772436852 translates to ".<newline>st" -- at least conceivably part of
some text string. One thing you could do is to wrap sftp-server in a
script which runs it under strace, dumping the trace output to a file.
Use strace options to capture the I/O buffer contents on all reads and
writes it performs, and see if you can see more of the junk it's getting
and get a clue where it's coming from.
--
Richard Silverman
sl...@shore.net
Josh Willis
script is interfering with scp/sftp: run the command
ssh <your host> /bin/true
and if this produces any output (other than prompting for your password, of
course) then you have a shell start-up script which is producing output for
non-interactive sessions, which is likely confusing sftp.
Josh
--------------------------------------------------------------------------
In article <m1lae6p...@syrinx.oankali.net>,
D. Stimits
Here is the output of "sftp someuser@localhost /dev/true". It appears to
be the output of the user shell, not the output of the server shell. I
have to wonder why it has this problem with /usr/X11R6/bin, it is trying
to *execute* it. I believe the reference to this directory would be for
xauth. FYI, X11Forwading is "yes" in the config file.
~> ssh someuser@localhost /bin/true
someuser@localhost's password:
sh: /usr/X11R6/bin: is a directory
stdin: is not a tty
D. Stimits
>
> Josh Willis wrote:
> >
> > One suggestion from FAQ 2.8 at the OpenSSH website to test whether a shell
> > script is interfering with scp/sftp: run the command
> >
> > ssh <your host> /bin/true
> >
> > and if this produces any output (other than prompting for your password, of
> > course) then you have a shell start-up script which is producing output for
> > non-interactive sessions, which is likely confusing sftp.
> >
> > Josh
> >
> > --------------------------------------------------------------------------
> >
> > In article <m1lae6p...@syrinx.oankali.net>,
> > sl...@shore.net (Richard E. Silverman) writes:
> > >>>>>> "D" == D Stimits <sti...@idcomm.com> writes:
> > >
> > > D> The error I get from "sftp someuser@localhost" is: Connecting to
> > > D> localhost... someuser@localhost's password: <password entered>
> > > D> Received message too long 772436852
> > >
> > >Try temporarily moving aside any shell startup or login files you have on
> > >the server side (~/.bashrc, ~/.login, etc.).
> > >
> > >--
> > > Richard Silverman
> > > sl...@shore.net
>
> Here is the output of "sftp someuser@localhost /dev/true". It appears to
Oops, typo error. It is "sftp someuser@localhost /bin/true". Output was
the same, from an xterm. But this got me thinking about the X11 part, so
I went to a regular console, and instead it gave me:
usage: sftp [-1vC] [-osshopt=value] [user@]host
This machine has only one sftp client ever, there is no possibility of
mixing it up with a prior version. Also, the "which" command tells me
they are the same binary.
Josh Willis
"D. Stimits" <sti...@idcomm.com> writes:
>> >
>> > ssh <your host> /bin/true
>> >
As you might notice, I actually said to type ssh <host> /bin/true, not sftp.
> ^^^
>Oops, typo error. It is "sftp someuser@localhost /bin/true". Output was
>the same, from an xterm. But this got me thinking about the X11 part, so
>I went to a regular console, and instead it gave me:
>usage: sftp [-1vC] [-osshopt=value] [user@]host
This is because you are trying to execute a command, /bin/true, through sftp.
But sftp doesn't execute commands, just ssh. That's why I wrote above to type
'ssh someuser@host /bin/true'. Again, I'm taking this directly from the OpenSSH
FAQ.
>>
>> ~> ssh someuser@localhost /bin/true
>> someuser@localhost's password:
>> sh: /usr/X11R6/bin: is a directory
>> stdin: is not a tty
This last message is the important one: something in your shell startup is
attempting to read input from a terminal. But with sftp (as opposed to ssh) you
should not have any part of your shell startup reading input from a terminal.
The 'sh: /usr/X11R6/bin: is a directory' is probably some other warning message,
but it may still confuse sftp. Does this same message appear when you login
with ssh?
The fix to these is to modify your .bashrc or .cshrc file as appropriate;
something in there is printing out this message and additionaly expecting
terminal input. If some part of your initialization requires terminal input, it
should be made conditional based on whether or not the session is interactive;
see the man page for your shell on how to do this. You should also track down
whatever is printing out the 'is a directory' message; something in your shell
startup tries to do something to a directory (/usr/X11R6/bin) that it should
only do to a regular file. If it should really be attempting to do whatever it
is attempting to do in the first place. I can't tell you what that is because I
don't know what your shell startup does; but the principle you should apply is
to track down whatever is causing that message and do whatever that is
correctly, so that it doesn't generate any warning messages.
Josh
D. Stimits
>
> One possibility: do you have X forwarding turned on? If so, sshd will try
> to run xauth (using the shell, as it does when it runs anything) -- on my
> Linux build of OpenSSH, the path /usr/X11R6/bin/xauth is compiled into
> sshd. Perhaps there's something wrong there.
>
> --
> Richard Silverman
> sl...@shore.net
Yes, X forwarding is on, this was compiled in here as well.
Ok, some progress. I can now sftp in to this box, but it required me to
generate a default size key set (768 bit), and also remove any echo or
output from the shell startup. So there is definitely a bug where sftp
is messing up if a shell has any echo output (user definable echo output
should not be read by sftp, at least it seems like a bad idea for a
security program), and also something causing failure with longer keys.
I can't imagine sftp would die because a shell echoes a welcome or
anything else, but it does (my case is tcsh).
When I turn off X forwarding, the ssh error message changes from the
note that sh tried to exec a directory, to instead:
Warning: Remote host denied X11 forwarding.
(it still works though)
I am beginning to understand that the config options were incorrectly
documented. When it wanted the path to the X11 xauth directory, it
really meant it wanted the full path to the binary file itself, xauth,
and NOT the directory. If that wasn't the intent, then it is a bug in
the runtime forgetting to add the actual xauth name to the path. I'll
have to recompile everything and try again tomorrow.
D. Stimits, sti...@idcomm.com
Richard E. Silverman
D> So there is definitely a bug where sftp is messing up if a shell
D> has any echo output (user definable echo output should not be read
D> by sftp, at least it seems like a bad idea for a security program),
D> ... I can't imagine sftp would die because a shell echoes a welcome
D> or anything else, but it does
The bug is in your shell rc file, not sftp. sftp is not a "security
program;" it's a file-transfer program with no security features
whatsoever. It happens to be bundled with SSH, but that's a matter of
convenience. It derives its security from using SSH to connect to the
sftp server; it has no more specific connection to SSH than, say, rsync or
cvs, which can also be run over SSH.
sftp expects to execute "ssh server-host -s sftp ..." and get a clean pipe
over which to talk to the sftp server. If your shell startup file
generates random garbage intended for humans to read, even on a
non-interactive login when there is no human there to read it, and injects
it into stdout, then it's going to interfere with programs trying to talk
to each other.
The alternative would be for sshd to not use your shell to start programs,
but rather exec them directly. Historically, sysadmins have used the
account shell as a method of access control, so this would be unexpected.
Also, it would remove your ability to customize aspects of command
execution (tweak the path, use command aliases, set the umask, etc.).
The ssh.com SSH2 actually disables reading the shell startup file
specifically when starting subsystems, for this very reason. And as a
fortuituous example of the downside of this, I just answered a question in
another thread here from a woman who was mystified as to why she couldn't
control the umask for file uploads via sftp, even though she had set it in
the shell rc files on the server.
The IETF SSH working group is right now arguing over this issue: whether
the sftp protocol should include a magic cookie feature to try to discard
initial garbage from the connection, and whether that feature should be
part of the general subsystem mechanism or not.
D> I am beginning to understand that the config options were
D> incorrectly documented. When it wanted the path to the X11 xauth
D> directory, it really meant it wanted the full path to the binary
D> file itself, xauth, and NOT the directory.
I don't see that:
% configure --help
...
--with-xauth=PATH Specify path to xauth program
...
--
Richard Silverman
sl...@shore.net
D. Stimits
>
> >>>>> "D" == D Stimits <sti...@idcomm.com> writes:
>
> D> So there is definitely a bug where sftp is messing up if a shell
> D> has any echo output (user definable echo output should not be read
> D> by sftp, at least it seems like a bad idea for a security program),
> D> ... I can't imagine sftp would die because a shell echoes a welcome
> D> or anything else, but it does
>
> The bug is in your shell rc file, not sftp. sftp is not a "security
> program;" it's a file-transfer program with no security features
> whatsoever. It happens to be bundled with SSH, but that's a matter of
> convenience. It derives its security from using SSH to connect to the
> sftp server; it has no more specific connection to SSH than, say, rsync or
> cvs, which can also be run over SSH.
>
> sftp expects to execute "ssh server-host -s sftp ..." and get a clean pipe
> over which to talk to the sftp server. If your shell startup file
> generates random garbage intended for humans to read, even on a
> non-interactive login when there is no human there to read it, and injects
> it into stdout, then it's going to interfere with programs trying to talk
> to each other.
Granted that a non-interactive version should not do this, but I am
using password logins (key without pass, uses system password login).
From this I wonder, is this still true ftp (despite being through ssh),
or is it an emulation? I ask because true ftp does not consult a user's
login shell in the same way that a telnet connection does; sftp is doing
so. It seems that it is using a login shell too early. Regular ftp would
completely ignore a user's login shell, so I suspect this is really a
common telnet style login.
>
> The alternative would be for sshd to not use your shell to start programs,
> but rather exec them directly. Historically, sysadmins have used the
> account shell as a method of access control, so this would be unexpected.
> Also, it would remove your ability to customize aspects of command
> execution (tweak the path, use command aliases, set the umask, etc.).
I suppose ftp has some sort of shell, it really has to, but it isn't the
user controlled shell. I would think that a dedicated ftp shell (not the
user one) would be preferable to either the user's version, or to direct
exec. This would make a very nice feature addition if the sshd_config
had an item that said something like "SFtpForceShell restricted", or
"SFtpForceShell user", to decide what it uses. Very few of my tcsh
commands or path have any effect from sftp anyway. For example, "which"
answers based on the path for the shell, but since it isn't available in
sftp, there is no point to having such a path inherited. Nor aliases. My
choice if offered would be something more like "SftpForceShell
traditional".
>
> The ssh.com SSH2 actually disables reading the shell startup file
> specifically when starting subsystems, for this very reason. And as a
> fortuituous example of the downside of this, I just answered a question in
> another thread here from a woman who was mystified as to why she couldn't
> control the umask for file uploads via sftp, even though she had set it in
> the shell rc files on the server.
>
> The IETF SSH working group is right now arguing over this issue: whether
> the sftp protocol should include a magic cookie feature to try to discard
> initial garbage from the connection, and whether that feature should be
> part of the general subsystem mechanism or not.
If a dedicated shell were used, such as normal ftp seems to use, it
wouldn't matter. If it continues to use user specified shells, I would
think this is a good idea to use a cookie feature.
>
> D> I am beginning to understand that the config options were
> D> incorrectly documented. When it wanted the path to the X11 xauth
> D> directory, it really meant it wanted the full path to the binary
> D> file itself, xauth, and NOT the directory.
>
> I don't see that:
>
> % configure --help
> ...
> --with-xauth=PATH Specify path to xauth program
> ...
I interpreted this (others obviously interpret it otherwise) as
path=directory. It is a matter of semantics I suppose, I would have
phrased it as:
--with-xauth=FULL_PATH_COMMAND
(admittedly, a cumbersome wording)
>
> --
> Richard Silverman
> sl...@shore.net
Richard E. Silverman
D> Just noticed something else that is relevant to this. In the
D> sshd_config file is: ServerKeyBits 768
D> Why is it necessary to set the size of the key file? I can see a
D> reason to set a minimum, but to require an exact statement of size
D> seems odd, since sshd can figure out the keys itself. This is
D> probably why my longer keys were failing.
We haven't yet tried to debug this aspect of the situation. However,
ServerKeyBits has nothing to do with it in any event. That's the size of
the "server key," which is an ephemeral key used during server
authentication; it has nothing to do with the size of keys used for
public-key user authentication.
--
Richard Silverman
sl...@shore.net
D. Stimits
file is:
ServerKeyBits 768
Why is it necessary to set the size of the key file? I can see a reason
to set a minimum, but to require an exact statement of size seems odd,
since sshd can figure out the keys itself. This is probably why my
longer keys were failing.
"D. Stimits" wrote:
>
> Ok, I just verified my suspicious below. I recompiled and in the
> ./configure arguments, it does not want the xauth dir, it wants the full
> path to xauth *including* the file name itself, not a directory. Plus I
> had to use default key sizes, longer keys failed. And I verified that
> the shell echoing a welcome message destroys sftp (which you had
> suggested earlier).
D. Stimits
./configure arguments, it does not want the xauth dir, it wants the full
path to xauth *including* the file name itself, not a directory. Plus I
had to use default key sizes, longer keys failed. And I verified that
the shell echoing a welcome message destroys sftp (which you had
suggested earlier).
Richard E. Silverman
D> Granted that a non-interactive version should not do this, but I am
D> using password logins (key without pass, uses system password
D> login).
The authentication method has nothing to do with whether a login is
"interactive" or not. The usual definition of interactive is that there is
a tty on stdin, which can be yes or no regardless of what authentication
method you use.
D> From this I wonder, is this still true ftp (despite being through
D> ssh), or is it an emulation?
I don't know what you mean by "true ftp." If you're asking whether it is
using the "FTP" protocol, i.e. that described in RFC-959, the answer is
no. The sftp protocol has nothing at all to do with FTP, except that the
purpose of both is to transfer files. Apart from that, they have nothing
in common.
D> I ask because true ftp does not consult a user's login shell in the
D> same way that a telnet connection does; sftp is doing so.
D> It seems that it is using a login shell too early. Regular ftp
D> would completely ignore a user's login shell,
I don't know what you mean by "consult," but actually, most FTP server
implementations require that an account have a shell listed in
/etc/shells.
D> so I suspect this is really a common telnet style login.
I explained this in my last post. What happens is this:
- you run "sftp H"
- sftp runs "ssh H -s sftp ..." in a subprocess. This starts the sftp
on H.
- The sftp client and server converse over the SSH session, using the sftp
protocol.
D> I suppose ftp has some sort of shell, it really has to, but it
D> isn't the user controlled shell. I would think that a dedicated ftp
D> shell (not the user one) would be preferable to either the user's
D> version, or to direct exec...
I don't understand any of this. The issue is, how should sshd start
user-specified programs? There a are pros and cons to using the account
shell versus direct exec. What point would there be in a "dedicated ftp
shell," whatever that means? If it has no features the user can adjust,
what value is there in that as opposed to running programs directly? If
it does have such features, it may just as well be the account shell.
D> If a dedicated shell were used, such as normal ftp seems to use,
"Normal FTP" does nothing analogous to this, since it does not need to
exec the server or any other program when a client connects -- the server
is already running; it simply forks a child process to service this
session.
--
Richard Silverman
sl...@shore.net