sshfs auto login

[Red Squirrel]

I want to setup a backup job so I can backup my websites to my home server as right now I do it manually (for DB, uploaded files, that type of stuff - actual website data is already localized). Only issue is I can't seem to figure how to auto feed it the password.

This is shared hosting so I don't have access to the configuration to setup public key stuff and most shared hosts don't have public key as its more complex for users, password auth is still preferred. So any way to automate this?

Also is using this hard on the server at all or does it just look like a regular ssh session? I don't want my backups to bog down the server. It seems to be ok though.

 

[sourceninja]

I've always just pasted my key in .ssh/authorized_keys and been done with it. I don't know how to do it without keys.

 

[Red Squirrel]

Yeah for my own dedicated server thats a possible option as I can just set authentication to use keys, but on shared hosting its not really an option as it uses password authentication.

It's the same with the ssh command, I've never been able to find a way to make it auto login then execute a script remotely. That's going to be another of my requirements for my backups so I can auto backup my databases too. I realize its a security issue to have to store a password somewhere, but its not any different then storing a key. If someone gets on my server and gets access to the config that's a huge issue on it's own.

 

[yoda291]

are you sure ssh keys aren't enabled? Most shared hosts will leave the default auth options open in my experience and maybe disable gss and sshv1 IME. Also, just to cover the small possibility, you have tried putting your public key in ~/.ssh/authorized_keys2 as opposed to authorized_keys?

In any event, you could use an expect script to feed the password across for the mount. this would rule out using fstab, but you could always drop your script into rc.local.

 

[Red Squirrel]

Hmm so would it be possible that keys And password authentication are used? If yes how do I go about disabling the password authentication and use just keys? (on the shared host)

 

[yoda291]

Originally posted by: RedSquirrel
Hmm so would it be possible that keys And password authentication are used? If yes how do I go about disabling the password authentication and use just keys? (on the shared host)

well, it will try the authentications in a particular order. Usually, the password authentication fires off when the other ones have failed. ssh -vvv <hostname> should give you a detailed description of which methods are being tried and failing. So you wouldn't need to disable password auth, just make sure you're using another supported method and that it's set up right.

for example, if the permissions on the server side ~/.ssh directory aren't 0700 and the authorized_keys2 file isn't like 644, then keys will fail and it'll drop back to password.

 

[QuixoticOne]

Can't you use RSYNC to help with that?
Also, yeah, check to make sure that the RSA and DSA PKI login modes are BOTH really not possible to use since they would solve your problem.

Of course there are obvious scripting or modding ways to get SSH working for you (just recompile at worst).
But since it is a web site, alternatively, you could just have it archive itself into a snapshot and then download that over an authenticated SSL HTTPS session from the webserver itself assuming you have the right ability to use server side scripts/jobs/CGI/whatever with the right permissions to do what is needed.

 

[Red Squirrel]

This is a shared server so I don't have access to do that kind of stuff. Also I am using rsync to transfer data from the mounted ssh folder to the backup destination.

 

[Red Squirrel]

I sorta got keys to work, BUT now it asks for a passphrase... so I'm back to square one. Any way to automate entering the passphrase? I heard something about ssh-agent but its really not explained well. I have no idea where I'm suppose to enter the passphrase to so it knows it. It looks like I'd still be stuck entering it when the system reboots, not very practical at all.

 

[QuixoticOne]

Just don't CREATE the DSA / RSA secret key using a passphrase, then there won't be one.

 

[QuixoticOne]

$ ssh-keygen
Generating public/private rsa key pair.
Enter file in which to save the key (/home/...): newkey
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in newkey.
Your public key has been saved in newkey.pub.
The key fingerprint is:
5b:aa:.....
$ ls -al newkey*
-rw------- 1 1675 2008-08-17 16:26 newkey
-rw-r--r-- 1 399 2008-08-17 16:26 newkey.pub

Of course change slightly to generate a DSA key if desired.

 

[Red Squirrel]

But isin't that a huge security issue? Anyone can run ssh-keygen, enter no key, and get on my server. I can restrict by using from="myhost" in the authorized_keys file but that does not seem to be working at all. I tried putting my hostname as well as my IP.

 

