Ron and Ella Wiki Page

Extremely Serious

Page 26 of 29

Securing Tinker Board SSH

April 4, 2018 / / 0 Comments
  1. Require the sudoer to prompt for a password by updating the /etc/sudoers file with the following:
    Look for the following:

    %sudo ALL=(ALL) NOPASSWD: ALL

    And update to become the following:

    %sudo ALL=(ALL) ALL
  2. Update the /etc/ssh/sshd_config file to have the following added: 
    PermitRootLogin no
  3. Install fail2ban using the following command: 
    sudo apt-get install fail2ban
  4. Create the file /etc/fail2ban/jail.d/jail.ssh file to have the following: 
    [ssh]
 enabled = true
 port = ssh
 filter = sshd
 logpath = /var/log/auth.log
 maxretry = 6
 bantime = -1
 banaction = iptables-allports
  5. Restart the service using the following command: 
    sudo systemctl restart fail2ban

See Unbanning an IP

Using Putty SSH Key Pair

April 3, 2018 / / 0 Comments
  1. Login to your account on the remote server.
  2. Create a file ~/.ssh/authorized_keys file and placed in the putty public key with the following format:
ssh-rsa <PUBLIC_KEY> <KEY_COMMENT>

Note: If you don’t have a public key generated you can follow the procedure from Generating Putty SSH Key Pair.

If the file already exists then append the public key on a new line with the same format specified earlier.

  1. If necessary update the permission of the authorized_keys file with the following command:
chmod 600 ~/.ssh/authorized_keys
  1. If necessary update the permission of the .ssh directory with the following command:
chmod 700 ~/.ssh
  1. Setup the Pageant (see Using Pageant to hold the Putty Private Key) to hold the private key (and passphrase).
  2. Run the Putty application.
  3. Fill-up Host Name (or IP Address) field with the following format:
<USERNAME>@<HOST_NAME_OR_IP_ADDRESS>

Where fields are defined as follows:

<USERNAME> is the account name used on step 1.

<HOST_NAME_OR_IP_ADDRESS> is the remote server used on step 1.

Example

user@someserver.com

user@192.168.1.200

  1. Click the Open button and expect to be connected to the remote server without it asking you to provide your password (or even your passphrase).

Using Pageant to hold the Putty Private Key

April 3, 2018 / / 0 Comments
  1. Run the Pageant daemon that will listen to a putty SSH connection.
  2. Right click the Pageant icon from the taskbar that can be identified like the following:
  3. Select Add Key.
  4. Browse and select the target private key (i.e. ppk file).
    Note: If you don’t have a private key generated you can follow the procedure from Generating Putty SSH Key Pair.
  5. Supply the passphrase of the key if required.

Passing the Private Key upon running the Pageant Daemon

Every time at a pageant daemon was started the private key must be added. To simplify this, we can add the private key as a parameter on the target field of the shortcut of the pageant daemon like the following:

"<PAGEANT_EXECUTABLE>" "<PRIVATE_KEY>"

Example

Where the fields are defined as:

<PAGEANT_EXECUTABLE> is "C:\putty\bin\pageant.exe"<PRIVATE_KEY> is "C:\private-key.ppk"

Note: If the key has a passphrase it must be provided every time.

Generating Putty SSH Key Pair

April 3, 2018 / / 0 Comments
  1. Run the Puttygen (i.e. Putty Key Generator).
  1. Click the Generate button.
  2. Move the mouse cursor on the blank area provided by the generator.
  3. Update the Key comment field if desired.
  4. Provide an identical passphrase to the following fields if desired:
    • Key passphrase
    • Confirm passphrase
  1. Click Save private key button.
  1. Click Save public key if desired.

The content of public key file is the one to be copied on the server with the following format:

ssh-rsa <CONTINUOUS_PUBLIC_KEY> <KEY_COMMENT>

And the file normally have the following format:

---- BEGIN SSH2 PUBLIC KEY ----
Comment: <KEY_COMMENT>
<DELIMITED_PUBLIC_KEY>
---- END SSH2 PUBLIC KEY ----

You are reading it right, in the file, the public key (i.e. DELIMITED_PUBLIC_KEY) is delimited by a carriage return. Thus, you need to remove it to have the CONTINUOUS_PUBLIC_KEY.

Resetting GitHub Forked Master with Upstream Master Branch

March 27, 2018 / / 1 Comment

If your GitHub forked master branch is ahead from the upstream's master branch and you wanted to make it even (i.e. also lose some work). The following procedure might help you.

Note: If you have your default branch protected perform steps 1, 2, 3, 7, 8 and 9.  Otherwise just do steps 4, 5 and 6.

  1. Open a terminal (i.e. powershell, cmd, bash) and checkout the master of the upstream to a temporary branch (i.e. this could be anything) using the following syntax: 
    git checkout -b <temporary-branch> upstream/master

    Example

    git checkout -b temp-branch upstream/master

    Where <temporary-branch> is temp-branch.

  2. Push the temporary-branch to your origin using the following syntax: 
    git push origin <temporary-branch>

    Example

    git push origin temp-branch

    Using the <temporary-branch> from the example in step 1.

  3. On your browser, access your forked GitHub project and update the default branch to your temporary-branch.
  4. On your terminal (i.e. powershell, cmd, bash), switch to your master branch using the following command: 
    git checkout master
  5. Reset the master based on the upstream's master branch using the following command: 
    git reset --hard upstream/master
  6. Push the update to your master using the following command: 
    git push origin master --force

    Note: If you didn't do step 3 this and the branch is proctected command will fail.

  7. On your browser, access your forked GitHub project and update the default branch to master.
  8. Going back to your terminal, delete the local temporary-branch using the following syntax: 
    git branch -D <temporary-branch>

    Example

    git branch -D temp-branch

    Using the <temporary-branch> from the example in step 1.

  9. Delete the remote temporary-branch on your origin using the following syntax: 
    git push origin --delete <temporary-branch>

    Example

    git push origin --delete temp-branch

    Using the <temporary-branch> from the example in step 1.

