I recently installed Fedora 27 on my personal laptop alongside Windows. So far Fedora 27 feels very polished and it recognized almost everything out of the box, including sleeping when I close the lid.
There were, however, a few things I did that went beyond the usual click-click install experience, so I thought I would share:
1) The new Fedora install still boots into Windows
There's a new Fedora media installer executable that downloads the ISO and prepares a USB drive for you, and upon booting from said USB, installation is relatively straight-forward. The installation took care of creating free space from my existing NTFS partition, and automatic partitioning created a /boot, / and swap partition.
However, after rebooting my laptop ran Windows again, instead of Grub - this is typical of UEFI installations. The Fedora installation did create a new entry for itself, but it was missing one for Grub. I am not sure if this is by design, or a product of having a password on my BIOS, etc.
To fix this, we must add Grub to the authorized UEFI files. Find where your BIOS allows you to add UEFI files as "trusted for executing" and point it to
HD / EFI / Fedora / grubx64.efi (you must provide a name, I chose Fedora Grub)
Save the settings. You may only have an option to save and exit, like me.
Then, you must make sure that the Grub option that now appears in your boot priority list is listed before "Windows Boot Manager". Voila, it works, and this includes after updating Fedora.
2) Gnome (by default) doesn't show files in the Desktop
You can either install the gnome-tweak-tool, or just run the following in an unprivileged terminal (I think this is a per-user setting)
gsettings set org.gnome.desktop.background show-desktop-icons true
3) Touchpad does not support tap-to-click (ie, like a Mac).
In the Settings app, choose Devices, Mouse & Touchpad, and in the Touchpad section, turn on "Tap to click".
Saturday, November 25, 2017
Thursday, October 19, 2017
My simple cheat-sheet of Git bash commands
This post has several assumptions!
1) You are working on a Windows machine with https://git-for-windows.github.io/ already installed.
2) You already have a Github user and have created a repository with content
3) Assumes you already have created a github ssh key and its already working - I will make a blog post about doing this easily soon!
4) This also only works when you are only working on the ONE default branch!!
Essential Github bash commands:
To clone something you have in the Github site to your PC
On the webpage:
- Go to your profile and click on the repo
- Find the "clone or download" button
- Click Get SSH if you need, and copy something like git@github.com:arielsanchezmora/arielsanchezmora.github.io.git to your clipboard.
Open Git Bash:
- Find the directory where you want to copy the repository to
- In the Git Bash Window type "cd /c/....(the path, but in linux format. use "pwd" if you get lost on how to format it)
- Git clone [what you had copied from the webpage: git@github.com....]
(type ssh key password if needed)
To return changes to Github
Change to the cloned folder (it will have a hidden .git folder) before executing the below. The other files should have changed before you run these commands.
git status to see the changes (red is unstaged changes)
git add . (the dot means all files/subfolders)
git status (green shows changes have been staged)
git commit -m "add a comment to your code change" (otherwise, hi vi!)
git status will show your local branch is ahead of the Github site
git push origin master will sync your changes back to Github :)
1) You are working on a Windows machine with https://git-for-windows.github.io/ already installed.
2) You already have a Github user and have created a repository with content
3) Assumes you already have created a github ssh key and its already working - I will make a blog post about doing this easily soon!
4) This also only works when you are only working on the ONE default branch!!
Essential Github bash commands:
To clone something you have in the Github site to your PC
On the webpage:
- Go to your profile and click on the repo
- Find the "clone or download" button
- Click Get SSH if you need, and copy something like git@github.com:arielsanchezmora/arielsanchezmora.github.io.git to your clipboard.
Open Git Bash:
- Find the directory where you want to copy the repository to
- In the Git Bash Window type "cd /c/....(the path, but in linux format. use "pwd" if you get lost on how to format it)
- Git clone [what you had copied from the webpage: git@github.com....]
(type ssh key password if needed)
To return changes to Github
Change to the cloned folder (it will have a hidden .git folder) before executing the below. The other files should have changed before you run these commands.
git status to see the changes (red is unstaged changes)
git add . (the dot means all files/subfolders)
git status (green shows changes have been staged)
git commit -m "add a comment to your code change" (otherwise, hi vi!)
git status will show your local branch is ahead of the Github site
git push origin master will sync your changes back to Github :)
Wednesday, March 29, 2017
Disable TLS v1.0 and v1.1 in vSphere 6.0
This is a very rough post with the base information - I will make this part of a series soon.
This quick post only focuses on the use of the TLS tool in vSphere 6.0 in a very simple environment (VCSA with embedded PSC, hosts in the 3 situations used in the tool) for demonstration purposes.
Also, note that only port 443 is tested, but both vSphere and ESXi have many other ports, some even outside of the TLS tool configuration.
This post focuses on only leaving TLS 1.2 enabled. Other posts which helped me and constitute good reading are:
https://techbrainblog.com/2015/03/30/how-to-scp-files-to-vmware-vcenter-appliance-6-0-vcsa/ by GaneshSekarbabu
https://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2054085
http://www.justmy02centsworth.com/2016/11/pci-dss-tls-10-disablement-and-vmware.html by DanRaymond65
We will basically put in practice KB 2148819:
https://kb.vmware.com/selfservice/search.do?cmd=displayKC&docType=kc&docTypeID=DT_KB_1_1&externalId=2148819
Before we start, make super sure you are running at least 6.0 Update 3 and your vCenter and hosts are on the same release! Also download the rpm version of the TLS tool from the same location where the VCSA is downloaded from.
If you are going to do the whole environment, the basic order is:
1) vCenters
2) hosts
3) PSCs
Steps needed to be able to run the tool:
#Open SSH (or use the VCSA console). You may need to follow this if it's not enabled already
#It's always a good idea to verify the SSH keys match
#Now execute these commands. Enable Bash shell:
shell.set --enable True
#Launch the "Bash" shell which is really a "pi shell":
shell
#Change shell to Bash so SCP works (doesn't otherwise, not explained in the KB)
chsh -s "/bin/bash" root
*Go copy the TLS RPM file to the VCSA now*
#I copied the file to /tmp (or wherever, but notice you have to change the directory to what you used)
cd /tmp
#U is upgrade (assumes install if no older version found), v is verbose, h is hash (progress display)
rpm -Uvh VMware-vSphereTlsReconfigurator-6.0.0-5051284.x86_64.rpm
#Change directory to where TLS Reconfigurator was installed to
cd /usr/lib/vmware-vSphereTlsReconfigurator/
vCenter and PSC steps
#Switch to vCenter tool directory
cd VcTlsReconfigurator
#Take a backup as per the KB
./reconfigureVc backup
*Go copy the backup directory to a safe place. Why? WHY NOT?*
Note a scan of port 443 before running the tool using sslscan (from a windows executable) shows TLS 1.0 and 1.1 are active:
#Do some damage! I mean, set TLS v1.2 as the only accepted protocol
./reconfigureVc update -p TLSv1.2
#Type a "y" to proceed. It doesn't really re-start the whole appliance, just the services
#Note it actually takes another backup. Gotta protect GSS :)
#Finally you will get a status report which confirms that only TLS v1.2 is configured
#The vSphere Client service takes a little longer to start than the rest. You can monitor it via the shell with
service vsphere-client status
#Note a scan of port 443 after running the tool shows only TLS 1.2 is now enabled:
ESXi steps
#Hosts MUST be rebooted after these commands for all changes to take effect!!
#Switch to ESX tool directory
cd /usr/lib/vmware-vSphereTlsReconfigurator/EsxTlsReconfigurator
You have 3 options for host changes - by cluster, by host joined to this vCenter, or standalone hosts.
#If you are doing hosts joined to a vCenter inside a Cluster (this does the whole cluster)
#./reconfigureEsx vCenterCluster -c <Cluster_Name> -u <Administrative_User> -p TLSv1.2
./reconfigureEsx vCenterCluster -c MyCluster -u administrator@vsphere.local -p TLSv1.2
#It asks for the user's passwords and executes
#Don't forget to reboot the host!
#Scan before change
#Scan after change and reboot
#If you are doing one host joined to a vCenter
#./reconfigureEsx vCenterHost -h <ESXi_Host_Name> -u <Administrative_User> -p TLSv1.2
./reconfigureEsx vCenterHost -h 192.168.1.102 -u administrator@vsphere.local -p TLSv1.2
#It asks for the user's passwords and executes
#Don't forget to reboot the host!
#Scan before change
#Scan after change and reboot
#If you are doing a host that is not joined to a vCenter
#./reconfigureEsx ESXiHost -h <ESXi_Host_Name> -u <User> -p TLSv1.2
./reconfigureEsx ESXiHost -h 192.168.1.103 -u root -p TLSv1.2
#Note this uses a local ESXi account since this host is not in this vCenter
#Don't forget to reboot the host!
#Scan before change
#Scan after change and reboot
Hope this helps. I'll go into a bit more detail as soon as I have some time! Ping me on twitter if you have any comments please.
This quick post only focuses on the use of the TLS tool in vSphere 6.0 in a very simple environment (VCSA with embedded PSC, hosts in the 3 situations used in the tool) for demonstration purposes.
Also, note that only port 443 is tested, but both vSphere and ESXi have many other ports, some even outside of the TLS tool configuration.
This post focuses on only leaving TLS 1.2 enabled. Other posts which helped me and constitute good reading are:
https://techbrainblog.com/2015/03/30/how-to-scp-files-to-vmware-vcenter-appliance-6-0-vcsa/ by GaneshSekarbabu
https://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2054085
http://www.justmy02centsworth.com/2016/11/pci-dss-tls-10-disablement-and-vmware.html by DanRaymond65
We will basically put in practice KB 2148819:
https://kb.vmware.com/selfservice/search.do?cmd=displayKC&docType=kc&docTypeID=DT_KB_1_1&externalId=2148819
Before we start, make super sure you are running at least 6.0 Update 3 and your vCenter and hosts are on the same release! Also download the rpm version of the TLS tool from the same location where the VCSA is downloaded from.
If you are going to do the whole environment, the basic order is:
1) vCenters
2) hosts
3) PSCs
Steps needed to be able to run the tool:
#Open SSH (or use the VCSA console). You may need to follow this if it's not enabled already
#Now execute these commands. Enable Bash shell:
shell.set --enable True
#Launch the "Bash" shell which is really a "pi shell":
shell
#Change shell to Bash so SCP works (doesn't otherwise, not explained in the KB)
chsh -s "/bin/bash" root
*Go copy the TLS RPM file to the VCSA now*
#I copied the file to /tmp (or wherever, but notice you have to change the directory to what you used)
cd /tmp
#U is upgrade (assumes install if no older version found), v is verbose, h is hash (progress display)
rpm -Uvh VMware-vSphereTlsReconfigurator-6.0.0-5051284.x86_64.rpm
#Change directory to where TLS Reconfigurator was installed to
cd /usr/lib/vmware-vSphereTlsReconfigurator/
vCenter and PSC steps
#Switch to vCenter tool directory
cd VcTlsReconfigurator
#Take a backup as per the KB
./reconfigureVc backup
*Go copy the backup directory to a safe place. Why? WHY NOT?*
Note a scan of port 443 before running the tool using sslscan (from a windows executable) shows TLS 1.0 and 1.1 are active:
#Do some damage! I mean, set TLS v1.2 as the only accepted protocol
./reconfigureVc update -p TLSv1.2
#Type a "y" to proceed. It doesn't really re-start the whole appliance, just the services
#Note it actually takes another backup. Gotta protect GSS :)
#Finally you will get a status report which confirms that only TLS v1.2 is configured
#The vSphere Client service takes a little longer to start than the rest. You can monitor it via the shell with
service vsphere-client status
#Note a scan of port 443 after running the tool shows only TLS 1.2 is now enabled:
ESXi steps
#Hosts MUST be rebooted after these commands for all changes to take effect!!
#Switch to ESX tool directory
cd /usr/lib/vmware-vSphereTlsReconfigurator/EsxTlsReconfigurator
You have 3 options for host changes - by cluster, by host joined to this vCenter, or standalone hosts.
#If you are doing hosts joined to a vCenter inside a Cluster (this does the whole cluster)
#./reconfigureEsx vCenterCluster -c <Cluster_Name> -u <Administrative_User> -p TLSv1.2
./reconfigureEsx vCenterCluster -c MyCluster -u administrator@vsphere.local -p TLSv1.2
#It asks for the user's passwords and executes
#Don't forget to reboot the host!
#Scan before change
#Scan after change and reboot
#If you are doing one host joined to a vCenter
#./reconfigureEsx vCenterHost -h <ESXi_Host_Name> -u <Administrative_User> -p TLSv1.2
./reconfigureEsx vCenterHost -h 192.168.1.102 -u administrator@vsphere.local -p TLSv1.2
#It asks for the user's passwords and executes
#Don't forget to reboot the host!
#Scan before change
#Scan after change and reboot
#If you are doing a host that is not joined to a vCenter
#./reconfigureEsx ESXiHost -h <ESXi_Host_Name> -u <User> -p TLSv1.2
./reconfigureEsx ESXiHost -h 192.168.1.103 -u root -p TLSv1.2
#Note this uses a local ESXi account since this host is not in this vCenter
#Don't forget to reboot the host!
#Scan before change
#Scan after change and reboot
Hope this helps. I'll go into a bit more detail as soon as I have some time! Ping me on twitter if you have any comments please.
Tuesday, February 28, 2017
PowerShell and PowerCLI - scripted addition to "getting started"
In my first post on Powershell/PowerCLI I had ventured the guess that many of the tasks to setup PowerShell/PowerCLI could be scripted. Today I present the script:
Set-ExecutionPolicy Bypass -force
mkdir $env:userprofile\Documents\WindowsPowerShell
mkdir "C:\PowerCLI codes"
$fixPS = @"
Set-Location "C:\PowerCLI codes"
if (`$psISE)
{
Clear-Host
Write-Host 'You can do this!'
}
"@
$fixPS | Out-File -FilePath $env:userprofile\Documents\WindowsPowerShell\profile.ps1 -Encoding ASCII
You can change the directory for your codes and the startup message, and add or remove things, but this will at least create the proper file to set your working directory, and write all lines to the profile.ps1 file.
So to use this:
1) Find powershell on your computer
2) right click, run as administrator
3) paste and execute. This should not prompt you for any questions
4) close that window
5) Use ISE or powershell like your normally would from now on
Let me know if you found this useful. I needed it since I have several jumpboxes and create new VMs, and figuring out where stuff needs to be changed takes much more time than copy pasting my setup in a script :)
Set-ExecutionPolicy Bypass -force
mkdir $env:userprofile\Documents\WindowsPowerShell
mkdir "C:\PowerCLI codes"
$fixPS = @"
Set-Location "C:\PowerCLI codes"
if (`$psISE)
{
Clear-Host
Write-Host 'You can do this!'
}
"@
$fixPS | Out-File -FilePath $env:userprofile\Documents\WindowsPowerShell\profile.ps1 -Encoding ASCII
You can change the directory for your codes and the startup message, and add or remove things, but this will at least create the proper file to set your working directory, and write all lines to the profile.ps1 file.
So to use this:
1) Find powershell on your computer
2) right click, run as administrator
3) paste and execute. This should not prompt you for any questions
4) close that window
5) Use ISE or powershell like your normally would from now on
Let me know if you found this useful. I needed it since I have several jumpboxes and create new VMs, and figuring out where stuff needs to be changed takes much more time than copy pasting my setup in a script :)
Tuesday, January 24, 2017
Learning about vSphere Flash Read Cache
I'm looking at vSphere Flash Read Cache in case that Pernix FVP does not release an update for vSphere 6.5 (after being bought by Nutanix). Using vFRC is a bit different right off the bat, since it doesn't do write acceleration, but since I already have the required vSphere licensing and hardware, there is no cost to enable.
The biggest problems I see so far are:
1) not a lot of reported users, at least that I could find, although it's been kept as a feature by VMware since it was announced so there has to be quite a few. However, I didn't find lots of operational blogs, just feature announcement types.
2) more rigid implementation steps compared to Pernix FVP, which takes some reading to figure out
Biggest differences with Pernix FVP apart from the obvious:
Known KB’s
There are two known issues, and they are easily avoidable as patches were released already, so just make sure you are running latest before enabling
https://kb.vmware.com/selfservice/microsites/search.do?cmd=displayKC&docType=kc&externalId=2114498&sliceId=1&docTypeID=DT_KB_1_1&dialogID=381661788&stateId=0%200%20381669816
https://kb.vmware.com/selfservice/microsites/search.do?cmd=displayKC&docType=kc&externalId=2072392&sliceId=1&docTypeID=DT_KB_1_1&dialogID=381647699&stateId=0%200%20381651933
Documentation
http://pubs.vmware.com/vsphere-65/index.jsp#com.vmware.vsphere.storage.doc/GUID-07ADB946-2337-4642-B660-34212F237E71.html
http://www.vmware.com/content/dam/digitalmarketing/vmware/en/pdf/techpaper/vmware-vsphere-flash-read-cache-faq.pdf << particularly useful
http://www.vmware.com/content/dam/digitalmarketing/vmware/en/pdf/techpaper/vmware-vfrc-performance-vsphere55-white-paper.pdf << cool read
Blog posts
http://cormachogan.com/2014/02/14/a-closer-look-at-vsphere-flash-read-cache-vfrc/
http://nolabnoparty.com/en/vmware-vflash-read-cache-setup/
http://everything-virtual.com/vmware-study-guides/vcap-dca-study-guide/configure-and-manage-vsphere-flash-read-cache/
http://www.settlersoman.com/what-is-and-how-to-configure-vmware-vsphere-flash-read-cache-vfrc/
http://www.vladan.fr/vmware-vflash-read-cache-vfrc/
The biggest problems I see so far are:
1) not a lot of reported users, at least that I could find, although it's been kept as a feature by VMware since it was announced so there has to be quite a few. However, I didn't find lots of operational blogs, just feature announcement types.
2) more rigid implementation steps compared to Pernix FVP, which takes some reading to figure out
Biggest differences with Pernix FVP apart from the obvious:
- Instead of enabling per cluster, you have to enable it per disk on the VMs, and have to choose the block size. This means you have to use something like vSCSIstats to determine your workload, and then you will only be able to accelerate the block sizes that match, which is never 100% of storage i/o. You can change the block size of a running VM; this can be enabled/disabled while the VM is running as well.
- Implementing this requires VMs to be running HW v10 – I know lots of admins that don't religiously update their VM hardware after an upgrade, so this should be called out.
- There have been no updates in functionality since the v1.0 release in vSphere 5.5. Good news is VMware continues supporting it, and the SSD model I'm interested in is listed in the HCL for 6.5 http://www.vmware.com/resources/compatibility/detail.php?deviceCategory=vfrc&productid=36248&deviceCategory=vfrc&details=1&releases=273&deviceTypes=18&partner=454&page=1&display_interval=10&sortColumn=Partner&sortOrder=Asc
Known KB’s
There are two known issues, and they are easily avoidable as patches were released already, so just make sure you are running latest before enabling
https://kb.vmware.com/selfservice/microsites/search.do?cmd=displayKC&docType=kc&externalId=2114498&sliceId=1&docTypeID=DT_KB_1_1&dialogID=381661788&stateId=0%200%20381669816
https://kb.vmware.com/selfservice/microsites/search.do?cmd=displayKC&docType=kc&externalId=2072392&sliceId=1&docTypeID=DT_KB_1_1&dialogID=381647699&stateId=0%200%20381651933
Documentation
http://pubs.vmware.com/vsphere-65/index.jsp#com.vmware.vsphere.storage.doc/GUID-07ADB946-2337-4642-B660-34212F237E71.html
http://www.vmware.com/content/dam/digitalmarketing/vmware/en/pdf/techpaper/vmware-vsphere-flash-read-cache-faq.pdf << particularly useful
http://www.vmware.com/content/dam/digitalmarketing/vmware/en/pdf/techpaper/vmware-vfrc-performance-vsphere55-white-paper.pdf << cool read
Blog posts
http://cormachogan.com/2014/02/14/a-closer-look-at-vsphere-flash-read-cache-vfrc/
http://nolabnoparty.com/en/vmware-vflash-read-cache-setup/
http://everything-virtual.com/vmware-study-guides/vcap-dca-study-guide/configure-and-manage-vsphere-flash-read-cache/
http://www.settlersoman.com/what-is-and-how-to-configure-vmware-vsphere-flash-read-cache-vfrc/
http://www.vladan.fr/vmware-vflash-read-cache-vfrc/
Sunday, November 6, 2016
Creating SSH private keys (advice as of 11/2016)
You have probably heard that using SSH keys for authentication is more secure than using usernames and passwords. I'm a total n00b at this, so take all of this advice with a grain of salt. If you find i'm giving bad advice, please let me know in the comments.
SSH keys are made in pairs - the public (which whatever wants to authenticate you must have) and the private (which only you should have). To create the SSH keys, you use a command called ssh-keygen . This is part of the OpenSSH software released by the OpenBSD Project, supported by the OpenBSD Foundation. Most nix style operating systems use this software, which is amazing considering how small the OpenBSD community is - small, yet technically deep and experienced :)
Anyways, I was trying to find some guidelines on creating secure SSH keys. Most Google documents that turned up are outdated. From what little I've learned reading I came away with:
1) RSA: at least 2048, but this is the least secure of the modern options
2) Use bcrypt
3) Use the new key format in OpenSSH with option -o
From the documentation:
-o
Causes ssh-keygen to save private keys using the new OpenSSH format rather than the more compatible PEM format. The new format has increased resistance to brute-force password cracking but is not supported by versions of OpenSSH prior to 6.5. Ed25519 keys always use the new private key format.
So, let's see what happens on my freshly installed and patched Ubuntu 16.04 LTS laptop:
Let's make sure we are on a modern version
~$ ssh -V
OpenSSH_7.2p2 Ubuntu-4ubuntu2.1, OpenSSL 1.0.2g 1 Mar 2016
So, what are the current default options? I ran the ssh-keygen command without parameters and accepted all defaults, including leaving the passphrase blank:
~$ ssh-keygen
Generating public/private rsa key pair.
Enter file in which to save the key (/home/user/.ssh/id_rsa):
Created directory '/home/user/.ssh'.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/user/.ssh/id_rsa.
Your public key has been saved in /home/user/.ssh/id_rsa.pub.
The key fingerprint is:
SHA256:[lots of characters here] user@laptophostname
The key's randomart image is:
+---[RSA 2048]----+
[lots of ASCII characters here]
+----[SHA256]-----+
SSH keys are made in pairs - the public (which whatever wants to authenticate you must have) and the private (which only you should have). To create the SSH keys, you use a command called ssh-keygen . This is part of the OpenSSH software released by the OpenBSD Project, supported by the OpenBSD Foundation. Most nix style operating systems use this software, which is amazing considering how small the OpenBSD community is - small, yet technically deep and experienced :)
Anyways, I was trying to find some guidelines on creating secure SSH keys. Most Google documents that turned up are outdated. From what little I've learned reading I came away with:
1) RSA: at least 2048, but this is the least secure of the modern options
2) Use bcrypt
3) Use the new key format in OpenSSH with option -o
From the documentation:
-o
So, let's see what happens on my freshly installed and patched Ubuntu 16.04 LTS laptop:
Let's make sure we are on a modern version
~$ ssh -V
OpenSSH_7.2p2 Ubuntu-4ubuntu2.1, OpenSSL 1.0.2g 1 Mar 2016
So, what are the current default options? I ran the ssh-keygen command without parameters and accepted all defaults, including leaving the passphrase blank:
~$ ssh-keygen
Generating public/private rsa key pair.
Enter file in which to save the key (/home/user/.ssh/id_rsa):
Created directory '/home/user/.ssh'.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/user/.ssh/id_rsa.
Your public key has been saved in /home/user/.ssh/id_rsa.pub.
The key fingerprint is:
SHA256:[lots of characters here] user@laptophostname
The key's randomart image is:
+---[RSA 2048]----+
[lots of ASCII characters here]
+----[SHA256]-----+
Seems if we just execute ssh-keygen with no options and press enter, we get a 2048 RSA key with a SHA256 cipher.
We can now run "ls -a" and see that a new .ssh directory was created. Inside it are two keys, our private (which only we should see from now on) and a .pub , the public matching pair that we would install where we want to have remote access:
~/.ssh$ ls
id_rsa id_rsa.pub
~/.ssh$ cat id_rsa
-----BEGIN RSA PRIVATE KEY-----
[lots of characters here]
~/.ssh$ cat id_rsa.pub
ssh-rsa [lots of characters here] user@laptophostname
So we see that in the public key, we are sharing some information about us, that we probably want to avoid - even if this is meant to be a public key, we don't want to give more detail than needed to a potential attacker.
We can check the details of an existing key with
~/.ssh$ ssh-keygen -l -f keyfile_name
2048 SHA256:[lots of characters here] user@laptophostname (RSA)
One thing to note is that the output of this previous command is the same for the public or private key - this means that it's useful to make sure they are indeed a pair!
Ok, fun enough, but let's delete this folder and try to create a more secure key.
~$ rm -r ./.ssh/
The current recommendation is to use ed25519 type keys instead of RSA. This is done with the -t option:
ssh-keygen -t ed25519
Note that when we explore the resulting files, the names and contents are a bit different
~/.ssh$ cat id_ed25519.pub
ssh-ed25519 [lots of characters here] user@laptophostname
~/.ssh$ cat id_ed25519
-----BEGIN OPENSSH PRIVATE KEY-----
~/.ssh$ cat id_ed25519
-----BEGIN OPENSSH PRIVATE KEY-----
~/.ssh$ ssh-keygen -l -f id_ed25519.pub
256 SHA256:[lots of characters here] user@laptophostname (ED25519)
We're supposedly being a bit more secure now. Note that per the documentation, ed25519 is always bit size 256 so there's no point in specifying an option with -b. Also, the new format is used by default with this key type, so the -o parameter isn't needed either.
We can still secure this further. First, let's remove our username and laptop name with -C and a comment inside quotes.
We can still secure this further. First, let's remove our username and laptop name with -C and a comment inside quotes.
~$ ssh-keygen -t ed25519 -C "cat"
Generating public/private ed25519 key pair.
~/.ssh$ ssh-keygen -l -f id_ed25519.pub
256 SHA256:CKhXQLlEa68uLCP9KRAhI9Bmg+0tRdEb47YuO2thuWU cat (ED25519)
Good - we can see that the string I gave as a comment is now shown in place of my username@hostname. Ideally you would put something in here that will help you use this key in the future. Most people create different keys for different services.
Now, let's make it so a brute force attack is tougher on our private key by adding computational rounds with the -a option. Apparently this is a protection we can specify that will future-proof our private keys a bit in case they fall into the wrong hands.
-a rounds
When saving a new-format private key (i.e. an ed25519 key or any SSH protocol 2 key when the -o flag is set), this option specifies the number of KDF (key derivation function) rounds used. Higher numbers result in slower passphrase verification and increased resistance to brute-force password cracking (should the keys be stolen).
I've seen several people online recommend at least 1000 rounds, so this would be the final command:
~$ ssh-keygen -t ed25519 -C "cat" -a 1000
Now, let's make it so a brute force attack is tougher on our private key by adding computational rounds with the -a option. Apparently this is a protection we can specify that will future-proof our private keys a bit in case they fall into the wrong hands.
I've seen several people online recommend at least 1000 rounds, so this would be the final command:
~$ ssh-keygen -t ed25519 -C "cat" -a 1000
Note that I'm allowing the program to prompt for a pass phrase instead of specifying one - this makes it so my pass phrase is not stored in the shell log. A note on the passphrase - you basically want a long, character based pass phrase, not a real English phrase.
At this moment we have generated a "pretty secure" SSH key. The next post will be on actually using them on a local server or in GitHub.
Some links apart from what I already put in the beginning that I found were among the better ones:
At this moment we have generated a "pretty secure" SSH key. The next post will be on actually using them on a local server or in GitHub.
Some links apart from what I already put in the beginning that I found were among the better ones:
- gertvdijk's September 2016 article was the best "overall and up to date" one I found
- The Mozilla foundation has public documentation on SSH best practices which I liked
- A bit older but quite in depth about securing SSH by stribika
Saturday, November 5, 2016
Running Ubuntu 16.04 LTS on Acer Aspire ES1-111M
Lovely laptop, but there are things that don't work out of the box. Linux is fun!
I tried several installation methods and the one that worked the best was UEFI install, connected to the wifi, accepting 3rd party (which does something with Secure Boot) and using LVM. To access all UEFI options you must set an administrator password, which is good policy anyways.
Important notes
- F2 gets you into BIOS mode - press it repeatedly after you see the Acer sign. Since I had the Ubuntu image in a usb drive (made in Windows with Rufus) I needed to set it to boot before my hard drive, or enable the F12 option to get a boot menu
- If you install in UEFI mode, all power options and acer hotkeys work out of the box - did not happen for me when disabling secure boot for a Legacy install. This is why I preferred it
- If after installing in UEFI mode you do not have a boot device, you probably didn't check the "Disable Secure Boot" option in the Ubuntu installer. This is fine - you can leave Secure Boot Enabled, but in the BIOS trusted UEFI boot, you have to add the shimx64.efi. This link is a good walkthrough. If you made a mistake, choose the option to delete all, reboot and then add it
- Trackpad works ok in both Advanced and Basic modes, but you had to choose 3rd party installers in the setup while connected to the internet, and once you log in, press Fn+F7 to enable the mouse (why it's disabled by default is beyond me)
- Two finger scrolling works, but so far, two finger right click doesn't - I really have to right click. It's weird and I'll have to check out why.
- Wireless, bluetooth, volume, screen brightness, sleep - all work
I've seen google results for the Synaptics trackpad state that the I2C tools have to be installed, or blacklisted, or add this to grub... I didn't have to do any of that (and don't see any of those entries in the corresponding files in this working setup) and both setting it to Basic and Advanced work the same on Ubuntu 16.04 LTS. I even like how the mouse responds better in Ubuntu than it did in Windows!
Subscribe to:
Posts (Atom)