User Tools

Site Tools


ssh

If you want to send us your comments, please do so. Thanks
More on comments


SSH

How to set up a ssh useing keypairs. The connection is filtered by a firewall

The openssh website

Install

Install task-ssh-server
This installs openssh-server and openssh-sftp-server

Settings

Why putting ssh on another port than 22 is a bad idea. And (dutch): Expert, het aanpassen van de standaardpoort van VNC of SSH is slecht een idee
/etc/ssh/ssh_config (client)
/etc/ssh/sshd_config (server)

Firewall

UFW

For the UFW GUI add under tab Simple

Allow | In | TCP | portnumber

example, do as root (change the IP address 1.2.3.4 to one you need)

ufw allow proto tcp from 1.2.3.4 to any port 22 # 'SSH port 22'

nftables

Add in /etc/nftables.conf something like

tcp dport { 22 } ip saddr 1.2.3.4 accept;

to the

table inet filter {
  chain input {

section

Mitigate brute forece attacks

by

  • turning the DOS (Denial Of Service) prevention on
  • allowing only a limited number of connection attempts in a given time
  • using port knocking
  • limiting the IP numbers that have access

Port knocking

fwknop, FireWall KNock OPerator“, might be a good tool for this. fwknop supports iptables

Keypairs

Preparations

Configure, on the server, in /etc/ssh/sshd_config

For PermitRootLogin set:

OptionExplanation
yesThis is the default
prohibit-passwordroot can not login with a password
forced-commands-onlyroot can login with public key authentication
noroot can not login. Not with a password nor with a key

To be sure set

PermitRootLogin no

so root can not login
If you want root to be able to login with a key use

PermitRootLogin without-password

on the server

Generation

Check for an existing key

Check, on the client, in $HOME/.ssh, if you had already generated a keypair
Login on the server and check if there is already a key for your local machine

ssh -p portnumber user@192.168.0.0
less $HOME/.ssh/authorized_keys

If there is already a key, and you do not want to replace it, you can use that key. Try if it works by executing on your local machine

ssh -i $HOME/.ssh/otherThanDefaultKeyFilename -p portnumber user@192.168.0.0

If so, you are ready
If not, continue

Generate

  • Generate a keypair on your local machine for the normal user (not on the server). Choose on of
    • Use the one with a keyname you can make up (the first command). It is advisable to use the hostname of the remote computer
    • Use the one with the default keyname (the second command)
  • If asked for a passphase do not enter one (handy for scripts) unless you need one
  • Save the output of the command, by scraping the screen, to a text file in $HOME/.ssh with the same name as the keyfile but extension .txt


Use a key of at least 2048 bits

ssh-keygen -t rsa -b 4096 -f $HOME/.ssh/otherThanDefaultKeyFilename
ssh-keygen -t rsa

You can check the key length with

ssh-keygen -l -f "$HOME/.ssh/otherThanDefaultKeyFilename"

Change permissions

cd $HOME/.ssh/
chmod 400 * (key files)
chmod 600 authorized_keys known_hosts

Set

PasswordAuthentication yes

in /etc/ssh/sshd_config Run

  systemctl restart sshd.service

Copy the key to the server

ssh-copy-id -i $HOME/.ssh/otherThanDefaultKeyFilename -p portnumber user@192.168.0.0

You should get

/usr/bin/ssh-copy-id: INFO: Source of key(s) to be installed: "$HOME/.ssh/RemoteHostname.pub"
/usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed
/usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keys
user@192.168.0.0 password:

Number of key(s) added: 1

Now try logging into the machine, with:   "ssh -p '22' 'user@192.168.0.0'"
and check to make sure that only the key(s) you wanted were added.

Set

PasswordAuthentication no

in /etc/ssh/sshd_config if it was set otherwise before Run

  systemctl restart sshd.service

Check if you can login with

ssh -i $HOME/.ssh/otherThanDefaultKeyFilename -p portnumber user@192.168.0.0

Check the added key on the server after being logged in

less $HOME/.ssh/authorized_keys

Create an alias

alias sremothostname='ssh -i $HOME/.ssh/otherThanDefaultKeyFilename -p portnumber user@192.168.0.0'

Other checks if needed

Check, on the server, if only one key is added to $HOME/.ssh/authorized_keys with

cat $HOME/.ssh/authorized_keys

and compare with the previous cat command to make sure that only the key(s) you wanted were added
Restart the sshd server. Use one of

  • systemctl restart sshd
  • /etc/init.d/ssh restart
  • systemctl reload sshd.service (on a systemd system)

Replace keypair

User .ssh/config file

There can be a user configfile

$HOME/.ssh/config

In it you can specify default settings per host

Host hostname
User username
IdentityFile ~/.ssh/somekeyfile

Disable password login

PAM: Pluggable Authentication Modules

In /etc/ssh/sshd_config set

  • ChallengeResponseAuthentication no
  • PasswordAuthentication no
  • PermitRootLogin no
  • UsePAM no

Errors

Connection Lost

  1. Authentication method 'password' failed. This is caused by a timeout which occurs after the timeout time is finished when no password is enterd
    1. Try to disconnect and reconnect again.

Connection refused

ssh: connect to host 192.168.0.1: Connection refused

  1. Check if you have the right IP adress
  2. Check if you have the right port number
  3. It is possible that the host is not up yet. Wait a few minutes and try again
  4. (Re)Start the ssh server.
    • Debian: systemctl restart sshd . Check with systemctl status sshd
    • LineageOS ssh . Check with ps -e | grep ssh
  5. Some drive may have failed to mount. The system has booted in rescue mode. This can also be the RAID drive
    1. Log in locally to check or if that is not possible place the harddrive in an other computer
      1. vi /etc/fstab and comment out the entries of the suspect drives
      2. Place the drive back in the original computer if applicable
      3. Uncomment one of the commented drive entries in /etc/fstab
      4. Save /etc/fstab
      5. mount -a
      6. Check if the drive is accesable
      7. Repeat for other drives
      8. If there is a RAID drive in the computer see also our Software raid page on how to start the RAID drive
  6. This can be occur by a reboot without a keyboard connected to the PC. Connect a keyboard an try again

Connection timed out

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

  1. Maybe there is a settings issue with the firewall on the client or the host

Load key invalid format

Load key "$HOME/.ssh/Server.pub": invalid format

You used the Server.pub where the Server file (without ”.pub“) is needed

No reaction

No reaction after ssh user@192.168.1.1

  1. Check if you are using the right port number. The default port number is 22
  2. Check the firewall rules

No route to host

ssh: connect to host 10.0.0.1 port 22: No route to host
  1. Check if the computer on the other end is running
  2. Check the IP number of the client with ip addr
  3. Check the permissions in any firewall involved
  4. Check the portforwarding in any router involved

Permission denied

Permission denied, please try again
  1. Check if you typed the password correctly
  2. Check the firewall rule. If possible turn both firewalls off and check again
  3. Check the portnumber in the config files
  4. Restart ssh

Remote host identification has changed

When you get

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a host key has just been changed.
The fingerprint for the ECDSA key sent by the remote host is
SHA256:somehash.
Please contact your system administrator.
Add correct host key in $HOME/.ssh/known_hosts to get rid of this message.
Offending ECDSA key in $HOME/.ssh/known_hosts:10
remove with:
ssh-keygen -f "$HOME/.ssh/known_hosts" -R [192.168.0.1]:22
ECDSA host key for [192.168.0.1]:22 has changed and you have requested strict checking.
Host key verification failed.

Do

ssh-keygen -f "$HOME/.ssh/known_hosts" -R [192.168.0.1]:22

or

ssh-keygen -f "$HOME/.ssh/known_hosts" -R 192.168.0.1

then

ssh -p 22 user@192.168.0.1

Now you should get

The authenticity of host '[192.168.0.1]:22 ([192.168.0.1]:22)' can't be established.
ECDSA key fingerprint is SHA256:somehash.
Are you sure you want to continue connecting (yes/no)?

Answer yes and you should get

Warning: Permanently added '[192.168.0.1]:22' (ECDSA) to the list of known hosts.
Authentication failed.

Do

ssh -p 22 user@192.168.0.1

and you should get

user@192.168.0.1's password:

and you should be able to login. If not, check with the other issues mentioned on this page

Broken pipe

packet_write_wait: Connection to 192.168.1.1 port 22: Broken pipe

This is probably due to connection inactivity

cannot create .ssh/authorized_keys

sh: 1: cannot create .ssh/authorized_keys: Permission denied
  • Check the permissions for $HOME/.ssh . They should be 700
  • Check the permissions for $HOME/.sshauthorized_keys . They should be 600
  • On the server do chown -R user:user $HOME/.ssh

ssh suddenly asks for a password

Check, on the server, /var/log/auth and look for Authentication refused: bad ownership or modes for directory $HOME/.ssh

On the client do, and try if it works after each step,

  • chmod 700 ~/.ssh
  • chmod 644 ~/.ssh/authorized_keys
  • chmod 600 ~/.ssh/keyfile
  • chmod 644 ~/.ssh/keyfile.pub
  • chown -R user:user $HOME/.ssh
  • ssh-copy-id -i $HOME/.ssh/otherThanDefaultKeyFilename -p 22 user@192.168.1.1
  • Not advised: Set in /etc/ssh/sshd_conf StrictModes off

On the server do, and try if it works after each step,

  • chown -R user:user $HOME/.ssh
  • Start sshd in debug mode on the server machine /usr/sbin/sshd -d -e -p 1234 (-d: debug -e: write to standard error -p: port 1234: portnumber)
  • systemctl restart sshd.service

Keep your Linux ssh session from disconnecting
SSH passwordless login with keychain for scripts
SSH key strength
How to use ssh public key authentication


Main subjects on this wiki: Linux, Debian, HTML, Microcontrollers, Privacy

RSS
Disclaimer
Privacy statement
Bugs statement
Cookies
Copyright © : 2014 - 2024 Webevaluation.nl and the authors
Changes reserved.

This website uses cookies. By using the website, you agree with storing cookies on your computer. Also you acknowledge that you have read and understand our Privacy Policy. If you do not agree leave the website.More information about cookies
ssh.txt · Last modified: 25-08-2023 15:05 by wim