2

I am following this post to create ssh tunnel to mysql. The details description of my application scenario is given in my other SOQ.

I exactly followed these steps to create a user:

useradd -s /bin/false myuser
mkdir /home/myuser/.ssh
touch /home/myuser/.ssh/authorized_keys
chown -R myuser:myuser /home/myuser/.ssh
chmod 755 /home/myuser/.ssh
chmod 600 /home/myuser/.ssh/authorized_keys

It did not work for me. Not even able to ssh into remote server.

Given the post very old I am looking for sane way to create a limited privileges user which only connect to mysql and nothing else. I am testing this under ubuntu.

The other issue with this is to test the ssh connection from my system. So how I will create authorization keys for a system ( my local machine) which does not have a static IP. However the network in which I am working have a static IP. Is it possible to create authorization keys for that IP ?

Edit

Re-tested with two vagrant ubuntu instances, it works using ubuntu user with password , but unable to connect with myuser and rsa key as created in given article.

SSH KEY

ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/home/vagrant/.ssh/id_rsa): 
/home/vagrant/.ssh/id_rsa already exists.
Overwrite (y/n)? y
Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in /home/vagrant/.ssh/id_rsa.
Your public key has been saved in /home/vagrant/.ssh/id_rsa.pub.

Upload to server

scp /home/vagrant/.ssh/id_rsa.pub [email protected]:.
[email protected]'s password: 
id_rsa.pub              100%

Append RSA key to ghost user ssh keys

ubuntu@DEV:~ cat id_rsa.pub >> /home/ghost/.ssh/authorized_keys

SSH LOG

vagrant@precise64:~$ ssh -fNg -vvv -L 3307:127.0.0.1:3306 [email protected] 
OpenSSH_5.9p1 Debian-5ubuntu1, OpenSSL 1.0.1 14 Mar 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 192.168.33.55 [192.168.33.55] port 22.
debug1: Connection established.
debug3: Incorrect RSA1 identifier
debug3: Could not load "/home/vagrant/.ssh/id_rsa" as a RSA1 public key
debug1: identity file /home/vagrant/.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 /home/vagrant/.ssh/id_rsa-cert type -1
debug1: identity file /home/vagrant/.ssh/id_dsa type -1
debug1: identity file /home/vagrant/.ssh/id_dsa-cert type -1
debug1: identity file /home/vagrant/.ssh/id_ecdsa type -1
debug1: identity file /home/vagrant/.ssh/id_ecdsa-cert type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.9p1 Debian-5ubuntu1
debug1: match: OpenSSH_5.9p1 Debian-5ubuntu1 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.9p1 Debian-5ubuntu1
debug2: fd 3 setting O_NONBLOCK
debug3: load_hostkeys: loading entries for host "192.168.33.55" from file "/home/vagrant/.ssh/known_hosts"
debug3: load_hostkeys: found key type ECDSA in file /home/vagrant/.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-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],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 11:5d:55:29:8a:77:d8:08:b4:00:9b:a3:61:93:fe:e5
debug3: load_hostkeys: loading entries for host "192.168.33.55" from file "/home/vagrant/.ssh/known_hosts"
debug3: load_hostkeys: found key type ECDSA in file /home/vagrant/.ssh/known_hosts:1
debug3: load_hostkeys: loaded 1 keys
debug1: Host '192.168.33.55' is known and matches the ECDSA host key.
debug1: Found key in /home/vagrant/.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: /home/vagrant/.ssh/id_rsa (0x7f446fe9ada0)
debug2: key: /home/vagrant/.ssh/id_dsa ((nil))
debug2: key: /home/vagrant/.ssh/id_ecdsa ((nil))
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: /home/vagrant/.ssh/id_rsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey,password
debug1: Trying private key: /home/vagrant/.ssh/id_dsa
debug3: no such identity: /home/vagrant/.ssh/id_dsa
debug1: Trying private key: /home/vagrant/.ssh/id_ecdsa
debug3: no such identity: /home/vagrant/.ssh/id_ecdsa
debug2: we did not send a packet, disable method
debug3: authmethod_lookup password
debug3: remaining preferred: ,password
debug3: authmethod_is_enabled password
debug1: Next authentication method: password
[email protected]'s password:

192.168.33.55 /etc/ssh/sshd_config

RSAAuthentication yes
PubkeyAuthentication yes
#AuthorizedKeysFile %h/.ssh/authorized_keys

192.168.33.55 SSHD LOGS

tail /var/log/auth.log -n 100

Feb 28 10:15:42 precise64 sudo: pam_unix(sudo:session): session closed for user root
Feb 28 10:15:53 precise64 sshd[2154]: Failed password for ghost from 192.168.33.31 port 52350 ssh2
Feb 28 10:15:53 precise64 sshd[2154]: Failed password for ghost from 192.168.33.31 port 52350 ssh2
Feb 28 10:15:53 precise64 sshd[2154]: Connection closed by 192.168.33.31 [preauth]
Feb 28 10:17:01 precise64 CRON[2157]: pam_unix(cron:session): session opened for user root by (uid=0)
Feb 28 10:17:01 precise64 CRON[2157]: pam_unix(cron:session): session closed for user root
Improve this question
14
  • There is nothing about adding the public ssh keys to the /home/myuser/.ssh/authorized_keys file ?!
    – Ouki
    Feb 28, 2014 at 9:00
  • I have added the ssh keys as describe in the article. Created ssh keys on the client side and uploaded to serverside and appended the keys to newly created user myuser's authorized_keys file. But still no luck : vagrant@precise64:~$ ssh -fNg -L 3307:127.0.0.1:3306 [email protected] [email protected]'s password: . It should not prompt for password given the ssh keys
    – sakhunzai
    Feb 28, 2014 at 9:04
  • 1
    could you add the log of your loging attempt with ssh but add the switch -vvv to your ssh command
    – Kiwy
    Feb 28, 2014 at 9:13
  • @Kiwy, please see logs , My assumption is that the rsa public key generated by command ssh-keygen -t rsa does not add proper host name bcz as I cat the key file I see it ending with vagrant@precise64 instead of the instance ip address which is 192.168.33.31 in this case. The question is how to generate rsa keys for specifics user@ip address
    – sakhunzai
    Feb 28, 2014 at 9:36
  • Just edit it. user@ip is an optional information field.
    – Ouki
    Feb 28, 2014 at 9:38

1 Answer 1

Reset to default
1

In search of restarting the sshd after updating AuthorizedKeysFile in /etc/ssh/sshd_config

RSAAuthentication yes
PubkeyAuthentication yes
AuthorizedKeysFile     %h/.ssh/authorized_keys

I got here with exact same error

Which guided me to install:

   sudo apt-get install openssh-server
   sudo initctl reload-configuration
   sudo service ssh start

After that I checked ssh logs

tail /var/log/auth.log -n 100 
  Feb 28 11:11:40 precise64 sshd[2826]: Server listening on :: port 22.
Feb 28 11:11:43 precise64 sshd[2827]: Authentication refused: bad ownership or modes for directory /home/ghost

Got it :)

sudo chown ghost:ghost -R /home/ghost

And now I am getting the two instances connected and able to connect to mysql through tunnel

One strange thing is that if I comment out #AuthorizedKeysFile %h/.ssh/authorized_keys in sshd_config ,I am still able to connect .

Thank you all for helping me in right direction

Improve this answer
1
  • By default, AuthorizedKeysFile uses that value. If you don't specify a value it falls back on the default.
    – MJD
    Feb 28, 2014 at 22:43

You must log in to answer this question.

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