Take the 2-minute tour ×
Ask Ubuntu is a question and answer site for Ubuntu users and developers. It's 100% free, no registration required.

I'm having trouble setting up SSH public key authentication. I want to use this to backup my server to a backup server with SSH. I will do this automatically with a cronjob, so I can't type in the passphrase or so.

What I did:

  • Make a key with ssh-keygen
  • Copy the key to the backup server with ssh-copy-id
  • Start the SSH agent with ssh-agent bash
  • Add the key to the agent with ssh-add
  • Verify this with ssh-add -l - the key was added
  • Verify everything - it worked

I did all this using root (via sudo -s) on the main server and my own user at the backup server.

However, now I logged out from sudo on the main server and logged back in (to root, with sudo). When I tried opening a connection with my key (ssh -i the-key the-user@the-host), I have to type in the passphrase again! So I runned ssh-add -l and got:

Could not open a connection to your authentication agent

How can I set up it that way that I never have to type in the passphrase again?


Here's ssh -vvv the-user@the-host:

root@cs:/# ssh -vvv [email protected]
OpenSSH_6.1p1 Debian-4, OpenSSL 1.0.1c 10 May 2012
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to 62.234.74.186 [62.234.74.186] port 22.
debug1: Connection established.
debug1: permanently_set_uid: 0/0
debug3: Incorrect RSA1 identifier
debug3: Could not load "/.ssh/id_rsa" as a RSA1 public key
debug1: identity file /.ssh/id_rsa type 1
debug1: Checking blacklist file /usr/share/ssh/blacklist.RSA-2048
debug1: Checking blacklist file /etc/ssh/blacklist.RSA-2048
debug1: identity file /.ssh/id_rsa-cert type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.9p1 Debian-5ubuntu1.1
debug1: match: OpenSSH_5.9p1 Debian-5ubuntu1.1 pat OpenSSH_5*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.1p1 Debian-4
debug2: fd 3 setting O_NONBLOCK
debug3: load_hostkeys: loading entries for host "62.234.74.186" from file "/root/.ssh/known_hosts"
debug3: load_hostkeys: found key type ECDSA in file /root/.ssh/known_hosts:1
debug3: load_hostkeys: loaded 1 keys
debug3: order_hostkeyalgs: prefer hostkeyalgs: [email protected],[email protected],[email protected],ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug2: kex_parse_kexinit: ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: [email protected],[email protected],[email protected],ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,[email protected],[email protected],[email protected],[email protected],ssh-rsa,ssh-dss
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,[email protected]
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,[email protected]
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,[email protected],hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,[email protected],hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,[email protected],hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,[email protected],hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,[email protected],zlib
debug2: kex_parse_kexinit: none,[email protected],zlib
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit: first_kex_follows 0
debug2: kex_parse_kexinit: reserved 0
debug2: kex_parse_kexinit: ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss,ecdsa-sha2-nistp256
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,[email protected]
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,[email protected]
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,[email protected],hmac-sha2-256,hmac-sha2-256-96,hmac-sha2-512,hmac-sha2-512-96,hmac-ripemd160,[email protected],hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,[email protected],hmac-sha2-256,hmac-sha2-256-96,hmac-sha2-512,hmac-sha2-512-96,hmac-ripemd160,[email protected],hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,[email protected]
debug2: kex_parse_kexinit: none,[email protected]
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit: first_kex_follows 0
debug2: kex_parse_kexinit: reserved 0
debug2: mac_setup: found hmac-md5
debug1: kex: server->client aes128-ctr hmac-md5 none
debug2: mac_setup: found hmac-md5
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: sending SSH2_MSG_KEX_ECDH_INIT
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ECDSA 24:60:36:95:d8:3f:04:b0:20:94:6b:a9:98:bf:22:1b
debug3: load_hostkeys: loading entries for host "62.234.74.186" from file "/root/.ssh/known_hosts"
debug3: load_hostkeys: found key type ECDSA in file /root/.ssh/known_hosts:1
debug3: load_hostkeys: loaded 1 keys
debug1: Host '62.234.74.186' is known and matches the ECDSA host key.
debug1: Found key in /root/.ssh/known_hosts:1
debug1: ssh_ecdsa_verify: signature correct
debug2: kex_derive_keys
debug2: set_newkeys: mode 1
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug2: set_newkeys: mode 0
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug2: key: /.ssh/id_rsa (0x7f4a9ecf0810)
debug1: Authentications that can continue: publickey,password
debug3: start over, passed a different list publickey,password
debug3: preferred gssapi-keyex,gssapi-with-mic,publickey,keyboard-interactive,password
debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /.ssh/id_rsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Server accepts key: pkalg ssh-rsa blen 279
debug2: input_userauth_pk_ok: fp fe:2f:03:4a:68:c0:ce:b1:e9:b5:74:9c:c5:cb:f5:1f
debug3: sign_and_send_pubkey: RSA fe:2f:03:4a:68:c0:ce:b1:e9:b5:74:9c:c5:cb:f5:1f
debug1: key_parse_private_pem: PEM_read_PrivateKey failed
debug1: read PEM private key done: type <unknown>
Enter passphrase for key '/.ssh/id_rsa':

