Before I started at my current job (at a small business), my office had no firewall on the network and literally nothing was ever being backed up. Now that I've signed on as a dedicated sysadmin / one-man-IT-department, I've been doing what I can to change this. After explaining to my boss how vulnerable we were, he's allowed me to set up some backup servers, one of which is at his house.

Right now, I'm trying to get everything set so that I can automate daily backups. I am planning to use rsync through ssh to do this. For security's sake as well as for ease of automation, I was planning to disable ssh password login and only use rsa key validation. Well, if I have an rsa passphrase set, then I would still have to enter a passsword, and that's a problem.

Does not having an rsa passphrase make things significantly less secure? I'm the only person in the company who has any sort of a clue about this kind of thing, so I'm not too worried about someone calling up a terminal on my machine (which is always locked when I'm AFK, anyway) and ssh-ing into one of the backup servers and doing any damage. I'm still very, very new to the world of systems administration, and this is my first time doing anything like this, and I don't want to leave any holes in the security setup.

The computers in question here are running Ubuntu 10.10, SME Server, and OSX 10.6, if that somehow makes any sort of a difference.

  • 5
    There really shouldn't be any loss in security by not having a passphrase on your key. Maintaining the security integrity of the key at this point becomes integral since if someone is able to copy it there is no secret key that would prevent them from using it. Commented Mar 23, 2011 at 15:02
  • 2
    Maybe it's just me, but I have no idea what the above comment is trying to say. Commented Sep 24, 2015 at 13:57
  • 5
    @underscore_d He is basically saying: No impact on SSH security to have or not have passphrases for your keys BUT you have to keep your keys locally secure.
    – Hartator
    Commented Jan 26, 2016 at 16:46

3 Answers 3


As you know, the advantage that the passphrase gives you is that if someone is able to read your private key, they are 'unable' to use it.

If someone is able to access that private key, you should take it for granted that they have access(ed)/compromised whatever machines are set up with the public key. Things like .bash_history or .ssh/config only make this easier, even if your .ssh/known_hosts is obfuscated.

Not having a password on your key isn't the end of the world, here are 3 ideas to try and help you secure yourself a little better despite this. (The biggie is the second, read that if nothing else)

  1. Don't just use the same key across all machines and users. Generate each user on each machine (that needs to do this kind of thing) its own key pair. This will let you keep fine grained control on what is able to ssh where.

  2. When adding the key to your authorized_keys file, you can lock it down to only be able to run a specific command, or use it only from a specific host.

    See man ssh and search for command= and from=

    The syntax is something like:

    from="",command="/path/to/executable argument" ssh-rsa key name

    i.e. pop 'rsync' in there and only 'rsync' could be called by your key, and only from the IP address Multiple IPs can be separated by ,. Host names are also supported.

  3. Another thing that springs to mind is the 'AllowUser' directive in your sshd_config


    This keyword can be followed by a list of user name patterns, separated by spaces. If specified, login is allowed only for user names that match one of the patterns. '*' and '?' can be used as wildcards in the patterns. Only user names are valid; a numerical user ID is not recognized. By default, login is allowed for all users. If the pattern takes the form USER@HOST then USER and HOST are separately checked, restricting logins to particular users from particular hosts.

    That basically ensures that the user can only log in from a certain location. (although it accepts wildcards too) Not going to solve all of your problems but it'll at least make it harder for others.

  • 1
    Beautiful - this is exactly what I needed to know. Thank you so much!
    – eckza
    Commented Mar 23, 2011 at 16:02
  • 3
    No problem, just don't take it as an exhaustive list! :-) Things like regularly reviewing auth.log/secure etc. spring to mind.
    – Pricey
    Commented Mar 23, 2011 at 16:06
  • 3
    So auditing instead of worrying about your passphrase being stolen? Commented Jul 11, 2013 at 5:11
  • 3
    @shurane Do both!
    – Pricey
    Commented Jul 18, 2013 at 14:39

You can use something like keychain to make having a passphrase less painful. This is slightly more secure than using a passwordless login, and can be used in combination with the other answers here. PriceChild's answer was pretty good.


Personally I use DSA not RSA, mainly because it's what I have always used and I know it 'just works', but the theory I guess is the same. You could replace dsa with rsa in the below.

On the source:

$ ssh-keygen -t dsa

Then copy the contents of the .ssh/id_dsa.pub file into .ssh/authorized_keys in the user account on the destination.

Then you should just be able to ssh between the source and the destination with no passwords.

  • 1
    Is there any reason you advocate dsa over rsa? I've more often seen the opposite recommended.
    – Pricey
    Commented Mar 23, 2011 at 15:04
  • @PriceChild: AFAIK, their security is more-or-less equivalent (assuming sufficient key size). Not being a cryptographer myself, I trust the decision of OpenSSH and GnuPG to use RSA as default key algorithm. See also this question. Commented Mar 23, 2011 at 15:14
  • No real reason - mainly personal choice - that and the fact that RSA was hacked into recently and sensitive code stolen - how that relates to RSA keys I have no idea (who does?) but I have just always used DSA as it seemed more secure.
    – Majenko
    Commented Mar 23, 2011 at 15:16
  • 10
    I'm afraid the hack on "the company RSA" has no effect on "the algorithm RSA"'s security. Also check out secure.wikimedia.org/wikipedia/en/wiki/RSA_Security - "RSA was named after the RSA public key cryptography algorithm, which was in turn named after the initials of its co-inventors: Ron Rivest, Adi Shamir, and Len Adleman."
    – Pricey
    Commented Mar 23, 2011 at 15:27
  • 8
    @Matt: The only thing they have in common is the name. The RSA asymmetric crypto algorithm is pure math, there is no way it could be weakened by a break-in to some corporation's systems. Commented Mar 23, 2011 at 15:32

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .