2

I cannot find from my linux box in which file the private key is stored. In below testing, my findings is , there is no ~/.ssh.config file, nor ~/.ssh/id_dsa or equivalent.

From the testing result, it seems some configuration is taking effect? But how can I found which file is it? I enabled the -v option in ssh connection as well, but nothing useful is found.

$ ls ~/.ssh
authorized_keys  authorized_keys.bak  known_hosts  known_hosts.bak

$ ls /etc/ssh/
moduli      sshd_config           ssh_host_dsa_key      ssh_host_ecdsa_key      ssh_host_ed25519_key      ssh_host_rsa_key      ssh_import_id
ssh_config  sshd_config.original  ssh_host_dsa_key.pub  ssh_host_ecdsa_key.pub  ssh_host_ed25519_key.pub  ssh_host_rsa_key.pub



$ ssh  git@bitbucket.com   #successful!!!
PTY allocation request failed on channel 0
logged in as xx.

$ ssh  bitbucket.com     #failed!!!
Permission denied (publickey).

$ ssh  localhost  #successful!!!

BTW, I enabled -vv option for ssh, and I can see that the key being used is xx@host1, but I still didn't see which file the key is fetched from.

$ ssh -vv github.com
OpenSSH_6.6.1, OpenSSL 1.0.1f 6 Jan 2014
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 github.com [192.30.253.113] port 22.
debug1: Connection established.
debug1: identity file /home/xx/.ssh/id_rsa type -1
debug1: identity file /home/xx/.ssh/id_rsa-cert type -1
debug1: identity file /home/xx/.ssh/id_dsa type -1
debug1: identity file /home/xx/.ssh/id_dsa-cert type -1
debug1: identity file /home/xx/.ssh/id_ecdsa type -1
debug1: identity file /home/xx/.ssh/id_ecdsa-cert type -1
debug1: identity file /home/xx/.ssh/id_ed25519 type -1
debug1: identity file /home/xx/.ssh/id_ed25519-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.6.1p1 Ubuntu-2ubuntu2.7
debug1: Remote protocol version 2.0, remote software version libssh-0.7.0
debug1: no match: libssh-0.7.0
debug2: fd 3 setting O_NONBLOCK
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug2: kex_parse_kexinit: curve25519-sha256@libssh.org,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-cert-v01@openssh.com,ssh-rsa-cert-v00@openssh.com,ssh-rsa,ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp521-cert-v01@openssh.com,ssh-ed25519-cert-v01@openssh.com,ssh-dss-cert-v01@openssh.com,ssh-dss-cert-v00@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-ed25519,ssh-dss
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-gcm@openssh.com,aes256-gcm@openssh.com,chacha20-poly1305@openssh.com,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-gcm@openssh.com,aes256-gcm@openssh.com,chacha20-poly1305@openssh.com,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
debug2: kex_parse_kexinit: hmac-md5-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-ripemd160-etm@openssh.com,hmac-sha1-96-etm@openssh.com,hmac-md5-96-etm@openssh.com,hmac-md5,hmac-sha1,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-ripemd160-etm@openssh.com,hmac-sha1-96-etm@openssh.com,hmac-md5-96-etm@openssh.com,hmac-md5,hmac-sha1,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib
debug2: kex_parse_kexinit: none,zlib@openssh.com,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,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-dss,ssh-rsa
debug2: kex_parse_kexinit: chacha20-poly1305@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr,aes256-cbc,aes192-cbc,aes128-cbc,blowfish-cbc
debug2: kex_parse_kexinit: chacha20-poly1305@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr,aes256-cbc,aes192-cbc,aes128-cbc,blowfish-cbc
debug2: kex_parse_kexinit: hmac-sha1,hmac-sha2-256,hmac-sha2-512
debug2: kex_parse_kexinit: hmac-sha1,hmac-sha2-256,hmac-sha2-512
debug2: kex_parse_kexinit: none,zlib,zlib@openssh.com
debug2: kex_parse_kexinit: none,zlib,zlib@openssh.com
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: setup hmac-sha1
debug1: kex: server->client aes128-ctr hmac-sha1 none
debug2: mac_setup: setup hmac-sha1
debug1: kex: client->server aes128-ctr hmac-sha1 none
debug1: sending SSH2_MSG_KEX_ECDH_INIT
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: RSA 16:27:ac:a5:76:28:2d:36:63:1b:56:4d:eb:df:a6:48
debug1: Host 'github.com' is known and matches the RSA host key.
debug1: Found key in /home/xx/.ssh/known_hosts:1
debug1: ssh_rsa_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: SSH2_MSG_SERVICE_REQUEST sent
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug2: key: xx@host1 (0x55a060a66440),
debug2: key: /home/xx/.ssh/id_rsa ((nil)),
debug2: key: /home/xx/.ssh/id_dsa ((nil)),
debug2: key: /home/xx/.ssh/id_ecdsa ((nil)),
debug2: key: /home/xx/.ssh/id_ed25519 ((nil)),
debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Offering RSA public key: xx@host1
debug2: we sent a publickey packet, wait for reply
debug1: Server accepts key: pkalg ssh-rsa blen 279
debug2: input_userauth_pk_ok: fp 46:18:4d:dd:54:70:93:0a:77:70:f4:19:7f:0d:39:be
debug1: Authentication succeeded (publickey).
Authenticated to github.com ([192.30.253.113]:22).
debug1: channel 0: new [client-session]
debug2: channel 0: send open
debug1: Entering interactive session.
debug2: callback start
debug2: fd 3 setting TCP_NODELAY
debug2: client_session2_setup: id 0
debug2: channel 0: request pty-req confirm 1
debug1: Sending environment.
debug1: Sending env LANG = en_US.UTF-8
debug2: channel 0: request env confirm 0
debug2: channel 0: request shell confirm 1
debug2: callback done
debug2: channel 0: open confirm rwindow 32000 rmax 35000
debug2: channel_input_status_confirm: type 100 id 0
PTY allocation request failed on channel 0
debug2: channel_input_status_confirm: type 99 id 0
debug2: shell request accepted on channel 0
debug2: channel 0: rcvd ext data 88
Hi xx! You've successfully authenticated, but GitHub does not provide shell access.
debug2: channel 0: written 88 to efd 6
debug1: client_input_channel_req: channel 0 rtype exit-status reply 0
debug2: channel 0: rcvd eof
debug2: channel 0: output open -> drain
debug2: channel 0: obuf empty
debug2: channel 0: close_write
debug2: channel 0: output drain -> closed
debug2: channel 0: rcvd close
debug2: channel 0: close_read
debug2: channel 0: input open -> closed
debug2: channel 0: almost dead
debug2: channel 0: gc: notify user
debug2: channel 0: gc: user detached
debug2: channel 0: send close
debug2: channel 0: is dead
debug2: channel 0: garbage collecting
debug1: channel 0: free: client-session, nchannels 1
Connection to github.com closed.
Transferred: sent 3632, received 1800 bytes, in 0.8 seconds
Bytes per second: sent 4558.3, received 2259.1
debug1: Exit status 1

And the lines in /etc/ssh/ssh_config is as below, excluding comments:

$cat /etc/ssh/ssh_config | grep -v ^#




Host *
    SendEnv LANG LC_*
    HashKnownHosts yes
    GSSAPIAuthentication yes
    GSSAPIDelegateCredentials no
1
debug2: key: xx@host1 (0x55a060a66440),

This key is provided by the ssh-agent. Check ssh-add -l. It should also list this key. But it is not possible to find out where it is (or was) stored. Currently it exists only in the process memory.

  • Yes, ssh-add -l prints out the fingerprint of the private key being used.But ssh-agent process is not running by checking "ps -ef". – Zii Jul 4 '16 at 1:56
  • It is fingerprint of public key. Ssh-agent interface can present also different desktop apps such as gnome-keeyring. – Jakuje Jul 4 '16 at 6:06
0

To enable more verbosity, you can try ssh -v -v to connect. In debug2 output you should see which keys are offered and used.

To generate a key for your current user, use ssh-keygen. For example:

ssh-keygen -t rsa -b 4096 -f ~/.ssh/id_rsa

creates 4096 bit RSA key with correct permissions.

  • I enabled -vv , and i found the key being used is xx@host1, but where is it from? – Zii Jul 3 '16 at 11:07
  • Seems the user you are logged in is "xx". As default /home/xx/.ssh/ or (~/.ssh/) is the directory where ssh keys are expected. You can change these settings in /etc/ssh/ssh_config. If you are user xx and want to use another key for a specific host, you can write a ~/.ssh/config file to use different keys for different host connections. – ztl Jul 3 '16 at 11:17
  • The directory ~/.ssh/ doesn't contain the private key files nor ssh config files. So where is the private key being used stored for now? – Zii Jul 3 '16 at 11:35
  • For some reason, is it possible that the key file is stored in your current directory? Have a look at /etc/ssh/ssh_config which defaults are configured. – ztl Jul 3 '16 at 11:46
  • The printout of /etc/ssh/ssh_config is appended to above post. – Zii Jul 3 '16 at 13:27

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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