Allow ssh access to multiple users on GoDaddy's shared hosting without sharing your password

My aim was to allow a couple of colleagues to ssh into my shared hosting server at GoDaddy. If it was any other server, I could have very well created another user which could be used by anyone else who needs access to the server. But, on GoDaddy shared hosting servers you get just one ssh user, hence this blog entry. As described in Max Beatty's blog, its a very simple job. But my approach was a little different, I did not want to keep copying everyone's public key into my godaddy server's .ssh/authorized_keys2 file. Instead of that, I created a new public/private key pair

[ausmarton@ausmarton ~]$ ssh-keygen

Next, step which is similar to Max's approach is to copy the newly generated public key onto our server.

[ausmarton@ausmarton ~]$ scp ~/.ssh/id_rsa.pub user@remote-host:.ssh/authorized_keys2

If you're on a linux system, you can use ssh-copy-id, which does it quite neatly.

[ausmarton@ausmarton ~]$ ssh-copy-id -i ~/.ssh/id_rsa.pub remote-host

Now, you just need to share your id file located at  ~/.ssh/id_rsa with anyone who needs to get ssh access to you GoDaddy shared hosting server. What they need to do is, use the id file whenever they try to ssh into your server. That can be using the following command.

[ausmarton@ausmarton ~]$ ssh user@remote-host -i ~/.ssh/d_rsa

The parameter -i can be used to specify an id file to be used while connecting to an ssh server. So, your friend/colleague simply needs to replace ~/.ssh/d_rsa with the path to the id file they got from you.

NOTE: It's not a good idea to share your id file with a lot of people, because of this, even if you already have a private/public key pair generated, do not share that one. Also, if you're using applications which use your ssh id file to validate your identity like git, then you definitely shouldn't share your existing id file. Instead, generate a new one - one which you wouldn't mind sharing with a lot of people.
Location: 4, Karunanidhi Beach Rd, Bharathi Nagar, Palavakkam, Chennai, Tamil Nadu, India

Comments

  1. rastaquere8 April 2013 at 23:44

    hello
    Thanks for your post!
    Would this allow to restrict file and directory rights for this newly created user?
    Dan

    ReplyDelete
    Replies
    1. Ausmarton Fernandes9 April 2013 at 23:06

      You're welcome Dan.
      We are not really creating a new user here. In fact, the pricing plan that I opted for, didn't allow more than 1 user to be able to access the server.
      So, basically you would not be able to set any directory/file access restrictions on any one else that logs in to this user.

      To make it simpler, it as good as sharing your user-id/password with someone else. Only difference here is that you don't disclose your password. But again, it doesn't give you any added security over sharing your password.

      Delete

Post a Comment

Popular posts from this blog

Errors while trying to monitor Asterisk through Nagios

Today, I was trying to configure nagios to monitor an asterisk setup. I installed the nagios-plugins-check_sip plugin available for CentOS. I also had check_asterisk downloaded from here just to try out both. Now, check_asterisk and check_sip are perl scipts which can be used to monitor an asterisk setup. When run through the command line, they seem to work fine, i.e: given that asterisk or any other sip server is listening and your command is correct, you should get output similar to this: ;SIP/2.0 200 OK, 0.000585 seconds response time, cnt=1 Although, that's exactly what I got, it didn't work the same way through nagios, I was getting the following as the output from the plugin. (Service check did not exit properly) After enabling debug info for nagios, I found this in the logs, HOST: remotehost, SERVICE: Asterisk, CHECK TYPE: Active, OPTIONS: 1, SCHEDULED: Yes, RESCHEDULE: Yes, EXITED OK: No, RETURN CODE: 3, OUTPUT: **ePN failed to compile /usr/lib64/nagios/plugins/chec...
Read more

Configuring remote access for couchdb

By default, CouchDb is configured to be access only from a local port, i.e: you can connect to a couchdb instance as long as it is on the same host. Also, it is necessary that the HTTP request be made using the loopback IP address (127.0.0.1). In case you want to be able to access a couchdb instance from an external machine, you need to make some changes to the couchdb configuration. Note that you would need to have superuser access in order to make changes to these files. Usually couchdb will have two configuration (ini) files in /etc/couchdb depending on your installation. Both these files (default.ini and local.ini) can be used to enable remote hosts to access couchdb. The configuration required for this is: [httpd] port = 5984 bind_address = 0.0.0.0 By default the configuration would be: [httpd] port = 5984 bind_address = 127.0.0.1 This means that the Http server is bound only to the loopback IP address, which is why we change it to 0.0.0.0 to make it bind to any IP address. If...
Read more

Proxy Error 502 “Reason: Error reading from remote server” with Apache 2.2.3

I had a setup of tomcat running on port 8080 and Apache proxying for tomcat on port 80. If I tried to access webapps directly from tomcat on port 8080,. they were accessible, while on port 80, I would get the followig error: Proxy Error 502 “Reason: Error reading from remote server” with Apache 2.2.3 following fix worked: adding retry=1 acquire=3000 timeout=600 Keepalive=On after the Proxy directive in the http configuration.
Read more