Cfrgtkky

I want to start using SSH instead of FTP, but I am clueless when it comes to SSH keys.

I'd like to use a Gulp command to transfer my files (as I do now with FTP). I've found a good amount of NPM packages that do this. However, none explain how to actually set up SSH keys on my remote shared (LAMP) server and on my local machine (MacOS).

Would anyone know how to set this up? All the tutorials I've found deal with setting up the node.js package, not the SSH keys themselves.

Update with additional information

• The server is Linux. It is a cheap shared LAMP stack server running CPanel


• I am able to only access the server via CPanel and FileZilla FTP (but not SFTP)


• The output of running ssh -i ~/.ssh/id_rsa me@mysite.com -vvv is as follows:

OpenSSH_7.9p1, LibreSSL 2.7.3

debug1: Reading configuration data /etc/ssh/ssh_config

debug1: /etc/ssh/ssh_config line 48: Applying options for *

debug1: Connecting to mysite.com port 22.

ssh: connect to host mysite.com port 22: Operation timed out

• Thinking it may be a firewall issue, I have tested with multiple ISPs but have gotten the same problem.


• I tried running the netstat -ntlp | grep ssh command on the Terminal that sits within the CPanel GUI (I don't know how else I could run this) but it did not recognise the netstat command.

• Perhaps, this article might interest you. However, before following this article, it would be nice to setup the SSH trust first.


• So, the problem statement is, you want to copy some files from your local machine to a remote server.


• To do that, you have to first chose an authentication method. Assuming the remote server is Linux, you've got two options - Password based and Password Less a.k.a SSH Key based authentication.


• For the remote server to authenticate you, these are the steps which need to happen


• You create an SSH keypair (Private Key + Public Key) on your local machine.


• You just copy/append the contents public key from your local machine to the .ssh/authorized_keys file of the remote server.



• Now, when you will try to SSH to the remote server from your local machine, you will specify in the command that you are trying to authenticate with the private key file that you already have created in the first step and the authentication will be successful since you have imported the corresponding public key to the remote server's authorized_keys file.




• First, lets create keypair:
  ssh-keygen -t rsa and then select all default options by just pressing Enter key.



• In the output of the above command, you will see that the private and public key files will be generated e.g.:
  Your identification has been saved in /home/ec2-user/.ssh/id_rsa
Your public key has been saved in /home/ec2-user/.ssh/id_rsa.pub
  


• Now, just copy/append the id_rsa.pub's CONTENT file from the directory mentioned in your case to the ~/.ssh/authorized_keys.


• To confirm that the SSH trust has been established, just try to SSH from your local machine to the remote server by using this command - ssh -i /location/of/private/key username@remote_server_ip
  


• If everything's good and you are able to login, then you just have to follow the link I mentioned in the first line of this post.

• Perhaps we need to backtrack and try to understand the context a little more. The following answers would be helpful. As mentioned earlier, the steps I suggested were based on my assumption that the remote server is Linux.


• What is the OS on the remote server?


• Are you able to login to the remote server?


• When you run that command ssh -i ~/.ssh/id_rsa me@mysite.com run it with -vvv flag. This runs the SSH into debug mode often revealing some more information on what's happening under the hood. A sample command is ssh -i ~/.ssh/id_rsa me@mysite.com -vvv. Let us know the output.


• 
  Once again, assuming the remote server is linux, there are following possibilities:-


• The sshd server on the remote machine is listening on some other port than the default TCP 22.


• To check this, you can logon to the remote machine and run sudo netstat -ntlp | grep ssh. It will show you the port on which the SSH server is listening for SSH connections.


• If you see that SSH is listening on some other port than TCP 22, you need to add -p flag in that ssh command. The sample command in that would be ssh -p port_number_on_which_SSH_server_is_listening -i ~/.ssh/id_rsa me@mysite.com -vvv
  


• If there's no output of the above command, that means the SSH is not running on the remote server and this is the reason you are not able to SSH into it.*


• I also have a remote instance to which I was able to connect using the same command. I was able to replicate/reproduce the issue when I disabled my SSH access to that instance and ran the SSH command in debug mode. This is the output I got (You are also getting the same error):

$ ssh -i /c/Users/XXX/ssh-keys/sl.pem ec2-user@13.233.220.64 -vv

OpenSSH_7.5p1, OpenSSL 1.0.2k  26 Jan 2017

debug1: Reading configuration data /etc/ssh/ssh_config

debug2: resolving "13.233.220.64" port 22

debug2: ssh_connect_direct: needpriv 0

debug1: Connecting to 13.233.220.64 [13.233.220.64] port 22.

debug1: connect to address 13.233.220.64 port 22: Connection timed out

ssh: connect to host 13.233.220.64 port 22: Connection timed out