Tag Archives: ssh

Hardening SSH on Mikrotik Routers

Posted on by
Reply

Here are the commands you’ll need to harden SSH on your Mikrotik Routers. It looks like it still can use SSH-RSA, but it does get rid of most of the weaker crytpo algorithms.

/ip/ssh/set strong-crypto=yes allow-none-crypto=no always-allow-password-login=no host-key-size=4096

We’ll want to regenerate the Host Key now that the settings have been changed.

/ip/ssh/regenerate-host-key

It will prompt to enter [y/N] to confirm that you actually want to regenerate the host key. Hit y

After your done, you can use something like ssh-audit to check your equipment.
https://www.ssh-audit.com/

Further hardening information is available at the following link.
https://wiki.mikrotik.com/wiki/Manual:Securing_Your_Router

What is Cisco VTY?

Posted on by
Reply

vty stands for Virtual Teletype. What is Teletype?

The teletype, or teleprinter, is a device used for communicating text over telegraph lines, public switched telephone network, Telex, radio, or satellite links.

Wikipedia explanation of teletype

https://en.wikipedia.org/wiki/Teleprinter

This means vty is essentially like a virtual computer screen plugged into the router that we can remotely access.

Both SSH and Telnet use this virtual monitor to let you see the router/switch.

The command 

line vty 0 4

Configures 5 of these virtual teletypes (vty’s) for us to use. Can think of it having 5 monitors connected to the router. When you SSH to it, you are claiming one of these monitors. Cisco devices support up to a maximum of 16. 0-15

Change VLAN ID Ubiquiti Radio from SSH

Posted on by
Reply

First we’ll need to ssh into the device

ssh ubnt@192.168.1.20

Next lets open up the config file 

vi /tmp/system.cfg

Now search for vlan and replace the vlan id with the appropriate number

In VI you can search by hitting / and then type in vlan

After you have changed all the vlan ids, save the file with esc, wq, enter.

Now we can save the config with

cfgmtd -f /tmp/system.cfg -w && reboot

Install and Configure Fail2ban on Fedora/CentOS/RedHat

Posted on by
Reply

The following is a very basic guide for setting up Fail2ban for SSH.

Install and basic config

Install Fail2ban

sudo dnf install fail2ban

You may need to install the epel repo

sudo yum install epel-release

Configure to run on system boot

sudo systemctl enable fail2ban

Start Fail2ban service

sudo systemctl start fail2ban

Copy config file with

sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local

Modify the config file

nano /etc/fail2ban/jail.local

Uncomment the following line and add any IPs that need to be whitelisted

ignoreip = 127.0.0.1/8 ::1 192.168.1.20

Save the file and restart Fail2Ban

sudo systemctl restart fail2ban

Configuring Fail2Ban for SSH

Create a new jail file in /etc/fail2ban/jail.d/ called sshd.local

nano /etc/fail2ban/fail.d/sshd.local

Add the following. Note: if you are using a custom ssh port, change “port = ssh” to “port = portnumber”

[sshd]
enabled = true
port = ssh
action = iptables-multiport
logpath = /var/log/secure
maxretry = 5
bantime = 300

Restart Fail2ban

sudo systemctl restart Fail2ban

You can list the firewall rules to verify that an IP gets banned.

iptables -S | grep ipaddress

Unbanning an IP Address

You can unban an IP address with the following command. 

sudo fail2ban-client set sshd unbanip 192.168.1.100

You can check out the following link for more information

https://www.redhat.com/sysadmin/protect-systems-fail2ban

Troubleshooting SSH “No Matching Key Exchange/Host Key Method/Type Found” errors

Posted on by
Reply

It can be common for older devices to throw errors like the following when trying to ssh into them.

Unable to negotiate with 192.168.1.1 port 22: no matching key exchange method found. Their offer: diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1

or 

Unable to negotiate with 192.168.1.1 port 22: no matching host key type found. Their offer: ssh-rsa

There can also be a No Matching Cipher Found error. We have talked about that in the past.

The issue is that your version of SSH does not support those older, and most likely insecure, Key Exchange and Host Key algorithms types. The errors do give us enough info to add the right options to connect to the device.

No Matching Key Exchange Method Found

For the “no matching key exchange method found.” we need to manually add the KexAlgorithms option. KexAlgorithms means Key Exchange Algorithm.

ssh -o KexAlgorithms=+diffie-hellman-group14-sha1 username@192.168.1.1

Change out “diffie-hellman-group14-sha1” for a supported Key Exchange algorithm.

No Matching Host Key Type Found

This issue is with the Host Key algorithm type. We’ll use the -o option with the HostKeyAlgorithms option.

ssh -o HostKeyAlgorithms=+ssh-rsa admin@192.168.1.1

Change our ssh-rsa with a supported “Their offer:” Host Key.

Putting it all together

You can combine the options if needed.

ssh -o KexAlgorithms=+diffie-hellman-group14-sha1 -o HostKeyAlgorithms=+ssh-rsa admin@192.168.1.1

We have covered some of these topics before. Be sure to check them out.

no matching cipher found. Their offer: aes128-cbc,3des-cbc…

