scponly, allowing sftp and denying ssh access - SSH

This is a discussion on scponly, allowing sftp and denying ssh access - SSH ; We want to restrict a bunch of users to ftp/sftp access only and deny shell access on a Solaris 10 system. The old trick used for restricting traditional FTP access only was to assign users the shell /bin/false. That won't ...

+ Reply to Thread
Results 1 to 4 of 4

Thread: scponly, allowing sftp and denying ssh access

  1. scponly, allowing sftp and denying ssh access

    We want to restrict a bunch of users to ftp/sftp access only and deny
    shell access on a Solaris 10 system.

    The old trick used for restricting traditional FTP access only was to
    assign users the shell /bin/false. That won't work for ssh and sftp.

    I've read a few posts about using "scponly" as a default user shell
    which prohibits user shell access but allows sftp and ftp access. A
    December 2005 security advisory mentioned that scponly had a security
    problem passing shell arguments thereby allowing a root compromise. The
    alert suggested upgrading to version 4.3 (?).

    Does anyone have experience with scponly or have other recommendations
    for restricting shell access on Solaris 10? We don'twant to create
    individual RBAC user profiles but would consider assigning all these
    users a common shell in /etc/passwd.

    Thanks.

    matthew black
    california state university


  2. Re: scponly, allowing sftp and denying ssh access

    lb.centaur@gmail.com wrote:
    > We want to restrict a bunch of users to ftp/sftp access only and deny
    > shell access on a Solaris 10 system.
    >
    > The old trick used for restricting traditional FTP access only was to
    > assign users the shell /bin/false. That won't work for ssh and sftp.
    >
    > I've read a few posts about using "scponly" as a default user shell
    > which prohibits user shell access but allows sftp and ftp access. A
    > December 2005 security advisory mentioned that scponly had a security
    > problem passing shell arguments thereby allowing a root compromise. The
    > alert suggested upgrading to version 4.3 (?).
    >
    > Does anyone have experience with scponly or have other recommendations
    > for restricting shell access on Solaris 10? We don'twant to create
    > individual RBAC user profiles but would consider assigning all these
    > users a common shell in /etc/passwd.
    >
    > Thanks.
    >
    > matthew black
    > california state university
    >


    Put this in the /etc/profile script...

    #Disable psoft user direct log in

    WHO=`who am i | awk ' { print $1 } '`
    if [ "${WHO}" = "userid" ]; then
    exit
    fi

    --
    To reply by email remove "_nospam"

  3. Re: scponly, allowing sftp and denying ssh access


    wrote in message
    news:1138213793.038447.40970@o13g2000cwo.googlegro ups.com...
    > We want to restrict a bunch of users to ftp/sftp access only and deny
    > shell access on a Solaris 10 system.


    Don't bother. If you need secret upload as well as download, install an
    Apache server with WebDAV enabled, and use the built-in user account
    management features of Apache. That way, not only can you mount the WebDAV
    filesystem on many OS's, but you can access it with just about every major
    browser, and do uploads with the built-in tools of most OS's rather than
    relying on your users to correctly manage an FTP/SFTP client.

    > Does anyone have experience with scponly or have other recommendations
    > for restricting shell access on Solaris 10? We don'twant to create
    > individual RBAC user profiles but would consider assigning all these
    > users a common shell in /etc/passwd.


    See above. It's easy to manage.



  4. Re: scponly, allowing sftp and denying ssh access

    In article Chuck
    writes:
    >
    >Put this in the /etc/profile script...
    >
    >#Disable psoft user direct log in
    >
    >WHO=`who am i | awk ' { print $1 } '`
    >if [ "${WHO}" = "userid" ]; then
    > exit
    >fi


    Which is easily circumvented by 'ssh somehost sh -i' or a gazillion
    other ways to get a shell without sourcing /etc/profile.

    --Per Hedeland
    per@hedeland.org

+ Reply to Thread