Sunday, May 5, 2024
Homepage · server
 Popular · Latest · Hot · Upcoming
1
rated 0 times [  1] [ 0]  / answers: 1 / hits: 1221  / 3 Years ago, wed, july 21, 2021, 7:42:05

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.


More From » server
 Answers
2

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.


[#30743] Wednesday, July 21, 2021, 3 Years  [reply] [flag answer]
Only authorized users can answer the question. Please sign in first, or register a free account.
antorchestr
Add To Favorites
Follow
Total Points: 92
Total Questions: 111
Total Answers: 120
Location: Jordan
Member since Wed, Jun 17, 2020
4 Years ago
;