no matching key exchange method found. Their offer: diffie-hellman-group1-sha1

no matching host key type found. Their offer: ssh-dss

fatal: [matrix2.host.com]: UNREACHABLE! => changed=false

Posted on by
Reply
Error while attempting to run playbook
ansible-playbook -i inventory/hosts setup.yml --tags=setup-system-user --ask-become-pass

Looks like the above issue is that Ansible is not able to authenticate with the server. By default it looks to try and use ssh keys, but I don’t have any passwordless ssh keys set up for Ansible to use so it fails while attempting to connect. The work around it to make sure you have sshpass installed and then specify –ask-pass to the end of the command.

ansible-playbook -i inventory/hosts setup.yml --tags=setup-system-user --ask-become-pass --ask-pass

When the command runs it’ll ask you for the ssh password and then use that.

Unable to Remove Authorized SSH Keys from AirOS

Posted on by
Reply

For some reason I ran into an issue where I can not remove authorized SSH Keys in AirOS version 6.3. It redirects to a 404 page and then to the main page.

Attempting to remove SSH keys in AirOS
404 Error while attempting to remove SSH keys

Thankfully, we can still remove the authorized keys from the command line. For more information on making changes over SSH, refer to the following post.

Ubiquiti AirOS – applying changes over ssh

SSH into radio. Replace username and IP address with your radios user and IP.

ssh ubnt@192.168.1.20

Open up config file

vi /tmp/system.cfg

Search for the lines that contain

the sshd.auth.key and remove them

Remove the sshd.auth.key lines

Save the file and write the configuration with

/usr/etc/rc.d/rc.softrestart save

Once the command completes, you should be good to go.

Configure UFW Firewall on Ubuntu

Posted on by
Reply
UFW Firewall Status

Below are some simple commands around working with UFW. UFW is included in Ubuntu. However it may need to be enable.

Show status

sudo ufw status

Disable UFW Service

sudo systemctl stop ufw && sudo systemctl disable ufw

Stop UFW Service

sudo systemctl stop ufw

Start UFW service

sudo systemctl stop ufw

Enable UFW

sudo ufw enable

Allow SSH

sudo ufw allow 22/tcp

Show status

sudo ufw status numbered

Example output

sudo ufw status numbered
Status: active
To            Action   From 
--            ------   ----
[1] 3478/udp  ALLOW IN  Anywhere
[2] 5514/udp  ALLOW IN  Anywhere
[3] 8080/tcp  ALLOW IN  Anywhere
[4] 8443/tcp  ALLOW IN  Anywhere
[5] 8880/tcp  ALLOW IN  Anywhere
[6] 8843/tcp  ALLOW IN  Anywhere
[7] 6789/tcp  ALLOW IN  Anywhere
[8] 27117/tcp ALLOW IN  Anywhere
[9] 22/tcp    ALLOW IN  Anywhere

Delete rule

You need to know the number of the rule you want to delete. Replace number with the number of the rule from the status command

sudo ufw delete number

Reset rules

sudo ufw reset

Allow access to port from specific IP address

Example command allows access to SSH (port 22) from the 172.16.0.0/12 ip range.

sudo ufw allow proto tcp from 172.16.0.0/12 to any port 22

One note: It appears that you need to run the rule with every IP range you want to allow.

Allow access to port from all private IP ranges (RFC 1918)

If we wanted to allow SSH (port 22) from all local IP addresses, we would need to run the following three commands.

sudo ufw allow proto tcp from 10.0.0.0/8 to any port 22
sudo ufw allow proto tcp from 172.16.0.0/12 to any port 22
sudo ufw allow proto tcp from 192.168.0.0/16 to any port 22

The following link has more information regarding UFW firewall and subnets.
https://www.cyberciti.biz/faq/ufw-allow-incoming-ssh-connections-from-a-specific-ip-address-subnet-on-ubuntu-debian/

How To Increase Session Timeout for SSH

Posted on by
Reply

From the server side, edit the /etc/ssh/sshd_config

Change, uncomment, or add

ClientAliveInterval 120
ClientAliveCountMax 15

Change the AliveInterval and CountMax as desired.

More info on the AliveIntercal and CountMax.

ClientAliveCountMax Sets the number of client alive messages which may be sent without sshd(8) receiving any messages back from the client. If this threshold is reached while client alive messages are being sent, sshd will disconnect the client, terminating the session. It is important to note that the use of client alive messages is very different from TCPKeepAlive. The client alive messages are sent through the encrypted channel and therefore will not be spoofable. The TCP keepalive option enabled by TCPKeepAlive is spoofable. The client alive mechanism is valuable when the client or server depend on knowing when a connection has become unresponsive.

The default value is 3. If ClientAliveInterval is set to 15, and ClientAliveCountMax is left at the default, unresponsive SSH clients will be disconnected after approximately 45 seconds. Setting a zero

ClientAliveCountMax disables connection termination.ClientAliveInterval Sets a timeout interval in seconds after which if no data has been received from the client, sshd(8) will send a message through the encrypted channel to request a response from the client. The default is 0, indicating that these messages will not be sent to the client.

More information
https://man.openbsd.org/sshd_config