Re: passwordless scp and cronjobs
> Date: Fri, 04 Oct 2002 13:31:56 -0400 > From: Gerard Samuel <[EMAIL PROTECTED]> > Sender: [EMAIL PROTECTED] > > A few months ago, I had a cron job scp a file to another box within my > lan. It worked great and things were good. > I dont remember why I turned it off, but Im trying to set it back up. > Both boxes are running FBSD 4.6.2-Release. > On the sending box -> > 1. ssh-keygen -t rsa //Accept the defaults and leave the passphrase empty. > 2. scp id_rsa.pub sys_dev@hivemind: //SCP the public key over to the > recieving box to the user who is going to recieve the file from the cron > job. > > On the recieving box -> > 1. cp id_rsa.pub .ssh/authorized_keys2 // Copy the sender's public key > to .ssh/authorized_keys2 > > From the sending box, I run my script using the -v option to scp to be > verbose. > Here is the output of the script -> > > Executing: program /usr/bin/ssh host hivemind, user sys_dev, command scp > -v -t . > OpenSSH_3.4p1 FreeBSD-20020702, SSH protocols 1.5/2.0, OpenSSL 0x0090605f > debug1: Reading configuration data /etc/ssh/ssh_config > debug1: Applying options for * > debug1: Rhosts Authentication disabled, originating port will not be > trusted. > debug1: ssh_connect: needpriv 0 > debug1: Connecting to hivemind.trini0.org [192.168.0.2] port 22. > debug1: Connection established. > debug1: identity file /home/gsam/.ssh/identity type -1 > debug1: identity file /home/gsam/.ssh/id_rsa type 1 > debug1: identity file /home/gsam/.ssh/id_dsa type -1 > debug1: Remote protocol version 1.99, remote software version > OpenSSH_3.4p1 FreeBSD-20020702 > debug1: match: OpenSSH_3.4p1 FreeBSD-20020702 pat OpenSSH* > debug1: Local version string SSH-1.5-OpenSSH_3.4p1 FreeBSD-20020702 > debug1: Waiting for server public key. > debug1: Received server public key (768 bits) and host key (1024 bits). > debug1: Host 'hivemind.trini0.org' is known and matches the RSA1 host key. > debug1: Found key in /home/gsam/.ssh/known_hosts:1 > debug1: Encryption type: 3des > debug1: Sent encrypted session key. > debug1: cipher_init: set keylen (16 -> 32) > debug1: cipher_init: set keylen (16 -> 32) > debug1: Installing crc compensation attack detector. > debug1: Received encrypted confirmation. > debug1: Doing password authentication. > [EMAIL PROTECTED]'s password: > -- > > Could someone point out to me where Im going wrong with this to have the > cron job complete successfully without entering a password. > Thanks. The most obvious thing is that you generated SSH V2 RSA keys, but the connection in the example used SSH V1 and is only interested in V1 keys. Check the "Protocol" line in $HOME/.ssh/config and/or /etc/ssh/ssh_config on the client side and /etc/ssh/sshd_config on the server side and make sure both use V2. You can force SSH V2 with -oProtocol=2 on the command line according to the man page. I have not tried this. R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: [EMAIL PROTECTED] Phone: +1 510 486-8634 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-questions" in the body of the message
Re: passwordless scp and cronjobs
I started the whole process again and added the SSH2 option to the command line which now looks like this -> scp -o 'Protocol=2' -v ~/temp/file.zip sys_dev@hivemind: Towards the bottom you'll see its trying authentication methods, using the public key as the first option. I would tend to believe if all were well, it shouldn't have to go past that point. Ill try messing around some more with the ssh options and report back. Thanks Here is the output of the ssh debug -> Executing: program /usr/bin/ssh host hivemind, user sys_dev, command scp -v -t . OpenSSH_3.4p1 FreeBSD-20020702, SSH protocols 1.5/2.0, OpenSSL 0x0090605f debug1: Reading configuration data /etc/ssh/ssh_config debug1: Applying options for * debug1: Rhosts Authentication disabled, originating port will not be trusted. debug1: ssh_connect: needpriv 0 debug1: Connecting to hivemind.trini0.org [192.168.0.2] port 22. debug1: Connection established. debug1: identity file /home/gsam/.ssh/id_rsa type 1 debug1: identity file /home/gsam/.ssh/id_dsa type -1 debug1: Remote protocol version 1.99, remote software version OpenSSH_3.4p1 FreeBSD-20020702 debug1: match: OpenSSH_3.4p1 FreeBSD-20020702 pat OpenSSH* Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_3.4p1 FreeBSD-20020702 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: dh_gen_key: priv key bits set: 121/256 debug1: bits set: 1602/3191 debug1: SSH2_MSG_KEX_DH_GEX_INIT sent debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY debug1: Host 'hivemind.trini0.org' is known and matches the DSA host key. debug1: Found key in /home/gsam/.ssh/known_hosts:6 debug1: bits set: 1573/3191 debug1: ssh_dss_verify: signature correct debug1: kex_derive_keys debug1: newkeys: mode 1 debug1: SSH2_MSG_NEWKEYS sent debug1: waiting for SSH2_MSG_NEWKEYS debug1: newkeys: mode 0 debug1: SSH2_MSG_NEWKEYS received debug1: done: ssh_kex2. debug1: send SSH2_MSG_SERVICE_REQUEST debug1: service_accept: ssh-userauth debug1: got SSH2_MSG_SERVICE_ACCEPT debug1: authentications that can continue: publickey,password,keyboard-interactive debug1: next auth method to try is publickey debug1: try pubkey: /home/gsam/.ssh/id_rsa debug1: authentications that can continue: publickey,password,keyboard-interactive debug1: try privkey: /home/gsam/.ssh/id_dsa debug1: next auth method to try is keyboard-interactive Password: Kevin Oberman wrote: >>Date: Fri, 04 Oct 2002 13:31:56 -0400 >>From: Gerard Samuel <[EMAIL PROTECTED]> >>Sender: [EMAIL PROTECTED] >> >>A few months ago, I had a cron job scp a file to another box within my >>lan. It worked great and things were good. >>I dont remember why I turned it off, but Im trying to set it back up. >>Both boxes are running FBSD 4.6.2-Release. >>On the sending box -> >>1. ssh-keygen -t rsa //Accept the defaults and leave the passphrase empty. >>2. scp id_rsa.pub sys_dev@hivemind: //SCP the public key over to the >>recieving box to the user who is going to recieve the file from the cron >>job. >> >>On the recieving box -> >>1. cp id_rsa.pub .ssh/authorized_keys2 // Copy the sender's public key >>to .ssh/authorized_keys2 >> >> From the sending box, I run my script using the -v option to scp to be >>verbose. >>Here is the output of the script -> >> >>Executing: program /usr/bin/ssh host hivemind, user sys_dev, command scp >>-v -t . >>OpenSSH_3.4p1 FreeBSD-20020702, SSH protocols 1.5/2.0, OpenSSL 0x0090605f >>debug1: Reading configuration data /etc/ssh/ssh_config >>debug1: Applying options for * >>debug1: Rhosts Authentication disabled, originating port will not be >>trusted. >>debug1: ssh_connect: needpriv 0 >>debug1: Connecting to hivemind.trini0.org [192.168.0.2] port 22. >>debug1: Connection established. >>debug1: identity file /home/gsam/.ssh/identity type -1 >>debug1: identity file /home/gsam/.ssh/id_rsa type 1 >>debug1: identity file /home/gsam/.ssh/id_dsa type -1 >>debug1: Remote protocol version 1.99, remote software version >>OpenSSH_3.4p1 FreeBSD-20020702 >>debug1: match: OpenSSH_3.4p1 FreeBSD-20020702 pat OpenSSH* >>debug1: Local version string SSH-1.5-OpenSSH_3.4p1 FreeBSD-20020702 >>debug1: Waiting for server public key. >>debug1: Received server public key (768 bits) and host key (1024 bits). >>debug1: Host 'hivemind.trini0.org' is known and matches the RSA1 host key. >>debug1: Found key in /home/gsam/.ssh/known_hosts:1 >>debug1: Encryption type: 3des >>debug1: Sent encrypted session key. >>debug1: cipher_init: set keylen (16 -> 32) >>debug1: cipher_init: set keylen (16 -> 32) >>debug1: Installing crc compensation attack detector. >>debug1: Received encrypted confirmation. >>debug1: Doing password authentication. >>[EMAIL PROTECTED]'s password: >>--
Re: passwordless scp and cronjobs
> Date: Fri, 04 Oct 2002 15:48:56 -0400 > From: Gerard Samuel <[EMAIL PROTECTED]> > > I started the whole process again and added the SSH2 option to the > command line which now looks like this -> > scp -o 'Protocol=2' -v ~/temp/file.zip sys_dev@hivemind: Good. This is now at least running V2 protocol. > Towards the bottom you'll see its trying authentication methods, using > the public key as the first option. > I would tend to believe if all were well, it shouldn't have to go past > that point. This is absolutely correct. Unfortunately, the client lacks the knowledge of why the publickey method was rejected. You can only tell that the attempt failed. I doubt that you will luck into the correct fix by shots at the config file. Instead, get debug information from the server side. To do this you will need root access to the server-side system. On the server side: % /usr/sbin/sshd -p 378 -d This will start a new instance of the ssh daemon that will connect to port 378. (If 378 is not available on your system, pick another port <512.) This instance will not fork a daemon and will print verbose debug information. Then add -P 378 to the scp on the client and try again. The daemon debug information is usually enough to clarify what is failing. Finally, I really get uncomfortable seeing un-encrypted private keys being used. They are a significant vulnerability. I hope that the account is in a jail or in some other way limited in access on the destination system. You might consider the use of .shosts and host authentication for this. While there is a slightly greater possibility of spoofing, it is probably safer than an open key that can get you to somewhere vulnerable. Good luck. R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: [EMAIL PROTECTED] Phone: +1 510 486-8634 > debug1: send SSH2_MSG_SERVICE_REQUEST > debug1: service_accept: ssh-userauth > debug1: got SSH2_MSG_SERVICE_ACCEPT > debug1: authentications that can continue: > publickey,password,keyboard-interactive > debug1: next auth method to try is publickey > debug1: try pubkey: /home/gsam/.ssh/id_rsa This SHOULD have worked! > debug1: authentications that can continue: > publickey,password,keyboard-interactive > debug1: try privkey: /home/gsam/.ssh/id_dsa > debug1: next auth method to try is keyboard-interactive > Password: To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-questions" in the body of the message
Re: passwordless scp and cronjobs
And deeper into the rabbit hole I go. Here is a snip from server debug -> - debug1: userauth-request for user sys_dev service ssh-connection method none debug1: attempt 0 failures 0 debug1: Starting up PAM with username "sys_dev" debug1: PAM setting rhost to "gladiator.trini0.org" Failed none for sys_dev from 192.168.0.3 port 1042 ssh2 debug1: userauth-request for user sys_dev service ssh-connection method publickey debug1: attempt 1 failures 1 debug1: test whether pkalg/pkblob are acceptable debug1: trying public key file /home/developer/.ssh/authorized_keys debug1: restore_uid debug1: trying public key file /home/developer/.ssh/authorized_keys2 Authentication refused: bad ownership or modes for file /usr/home/developer/.ssh/authorized_keys2 debug1: restore_uid Failed publickey for sys_dev from 192.168.0.3 port 1042 ssh2 Now, seeing this, got me thinking. The directory is a shared directory between shared users (some friends of mine that I trust). So I changed the ficticious user sys_dev's home directory to their own, and everything started working. Kevin, thanks for the help. Now that I have this working, I can look at locking down this little system Kevin Oberman wrote: >>Date: Fri, 04 Oct 2002 15:48:56 -0400 >>From: Gerard Samuel <[EMAIL PROTECTED]> >> >>I started the whole process again and added the SSH2 option to the >>command line which now looks like this -> >>scp -o 'Protocol=2' -v ~/temp/file.zip sys_dev@hivemind: >> >> > >Good. This is now at least running V2 protocol. > > > >>Towards the bottom you'll see its trying authentication methods, using >>the public key as the first option. >>I would tend to believe if all were well, it shouldn't have to go past >>that point. >> >> > >This is absolutely correct. Unfortunately, the client lacks the >knowledge of why the publickey method was rejected. You can only tell >that the attempt failed. > >I doubt that you will luck into the correct fix by shots at the config >file. Instead, get debug information from the server side. To do this >you will need root access to the server-side system. > >On the server side: >% /usr/sbin/sshd -p 378 -d >This will start a new instance of the ssh daemon that will connect to >port 378. (If 378 is not available on your system, pick another port ><512.) This instance will not fork a daemon and will print verbose >debug information. > >Then add -P 378 to the scp on the client and try again. The daemon >debug information is usually enough to clarify what is failing. > >Finally, I really get uncomfortable seeing un-encrypted private keys >being used. They are a significant vulnerability. I hope that the >account is in a jail or in some other way limited in access on the >destination system. > >You might consider the use of .shosts and host authentication for >this. While there is a slightly greater possibility of spoofing, it is >probably safer than an open key that can get you to somewhere >vulnerable. > >Good luck. > >R. Kevin Oberman, Network Engineer >Energy Sciences Network (ESnet) >Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) >E-mail: [EMAIL PROTECTED] Phone: +1 510 486-8634 > > > >>debug1: send SSH2_MSG_SERVICE_REQUEST >>debug1: service_accept: ssh-userauth >>debug1: got SSH2_MSG_SERVICE_ACCEPT >>debug1: authentications that can continue: >>publickey,password,keyboard-interactive >>debug1: next auth method to try is publickey >>debug1: try pubkey: /home/gsam/.ssh/id_rsa >> >> >This SHOULD have worked! > > >>debug1: authentications that can continue: >>publickey,password,keyboard-interactive >>debug1: try privkey: /home/gsam/.ssh/id_dsa >>debug1: next auth method to try is keyboard-interactive >>Password: >> >> > > > > -- Gerard Samuel http://www.trini0.org:81/ http://dev.trini0.org:81/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-questions" in the body of the message