And this is the relevant part of /var/log/auth.log on the server side:

Jun 14 10:06:30 laptop-camil sshd[2265]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=vivisoft.nl  user=camilstaps
Jun 14 10:06:34 laptop-camil sshd[2265]: Connection closed by 164.138.27.37 [preauth]

This is what I get when I run nohup ssh-agent bash & (see the comments):

root@cs:~# nohup ssh-agent bash &
[1] 1287
root@cs:~# nohup: ignoring input and appending output to ânohup.outâ
<here is an empty line with the cursor>

For some reason, the output of nohup is put on the next line, and a new line is added.

share|improve this question
1  
Did you generate the SSH key with a passphrase? Why would you even care about that if you're going to store the key in the agent? (Or are you referring to the regular password here?) And what do the logs say on the server side (/var/log/auth.log on the target of the ssh command)? And what does the client tell you on connecting (add -vvv as an option to ssh)? –  gertvdijk Jun 14 '13 at 8:04
    
@gertvdijk thanks for your comment! I generated with a passphrase, but also without: I have to press enter for inputting an empty password. I added the log and output your requested to my question. –  Camil Staps Jun 14 '13 at 8:11
1  
I see several errors in the client log, but those are actually valid and is nothing to worry about. What I do find interesting is that you use /.ssh/ as the path to the key in your configuration somewhere instead of /root/.ssh/. Is this intentional? Anyway, I would recommend to set this up without the use of an SSH key agent and use passphraseless keys. (In your case I don't think this would offer any enhancement in security.) Oh and by the way, to create backups, there's no need to be root on the both ends. –  gertvdijk Jun 14 '13 at 8:25
    
@gertvdijk sorry for the misunderstanding, I only use root at the computer that is to be backed up (the client). I use /.ssh because that's the homedir for root. Also when I shouldn't use it for backups, I'd still like to get it to work for other things. So is there anything you see I should change? –  Camil Staps Jun 14 '13 at 8:28
    
(continuing comment) My suspicion as to why this happens after you logout is that the key agent you start is a child process of your shell. Try running this in the background (nohup ssh-agent bash &) and verify the process isn't a child of the shell now with pstree. –  gertvdijk Jun 14 '13 at 8:29

2 Answers 2

up vote 1 down vote accepted

First: The key agent are supposed to exit when you log out, by design. Because of security issues, you don't want your login to be open if you log out by mistake. So, you really should NOT use ssh key agent for this, it is not the way to use it.

Second: It is posible to have very restricted user with few rights, to store/recive backup files on /srv/backup or where ever it has access. To log in to that user you have a ssh certificate whithout any certificate password, so you can log in without password if client has the right certificate.
You could then even restrict which machines are allowed to connect and what programs to runt in ~/.ssh, look that up in the manual.

share|improve this answer
    
Sorry, missed that. Corrected. –  Anders Jun 14 '13 at 18:36
    
I would have thought that using a persistent ssh-agent to hold a passphrase in memory is marginally more secure than using an ssh key with no passphrase, since an attacker would not only need to get a copy of the key file but also extract the passphrase from memory in order to use it. Note that he is talking about using this for an unattended cron job, so he will not necessarily be logged into the client when the job runs. –  David Edwards Jun 15 '13 at 9:16

When you are logged in as root (in your verbose output above it shows that you are) and you run ssh, it will look for keys in root's .ssh directory; not the directory of the user specified in the ssh connection string.

I am not entirely sure why you are running any of this using sudo; when you create and copy your keys you need to be logged in as the user you are intending to use for ssh.

I am a bit confused by your description of what you did, but as a first step I suggest you make sure that you have created the key in the correct user's .ssh directory and that when you are running ssh you are running it as the correct user to pick up that key file.

The second part of your question is about using ssh-agent to store your key's passphrase. There is a good guide to doing this here: http://www.akadia.com/services/ssh_agent.html. Again, you need to be running ssh-agent (on the client, if that isn't clear) as the correct user. Note that ssh-agent only stores the passphrase in memory, so if it is terminated and you start a new ssh-agent process it will no longer remember your passphrase. On a server, this is not such as issue; you just need to start up the agent once and keep it running in the background. There are details in the link above explaining how to tell your script where to find the agent by storing the location of the agent socket in a temporary file that your backup script can read.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.