[scponly] installation problem

Roland Lammel roland.lammel at kapsch.net
Thu Feb 26 02:24:04 EST 2004


 From the line you add to passwd it seems you are using shadow passwords from
/etc/shadow . So for login authentication to succeed you need to add a line
line to /etc/shadow too (just make it similar to one from above and make
sure it's on the correct line, bascially the same as in passwd).

Best way to add users is to use the Unix's useradd/adduser tools.

Try to do a scp on localhost to the user (first try without pubkey auth, just plain passwd)

Cheers

+rl

Jason Varsoke wrote:
> Hello scponly-ers,
>    I just downloaded and installed (./configure; make; make install)
> scponly 3.9.  There didn't seem to be any way to test it on the local
> machine.
>    I setup a new user on the machine ("sancho" (by adding a line to
> /etc/passwd) 
> 
> backup:x:0:0:BackupProcess:/:/usr/local/bin/scponly
> 
> Then I issused the following from the host "shadowbox"
> 
> $ scp -v bar.txt backup at sancho:/bar.txt
> 
> here's the debug report:
> Executing: program /usr/bin/ssh host sancho, user backup, command scp
> -v -t /bar
> .txt
> OpenSSH_3.6.1p2 Debian 1:3.6.1p2-12, SSH protocols 1.5/2.0, OpenSSL
> 0x0090703f
> debug1: Reading configuration data /etc/ssh/ssh_config
> debug1: Rhosts Authentication disabled, originating port will not be
> trusted.
> debug1: Connecting to sancho [192.168.1.50] port 22.
> debug1: Connection established.
> debug1: identity file /root/.ssh/identity type -1
> debug1: identity file /root/.ssh/id_rsa type -1
> debug1: identity file /root/.ssh/id_dsa type -1
> debug1: Remote protocol version 1.99, remote software version
> OpenSSH_3.5p1
> debug1: match: OpenSSH_3.5p1 pat OpenSSH*
> debug1: Enabling compatibility mode for protocol 2.0
> debug1: Local version string SSH-2.0-OpenSSH_3.6.1p2 Debian
> 1:3.6.1p2-12
> debug1: SSH2_MSG_KEXINIT sent
> debug1: SSH2_MSG_KEXINIT received
> debug1: kex: server->client aes128-cbc hmac-md5 none
> debug1: kex: client->server aes128-cbc hmac-md5 none
> debug1: SSH2_MSG_KEX_DH_GEX_REQUEST sent
> debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
> debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
> debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
> debug1: Host 'sancho' is known and matches the RSA host key.
> debug1: Found key in /root/.ssh/known_hosts:1
> debug1: ssh_rsa_verify: signature correct
> debug1: SSH2_MSG_NEWKEYS sent
> debug1: expecting SSH2_MSG_NEWKEYS
> debug1: SSH2_MSG_NEWKEYS received
> debug1: SSH2_MSG_SERVICE_REQUEST sent
> debug1: SSH2_MSG_SERVICE_ACCEPT received
> debug1: Authentications that can continue: publickey,password
> debug1: Next authentication method: publickey
> debug1: Trying private key: /root/.ssh/identity
> debug1: Trying private key: /root/.ssh/id_rsa
> debug1: read PEM private key done: type RSA
> debug1: Authentication succeeded (publickey).
> debug1: fd 4 setting O_NONBLOCK
> debug1: fd 5 setting O_NONBLOCK
> debug1: fd 6 setting O_NONBLOCK
> debug1: channel 0: new [client-session]
> debug1: Entering interactive session.
> debug1: Sending command: scp -v -t /bar.txt
> debug1: channel 0: request exec
> debug1: channel 0: open confirm rwindow 0 rmax 32768
> debug1: client_input_channel_req: channel 0 rtype exit-status reply 0
> debug1: channel 0: rcvd eof
> debug1: channel 0: output open -> drain
> debug1: channel 0: obuf empty
> debug1: channel 0: close_write
> debug1: channel 0: output drain -> closed
> debug1: channel 0: rcvd close
> debug1: channel 0: close_read
> debug1: channel 0: input open -> closed
> debug1: channel 0: almost dead
> debug1: channel 0: gc: notify user
> debug1: channel 0: gc: user detached
> debug1: channel 0: send close
> debug1: channel 0: is dead
> debug1: channel 0: garbage collecting
> debug1: channel_free: channel 0: client-session, nchannels 1
> debug1: fd 0 clearing O_NONBLOCK
> debug1: fd 1 clearing O_NONBLOCK
> debug1: fd 2 clearing O_NONBLOCK
> debug1: Transferred: stdin 0, stdout 0, stderr 0 bytes in 0.1 seconds
> debug1: Bytes per second: stdin 0.0, stdout 0.0, stderr 0.0
> debug1: Exit status 1
> lost connection
> 
> --cut--
> I have no idea why this didn't work.  The user "backup" has a
> correctly(?) configured key-signon through ssh.  I tested this by
> changing the shell to /bin/bash and correctly got a login shell.  But I
> can't seem to get scponly to work.
> 
> btw: I'm running scponly on SuSE 8.3 kernel 2.4.20.  The client machine
> is running Debian 3.0 2.4.21
> 
> thanks for the help,
> 
> -jason
> 
> __________________________________
> Do you Yahoo!?
> Yahoo! Mail SpamGuard - Read only the mail you want.
> http://antispam.yahoo.com/tools
> 
> _______________________________________________
> scponly mailing list
> scponly at lists.ccs.neu.edu
> https://lists.ccs.neu.edu/bin/listinfo/scponly

-- 
Ing. Roland Lammel | Technical Assistance Services
Kapsch CarrierCom AG | Am Europlatz 5 | 1120 Vienna | Austria
Phone +43 (0)50811 3456 | Mobile +43 664 628 3456 | Fax +43 (0)50811 3405
mailto:roland.lammel at kapsch.net | http://www.kapsch.net





More information about the scponly mailing list