Chocolatey Package Manager

March 9, 2018 / / 0 Comments

Introduction

If you are familiar with package manager of linux (e.g. rpm, apt-get, yum, dpkg, …) or mac (i.e. brew) here is the windows version.

Powershell Behind Proxy (if necessary)
Setting default Powershell TLS Protocol (if necessary)

Requirements

• Windows 7+ / Windows Server 2003+
• PowerShell v2+
• .NET Framework 4+ (the installation will attempt to install .NET 4.0 if you do not have it installed)

Installation using Powershell

Set-ExecutionPolicy Bypass -Scope Process -Force; iex ((New-Object System.Net.WebClient).DownloadString('https://chocolatey.org/install.ps1'))

Proxy configuration (if necessary)

choco config set proxy <locationandport>
choco config set proxyUser <username> #optional
choco config set proxyPassword <passwordThatGetsEncryptedInFile> # optional
choco config set proxyBypassList "'<bypasslist, comma separated>'" # optional, Chocolatey v0.10.4 required
choco config set proxyBypassOnLocal true # optional, Chocolatey v0.10.4 required

Example

choco config set proxy http://localhost:8888
choco config set proxyUser bob
choco config set proxyPassword 123Sup#rSecur3
choco config set proxyBypassList "'http://localhost,http://this.location/'" #0.10.4 required
choco config set proxyBypassOnLocal true #0.10.4 required

Usage

Displaying the tool capabilities

choco -?

Useful Commands

CommandDescription
installInstalls a particular package.
list --local-onlyLists installed packages using chocolatey on local machine.
searchSearches a package availability.
uninstallUninstalls a package.
upgradeUpgrades a package.

Alternative to CLI search command

https://chocolatey.org/packages

Reference

https://chocolatey.org/

Configure Tinker Board with Static IP

March 7, 2018 / / 3 Comments
    1. Using terminal go to /etc/network/interfaces.d directory.
    2. Create a file (e.g. ipv4) with the following content for IPv4: 
      auto eth0
 iface eth0 inet static
 address <desired IP address for eth0>
 netmask <valid netmask>
 gateway <gateway address>
 #The following dns-nameservers field is optional
 #dns-nameservers <dns addresses delimited by space>

auto wlan0
 iface wlan0 inet static
 address <desired IP address for wlan0>
 netmask <valid netmask>
 gateway <gateway address>
 #The following dns-nameservers field is optional
 #dns-nameservers <dns addresses delimited by space>

      Example

      auto eth0
 iface eth0 inet static
 address 192.168.0.100
 netmask 255.255.255.0
 gateway 192.168.0.1
 dns-nameservers 8.8.8.8 8.8.4.4

auto wlan0
 iface wlan0 inet static
 address 192.168.0.101
 netmask 255.255.255.0
 gateway 192.168.0.1
    3. Disable the DHCPCD service using the following command: 
      sudo systemctl disable dhcpcd.service
    4. Attach a LAN cable to your tinker board and run the following command: 
      sudo systemctl restart networking

      Check your IP using the following command:

      ip addr show

      You might also want to disable the network manager using the following command if you don't need a desktop UI:

      sudo systemctl disable NetworkManager

       

Transport Layer Security (TLS) Handshake

March 1, 2018 / / 0 Comments
  1. The client sends "client hello" and a number of specifications in plain text, such as the version of the TLS protocol it is running, the list of supported ciphersuites, and other TLS options it may want to use.
  2. The server picks the TLS protocol version for further communication, responds with "server hello", decides on a ciphersuite from the list provided by the client, attaches its certificate and public key and sends the response back to the client. Optionally, the server can also send a request for the client’s certificate and parameters for other TLS extensions.
  3. Assuming both sides are able to negotiate a common version and cipher, and the client is happy with the certificate provided by the server.The client creates a random Pre-Master Secret and encrypts it with the public key from the server's certificate, sending the encrypted Pre-Master Secret to the server.
  4. The server receives the Pre-Master Secret. The server and client each generate the Master Secret and session keys based on the Pre-Master Secret.
  5. The client sends "Change cipher spec" notification to server to indicate that the client will start using the new session keys for hashing and encrypting messages. Client also sends "Client finished" message.
  6. Server receives "Change cipher spec" and switches its record layer security state to symmetric encryption using the session keys. Server sends "Server finished" message to the client.
  7. Client and server can now exchange application data over the secured channel they have established. All messages sent from client to server and from server to client are encrypted using session key.

Reference

« Older posts Newer posts »

© 2024 Ron and Ella Wiki Page

Theme by Anders Noren — Up ↑