[besson3c]

Is there a way to pass off an ssh password to an ssh connection so that it doesn't have to be typed in each time?

I'd like to be able to set crontabs for rsync ssh connections...

[utidjian]

Originally posted by besson3c:
Is there a way to pass off an ssh password to an ssh connection so that it doesn't have to be typed in each time?

I'd like to be able to set crontabs for rsync ssh connections...

Yes there is. Read man ssh.

Sorry if that seems like an abrupt answer but all the info you need is in there. Makes more sense than me copy-n-pasting from the manpage to the reply ;-)

[besson3c]

utijian:

If I found my answer within the man pages, I wouldn't have taken the time to ask my question here, no?

Do you know how to do this?

[Tritium]

You can do this using key based authentication. On the machine you want to cron rsync on, run:

ssh-keygen -t dsa

don't enter a passphrase when it prompts you for one.

Copy the contents of ~/.ssh/id_dsa.pub into ~/.ssh/authorized_hosts on the remote machines. Make sure the .ssh directory's permissions are 700, and the authorized_hosts file is 600.

Assuming sshd is configured normally, you should be able to ssh user@host and pop straight in with no password prompt.

[Rainy Day]

Is there a way to pass off an ssh password to an ssh connection so that it doesn't have to be typed in each time?

I'd like to be able to set crontabs for rsync ssh connections...

There are three basic authentication methods for ssh. One is a classic password challenge, as you are inquiring about, another is IP based, and the best method is as Tritium suggests using a public key pair, which can be done with or without a password.

This may sound a bit confusing at first. The key pair provides the authentication for the session. A password in this context is simply to protect the key from unauthorized use (e.g., if someone should steal your private key, it would be of no use to them unless they knew the password protecting the key). While a password here may sound as though it would defeat your stated purpose of automation, it can be automated using a UNIX tool very similar to Apple's Key Chain approach. But if you're not worried about someone stealing your private key, the simplest approach is simply hit return when prompted for a password when generating your key.

For maximum security, the classic password challenge authentication method (not talking about a private key password here) should be turned off as this then makes the key pair authentication method mandatory (and not just an option). Because most folks choose weak passwords, the classic password challenge authentication method is usually a poor choice and really ought to be disabled altogether (as it provides a weakly protected door into your remote system).

If you have a static IP, you can also add the additional requirement of IP verification in addition to key authentication, which increases security even more. Since IP's can be spoofed, IP authentication should never be used as the sole authentication method, but in combination with a key pair, it makes it that much more difficult to break in.

Because public key pairs can also support pass-phrase protection, you can effectively combine all three approaches.

This O'Reilly On Lamp article will give you a step in the right direction. A google search on keywords like SSH and passwordless will give you even more info.

Edit: Grammar

[Rainy Day]

An addendum to my post above... to tighten security and configure the SSH server as per some of my recommendations above, edit /etc/sshd_config as follows:

To disable the inherently insecure classic account password challenge authentication method, change the line:

Code:
#PasswordAuthentication yes

to:

Code:
PasswordAuthentication no

Note the removal of the # (as well as the change from yes to no).

This should be done because if you don't, it provides access to anyone lacking the private key but who may have obtained (or who might be able to guess) an account name and password (this info is much easier to obtain than you might think). It is the weakest point in your security. Key pairs are so much stronger and very easy to use. Close this door to your system!

It's also a good idea to explicitly state which accounts may be accessed remotely. This adds another level of security. To do this, add an AllowUsers directive naming the accounts (multiple AllowUsers lines are allowed, as are multiple names in the directive). For example, adding:

Code:
AllowUsers leslie@203.120.14.5 terry

limits ssh access on your computer to only the accounts leslie and terry. Furthermore, the account leslie may only be accessed from IP address 203.120.14.5. The account terry has no IP address restrictions, however, and anyone anywhere on the internet may connect (provided they provide the proper session authentication). Partial IP addresses and wildcards are also supported (see appropriate documentation for specifics).

If at all possible, you should limit the IP, as in the leslie account example, as this adds yet another level of security. If, for example, the private key to the leslie account falls into the wrong hands (and isn't password protected), it can only be used from the specified IP address. This isn't a foolproof failsafe, but it's far better than none at all.

The current default for RSAAuthentication and/or PubkeyAuthentication is yes, which means public keys are enabled (but not required) by default, so you shouldn't have to specify those options. This is just as well as these keywords seem to be in flux and the standards could change later. [Note: Since classic account password challenge authentication is also enabled by default, either method may be used for session authentication (by default). That is why i recommended you turn it off above, thus leaving public key authentication as the only remaining authentication option.]

So if you apply all the recommendations above, the only people who can log into your Mac are those with the proper private keys. Having account names and passwords will not grant them login capabilities through ssh. In fact, those with the proper keys don't even need to know their account passwords (and this may be a wise security precaution, depending upon your circumstances). For additional security, you can add a password to protect the private key (which is not related to the account password).

Enjoy!

[geekwagon]

Originally posted by besson3c:
Is there a way to pass off an ssh password to an ssh connection so that it doesn't have to be typed in each time?

I'd like to be able to set crontabs for rsync ssh connections...

You've gotten some good answers to your questions so far in this thread but I just wanted to make one point...

Someone recommended making a keypair that didn't have a password as a solution for not having to type your password. That means that anyone who obtains your private key will be able to log into your systems just as if they had discovered your password.

A better solution is to go ahead and encrypt the key with a passphrase, and use ssh-agent to keep the key in memory after you have decrypted it with your passphrase once.

man ssh-agent