Red Hat Bugzilla – Bug 180332
scponly denies access when winscp compatibility is disabled
Last modified: 2007-11-30 17:11:23 EST
From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322; .NET CLR 2.0.50727)
Description of problem:
My users complained that scp didn't work anymore, from a command line on another linux box to the server on which they have scponly as shell.
I downloaded the lates sources of scponly (4.6), and compiled it. Same problem.
I then recompiled scponly with winscp compatibility option, and the problem was solved.
I think winscp compatibility was enabled by default in prior versions.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1.Create a 'test01' user with /usr/bin/scponly as shell
2.From another box, try scp x firstname.lastname@example.org:/tmp
Actual Results: ssh or scp to target server with user which has scponly as shell gives "Connection to target.machine closed."
Expected Results: should work without having to recompile
When debug level is set to 2:
scponly: 1 arguments in total.
scponly: arg 0 is -scponly
scponly: opened log at LOG_AUTHPRIV, opts 0x00000029
scponly: incorrect number of args
Connection to target.machine closed.
*** Bug 180333 has been marked as a duplicate of this bug. ***
It looks like scp is fully disabled by default despite configure and
documentation saying otherwise in 4.3+. I have upgraded our FE package to 4.6
and enabled scp with the ./configure flag. I don't think enabling the winscp
feature is necessary because the newer version of winscp is supposed to work
without it. It should be pushed to the mirrors later today.