Private key doesn’t work

The most typical reason for a private key not working is because of the permissions on your.ssh directory are incorrect. The.ssh directory, as well as your authorized keys file, must both be set to only allow your user access. If you’re having problems, try running the following commands:

[server]

/.ssh $ chmod 700
[server]
/.ssh/authorized keys $ chmod 600

Too many failed attempts

If you get the ‘too many failed tries’ error when trying to log into your server through SSH, consider adding the -v parameter to see the connection’s output. Consider the following scenario:

ssh -v [email protected] macbook$
To see how many keys are being used to connect, search for lines with the wording ‘Trying private key’ in the output. It’s possible that you added too many keys to your SSH configuration over time, forcing the SSH agent to try too many keys before falling back to Password Authentication. In the.ssh directory on your computer, you may view and delete any outdated keys.

No password prompt appears after connecting

If you don’t get a password prompt after connecting to the server, double-check that your username is set to shell user. For details on how to grant your user shell access, see the following article:

Creating a user with Shell (SSH) access

Directory/filenames which contain non-English/Asian characters show up as ?????? or are corrupt

If you’re having trouble with your filenames or content not showing up correctly, you can activate UTF support by adding the following to your.bash profile file. For instructions on how to edit your existing.bash profile, see the page on creating and editing a file via SSH.

LC ALL=en US is an export option.

UTF-8 \sexport LANG=en US. UTF-8 \sexport LANGUAGE=en US. UTF-8 \sexport G FILENAME ENCODING=UTF-8\
UTF-8 is very certainly already enabled. You may check this in your terminal by typing locale:

[server]

LANG=en US LANG=en US LANG=en US LANG=en US L

LC CTYPE=”e” UTF-8 LANGUAGE=”e” “_The United States_

LC NUMERIC=”en US” UTF-8″

LC TIME=”en US” UTF-8″

LC COLLATE=C LC MONETARY=”en US” UTF-8″ LC COLLATE=C LC MONETARY=”en US”

LC MESSAGES=”en US” UTF-8″

LC PAPER=”en US” UTF-8″

LC NAME=”en US” UTF-8″

LC ADDRESS=”en US” UTF-8″

LC TELEPHONE=”en US” UTF-8″

LC MEASUREMENT=”en US” UTF-8″

LC IDENTIFICATION=”en US” UTF-8″

UTF-8 is a Unicode character set “ALL=LC ALL
The first line is LANG=en US, as you can see.
UTF-8. If this still doesn’t work, the issue is most likely with the terminal client you’re using. Please see the following article for information on how to configure this in PuTTY:

PuTTY

Server unexpectedly closed network connection

If you see this problem when trying to SSH, it’s possible that your IP address has been blacklisted. To see if your IP is blacklisted, contact support. If that’s the case, support can add it to a whitelist. Visit whatismyipaddress.com if you don’t know your IP address.

[User] is not in the sudoers group

For security reasons, GreggHost does not grant standard shell users sudo access to shared servers. While many activities may be completed without sudo, you must upgrade to a Dedicated Server and create an admin user if you require sudo access.

Idle connections are getting dropped

GreggHost and other ISPs may terminate ssh connections that have been idle for more than a set amount of time. In Linux or OSX, the solution is straightforward. All you have to do is enable keep-alive on your computer by modifying the /etc/ssh/ssh config or /.ssh/config file. Add the following to that file:

ServerAliveCountMax 4 Host * ServerAliveInterval 15
The ssh client now requests a sign of life from the server every 15 seconds, keeping the connection active.

Visit the following article for details on how to configure this setting in PuTTY:

Killed

Running processes that demand a lot of memory and/or processor power over SSH may result in their being “Killed” – for more information, check the following article:

On my shared server, why were my processes killed?