🔐 #ssh Favorit Snipps

_readme.md

Copying your Public Key Using SSH

cat ~/.ssh/id_rsa.pub | ssh username@remote_host "mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys"

To start the SSH Agent, type the following into your local terminal session:

eval $(ssh-agent)

start the agent when we login What we need is to start the agent when we login to our client machine’s shell and stop it when we log out. So, we add the following line to ~/.bash_profile:

eval `ssh-agent`

We add the following line to ~/.bash_logout

eval `ssh-agent -k`

To add a key to the ssh-agent’s cache, we issue the command:

ssh-add ~/.ssh/id_dsa

list the cached keys we type:

ssh-add -l

To remove a cached key:

ssh-add -d ~/.ssh/id_dsa

To empty the ssh-agent’s cache:

ssh-add -D

copy key to server

type c:\users\my_name\.ssh\id_rsa.pub | ssh [email protected] "cat >> ~/.ssh/authorized_keys"

ssh agent for one time

ssh-agent $(ssh-add cat ~/.ssh/id_github; git clone [email protected]:USER/REPO.git REPOFOLRDER)

putty autologin

putty.exe -ssh -P 2222 [email protected] -pw password

ssh-server-config.md

The SSH Server configuration

The SSH server’s configuration file is /etc/ssh/sshd_config. Most of the default options do not need to be modified. What we’ll do is to set it up so that only the members of the "sshusers" group can authenticate using keys instead of passwords. So, as root, fire up your favourite text editor and edit the server configuration file.
NOTE: It’s a good habit to create backups before editing system files.
The options that need to be modified are shown below:

Port 22
Protocol 2
AddressFamily inet
ListenAddress 192.168.0.1

With these we configure the server to listen on port 22, accept connections only over the SSH-2 protocol, use the IPv4 address family and bind on the 192.168.0.1 IP address. Only the "protocol" option is really critical. You can set the others as you like or leave the defaults.

HostKey /etc/ssh/ssh\_host\_dsa_key

Uncomment or add this line. This is exactly the same as the default option, but needs to be uncommented in the server configuration file, so that the server shows its DSA key’s fingerprint when the client tries to authenticate the server during the connection process. If this is not set, then the server shows its RSA key’s fingerprint (the reason is unknown to me).

LoginGraceTime 2m
PermitRootLogin no
MaxAuthTries 1

The LoginGraceTime option sets a time limit for the user authentication process. If this time passes and the user has not yet authenticated succesfully, then the server closes the connection. Leave this value to the default "2m" until everything is set up properly, so that you have enough time to read any server messages. After that, you can lower it to a reasonable value. I have set it to "20s".
Setting the "PermitRootLogin" option to "no" the server does not allow root to login directly. You can still use "su" after you have succesfully logged in as a normal user.
The "MaxAuthTries" option sets the maximum login attempts per connection. Since we use keys and key validation never fails, we set it to "1".

PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys

These are the default options. I just add them here so that you make sure they are set up properly in your config.

RSAAuthentication no
PasswordAuthentication no
\# (UPDATE: Jan 11, 2015: 'UsePAM no' is not supported in
\# Red Hat Enterprise Linux and may cause several problems.
UsePAM yes
KerberosAuthentication no
GSSAPIAuthentication no

We do not want the server to let users authenticate using passwords or use SSH-1 based authentication methods. You should comment out any Kerberos or GSSAPI options too.

AllowGroups sshusers

Only users that belong to the "sshusers" group can authenticate. Any other user will be rejected without even being given the oportunity to authenticate.

MaxStartups 2

This option specifies the maximum number of concurrent unauthenticated connections to the SSH Server. It has nothing to do with the number of authenticated connections. The default value is "10". We lower this value in order to limit the connections from third parties which do not have an account on our server machine.

Banner /etc/ssh/banner

Finaly, you can set a text file that will be displayed as a banner when someone connects to the server. Just remember that it is displayed before the authentication takes place, so do not be very descriptive. The banner is not really needed.

This is all we have to do. The rest of the configuration options should be left to their default values, unless you need something different. This is up to you.

Restarting the server

Now, that we have finished editing the config file, we need to restart the server, so that our changes take effect. Before that, I would recommend deleting any existing server keys. Don’t worry, they will be recreated as soon as the service is restarted. A quick way to delete all the keys is to:

\# rm -f ssh_host\*key\*

Then restart the server:

\# service sshd restart

Note that the key creation time may vary from machine to machine, so it may take a few minutes if the CPU is slow.

The server logging is done through syslog and authentication information is sent to /var/log/secure. This file should not be world-readable.

A last thing is to take a note of the server’s DSA public key fingerprint, so that we can compare it with the fingerprint the server sends to our client when we connect. This is important for connections to the server from locations other than our LAN in order to be sure that we actually connect to our server. On the server console type:

\# ssh-keygen -l -f /etc/ssh/ssh\_host\_dsa_key.pub

Take a note of the fingerprint.

too-many-authentication-failures-for-username.md

Too many authentication failures for username

This is usually caused by inadvertently offering multiple ssh keys to the server. The server will reject any key after too many keys have been offered.

You can see this for yourself by adding the -v flag to your ssh command to get verbose output. You will see that a bunch of keys are offered, until the server rejects the connection saying: "Too many authentication failures for [user]". Without verbose mode, you will only see the ambiguous message "Connection reset by peer".

To prevent irrelevant keys from being offered, you have to explicitly specify this in every host entry in the ~/.ssh/config (on the client machine) file by adding IdentitiesOnly like so:

Host www.somehost.com
  IdentityFile ~/.ssh/key_for_somehost_rsa
  IdentitiesOnly yes
  Port 22

If you use the ssh-agent, it helps to run ssh-add -D to clear the identities.

If you are not using any ssh hosts configuration, you have to explicitly specify the correct key in the ssh command like so:

ssh -i some_id_rsa -o 'IdentitiesOnly yes' them@there:/path/

Note: the 'IdentitiesOnly yes' parameter needed to be between quotes.

or

ssh -i some_id_rsa -o IdentitiesOnly=yes them@there:/path/