[Red Squirrel]

Ok another problem, now that I created a key file, I cannot connect to any other ssh server from that server. Think its trying to use the key file for EVERY server now :/

 

[Red Squirrel]

Decided to use expect instead, been playing with it and it does what I want. Will just be tedious as I need to create an expect script AND backup script for a single job but what I'm doing is writing a C++ program that will take an argument for a job profile and read the info from a text file then generate the required bash/expect scripts, execute them, then delete them. I could probably even go a step further and make it support a basic custom encryption for the password.

The public key stuff was making me nervous anyway, too much obscurity and possibility of a security issue due to something I don't know about.

 

[yoda291]

- it isn't a security issue so long as you protect the private key file. Likely called id_dsa or newkey if you copied the above verbatim. anyone can run ssh-keygen, but keys work in pairs so as long as you don't disseminate the private key you generated yourself anywhere, you're ok.

- if it's trying the key for every server, take it out of .ssh and put it somewhere else with 700 permissions. When you connect, you specify which private key to use with the -i flag.

here's a question. Why do you need to do this automatically anyways? if you're using the sshfs stuff, pass the -o reconnect and it should re-establish the link due to failure itself. the only time you get an issue is if your client side reboots.

 

[QuixoticOne]

Yeah ssh-keygen uses in general the most random numbers your system can generate at the moment to generate a random unique keypair. It is not likely (in the crypto sense of astronomically improbable) that anyone else could find / discover that keypair. There has been one bug relating to Debian derived distributions where they used the wrong random number technique and the results weren't secure, but that was an isolated bug and has been fixed in updates for the affected systems for several months. Everyone else has been using ssh with RSA/DSA keys even without passphrases securely for ...years.

As yoda said, the secret key is secret, and is kept on the client (connecting) machine, and mustn't be disclosed. The public key can go on any server(s) you want to use that key to authenticate with and is possible to be public information without a serious compromise in security.

 

[Crusty]

Exactly, if someone has your public key big deal, not much they can do with it. You generate your public/private key on your local machine, secure your private key, and distribute your public key to the servers/machines you need to connect to.

 

[Red Squirrel]

Hmm good to know.

And I need to automate this as right now I do my backups manually, I rather do them automaticly. So even if system reboots I want it to work. It mounts the file system, does the rsync backup, then unmounts.

I've managed to get something working with "Exepect" though. Just writing a C++ program to make it easier to manage as I actually need 2 scripts per backup job and that would start to get messy. The C++ program generates it on the fly, runs it then deletes it after.

 

[yoda291]

d00d, I think you want to go back to keys...and then do

rsync -var --rsh="ssh -i <private_key>" <src> username@remotehost:<dst>

that would be non-trivially more secure than what you have going on...and it fits on 1 line.

 

[QuixoticOne]

Indeed. And spawning star / tar + gzip on one side or the other just completes the 'win'.

 

[Red Squirrel]

Did not know I could specify the key in rsync. Will this still cause me troubles with places that don't use keys if I configure my client to use keys though? (that I want to manually connect to)

 

[QuixoticOne]

If the given -i identity file doesn't authenticate successfully in general by default it'll prompt for a password.
Also typically you'd fire off a destination specific rsync or ssh command line so you're using the appropriate PKI identity to authenticate to that particular host as well as using appropriate rsync or whatever options suited to that job. There's no major harm in using the same identity file for multiple remote hosts, though, as long as you keep the SECRET key secret locally. If you do use the same keypair for numerous hosts and your secret key is lost / compromised, though, well.....

 

[Red Squirrel]

Yeah no luck, tried it with -i, I get the same thing as before "too many authentication failures". If I don't specify the -i then it asks for a password as normal. Only seems to work if I call the key id_rsa but then that only works on one server.

 

[Red Squirrel]

Looks like its a permission issue, what permissions do the .ssh have to be on the server I'm connecting to?

 

[Red Squirrel]

Think I got it. Thanks for that rsync command btw... had no idea it had the capability of directly connecting to a server via ssh. I will modify my program to just use that, it will be more secure and less maintenance (no need to edit the password when I change it)