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): scponly-4.3-1 How reproducible: Always Steps to Reproduce: 1.Create a 'test01' user with /usr/bin/scponly as shell 2.From another box, try scp x test01@target.machine:/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 Additional info: When debug level is set to 2: ---8<--8<--- scponly[22776]: 1 arguments in total. scponly[22776]: arg 0 is -scponly scponly[22776]: opened log at LOG_AUTHPRIV, opts 0x00000029 scponly[22776]: incorrect number of args Connection to target.machine closed. ---8<--8<---
*** 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.