Here are some of the Meetup groups that I have participated in:
Plano Software Entrepreneurs Meetup
Here are some of the Meetup groups that I have participated in:
Plano Software Entrepreneurs Meetup
I am running a Linux server at a remote, off the grid, site that I am calling “cave” for the purposes of this post.
The internet access is provided by Mint Mobile, which uses T-Mobile cell towers. T-Mobile does not provide users with publicly addressable IP address. Instead, multiple uses share a single IP address using NAT. I want to SSH into the cave server from anywhere. To do that, I use Reverse SSH tunnelling.
The concept of reverse SSH tunneling is simple. For this, I needed another host (so-called “relay host”) outside the restrictive cave network. The Raspberry Pi I will use is located at my home. It has an IP address that is publicly visible and unique to me. I can connect to it from anywhere on the internet. I will refer to it as the “Pi.”
Then I set up a persistent SSH tunnel from the server in the cave network to the Pi. With that, I can connect “back” to the cave server from the Pi. You can see why this configuration is called “reverse” tunnel.
As long as the Pi is reachable, I can connect to the cave server from wherever I am regardless of how restrictive T-Mobile’s NAT is – and regardless of how restrictive my in-bound firewall rules are on the cave’s network.
Let’s see how we can create and use a reverse SSH tunnel. We assume the following. We will be setting up a reverse SSH tunnel from the cave server to the Pi so that we can SSH to cave server via the Pi from another computer, such as a laptop. Let’s call that computer “laptop.”
Assume the public IP address of the Pi is 173.173.63.132.
On cave server, open an SSH connection to the Pi as follows:
caveserver~$ ssh -fN -R 12001:localhost:22 [email protected]
Here the port 12001 is an arbitrary port number that is not used by other programs on the Pi.
The “-R 12001:localhost:22” option defines a reverse tunnel. It forwards traffic on port 12001 of the Pi to port 22 of the cave server.
With “-fN” option, SSH will go into the background once successfully authenticated with an SSH server. This option is useful since we do not want to execute any commands on a remote SSH server. We just want to forward ports.
After running the above command, you will be right back to the command prompt of the cave server.
Now, log into the Pi and verify that 127.0.0.1:12001 is bound to sshd. If so, that means a reverse tunnel is set up correctly.
pi~$ sudo netstat -nap | grep 12001
tcp 0 0 127.0.0.1:12001 0.0.0.0:* LISTEN 8493/sshd
Now from any other computer (e.g., the laptop), log in to the Pi. Then access the cave server as follows:
pi~$ ssh -p 12001 CaveUser@localhost
One thing to take note is that the SSH login/password you type for localhost should be for the cave server, not the Pi, since you are logging into the cave server via the tunnel’s local endpoint. After successful login, you will be on cave server.
While the above method allows you to reach the cave server behind T-Mobile’s NAT, you need to log in twice: first to the Pi and then to the cave server. This is because the end point of an SSH tunnel on the Pi is binding to loopback address (127.0.0.1).
But in fact, there is a way to reach the cave server directly with a single login to the Pi. For this, you will need to let sshd on the Pi forward a port not only from loopback address, but also from an external host. This is achieved by specifying GatewayPorts option in sshd running on the Pi.
Open /etc/ssh/sshd_conf of the Pi and add the following line:
pi~$ vi /etc/ssh/sshd_conf
GatewayPorts clientspecified
Restart sshd.
pi~$ sudo /etc/init.d/ssh restart
Now let’s initiate a reverse SSH tunnel from the cave server as follows:
caveserver~$ ssh -fN -R 173.173.63.132:12001:localhost:22 [email protected]
Log into the Pi and confirm with netstat command that a reverse SSH tunnel is established successfully.
Pi~$ sudo netstat -nap | grep 12001
tcp 0 0 173.173.63.132:12001 0.0.0.0:* LISTEN 1538/sshd: dev
Unlike a previous case, the end point of the tunnel is now at 173.173.63.132:12001 (the Pi’s public IP address), not 127.0.0.1:12001. This means that the end point of the tunnel is reachable from an external host.
Now from any other computer (e.g., the laptop), type the following command to gain access to NATed cave server.
clientcomputer~$ ssh -p 12001 [email protected]
Now, after proving that this concept works, I made the tunnel “persistent.” This means that the tunnel is active all of the time and can reestablish itself in the case of temporary network congestion, SSH timeout, the Pi rebooting, etc..
For a persistent tunnel, I used a tool called autossh. As the name implies, this program automatically restarts an SSH session should it breaks for any reason.
As the first step, I set up the ability for the caveserver to log into the Pi without a password. That way, autossh can restart a broken reverse SSH tunnel without user involvement.
Next, install autossh on the caveserver..
From caveserver, run autossh with the following arguments to create a persistent SSH tunnel destined to the Pi.173.173.63.132
caveserver~$ autossh -M 12002 -fN -o "PubkeyAuthentication=yes" -o "StrictHostKeyChecking=false" -o "PasswordAuthentication=no" -o "ServerAliveInterval 60" -o "ServerAliveCountMax 3" -R 173.173.63.132:12001:localhost:22 [email protected]
The “-M 12001” option specifies a monitoring port on Pi which will be used to exchange test data to monitor an SSH session. This port should not be used by any program on Pi.
The “-fN” option is passed to ssh command, which will let the SSH tunnel run in the background.
The “-o XXXX” options tell ssh to:
The rest of reverse SSH tunneling related options remain the same as before.
To establish an SSH tunnel automatically up upon boot, I added the above autossh command to the /etc/rc.local on the caveserver.
Here is an informative PowerPoint (in PDF format) about engineered foundations from Jeff Hill at the Department of Public Works in Texarkana, Arkansas.
On February 19, 2019, I went to a Rice Alumni event at the Federal Reserve Bank in Dallas. The Dallas Fed is one of twelve Federal Reserve Banks in the United States. The CEO’s of the Fed banks meet every six weeks or so to set national monetary policy.
Robert Kaplan, the CEO of the Dallas Fed was speaking about the state of the economy. Peter Rodriguez, the Dean of the Jones School of Business at Rice University, was asking Dr. Kaplan questions. Late in the presentation, Rice Alumni and their guests asked questions.
Here are some key points that I took away:
Short Commentary
During the question and answer session from Rice Alumni and their guests, one gentleman told Dr. Kaplan that there is either no correlation, or negative correlation, between spending on education and educational achievement levels. If you think about it, such an assertion is absurd because, if true, the best thing for society (including individuals) would be to spend absolutely nothing on literacy. Obviously, Dr. Kaplan disagreed.
After the presentation, I spoke with Dr. Rodriguez, the Jones Business School Dean. I told Dr. Rodriguez that I was surprised by this question and was also surprised that Robert Kaplan did not point out that much of the spending labeled as “education” spending really goes for athletic programs which do not increase literacy. Dr. Rodriguez agreed and mentioned the huge high school stadium in Allen as a great example.
I told Dr. Rodriguez that I would like to understand the research about the relative effect of employment growth and productivity on GDP. For example, immigration increases the number of workers in the workforce. But, immigrants come with various educational levels depending on their circumstances. So, more immigrants cause GDP to grow. And highly educated immigrants increase productively and that causes GDP to grow too. But, illiterate immigrants have the opposite effect on productivity – at least initially. That means that the positive effects of increased workers are dampened if those workers have lower than average productivity. Unfortunately, Dr. Rodriguez seemed to take this as a political question and brushed it aside. It was not meant to be. I am sure that the Fed has data on this question. I would love to see it.
OpenWRT is an open source router firmware that can be installed on most consumer WiFi routers for increased security, functionality, and performance.
One way to configure OpenWRT is through a web interface. The other, more powerful, way to configure it is through SSH. OpenWRT comes with dropbear for SSH. Dropbear is a optimized, reduced functionality, SSH server. So, the typical methodology of creating public/private key pairs for authentication does not always work. Here is what I have found to work:
The first command creates a 2048 RSA key, which is the strength recommended by NIST for RSA. To login without a password, just choose the defaults by pressing enter at each prompt. The second command copies the public key to the OpenWRT router. Now, log in to the OpenWRT router with SSH:
You will be prompted for a password. Use the password that you set up for the OpenWRT web interface.
Once logged into the router, execute the following command:
cp /root/.ssh/authorized_keys /etc/dropbear/authorized_keys
This will copy the public key to the location expected by dropbear. This has to be done because ssh-keygen puts the key in the directory expected by openssh, not dropbear.
Now, exit from the router:
exit
Back that the Cygwin or Linux terminal, try logging into the OpenWRT router again with SSH:
This time, you should be able to get in without a password.
Finally, use the OpenWRT GUI (under System->Administration) to turn off SSH password authentication and disallow the root user to login with a password. Test to verify password authentication is turned off by typing the following in Cygwin or a Linux terminal:
ssh -o PreferredAuthentications=password -o PubkeyAuthentication=no [email protected]
You should get an error that says [email protected]: Permission denied (publickey).
Two things to note:
To access your Raspberry Pi through remote desktop, type the following commands at the Raspberry Pi terminal prompt:
sudo apt-get install tightvncserver
When installation of tightvncserver is complete, execute this command:
sudo apt-get install xrdp
When this is complete, the Pi should be running a remote desktop server. To access the Pi on Windows, choose “Remote Desktop Connection” from the start menu. The remote desktop client will appear and ask you for the IP address of the Pi. My Pi is at 10.0.0.129.
Hit Connect.
A login screen will appear and ask for your username and password. The default username for the Pi is “pi” — and the default password is “raspberry”
Congratulations! The Raspberry Pi’s desktop should appear. Now, you can access the Pi from anywhere on your network and there is no need to lug around a monitor, keyboard, mouse, cables, etc.
The terms Cost of Goods Sold (COGS), Cost of Sales, and Cost of Revenue are synonymous. They describe the direct costs of producing a good or service that is sold to customers. In this post, let’s just refer to this as COGS.
Direct costs include direct labor and materials, and facility or plant overhead that is directly tied to producing the good or service. For example, the salary of a person assembling a television would be a direct cost. Extra electricity used to run a machine used only to produce the good or service would also be included.
But, the salary of the janitor at a plant that makes televisions, phones, and alarm clocks would be an indirect cost. The reason is that the cost of the janitor does not increase or decrease as a result of making more or less televisions. The amount of floor space to sweep in the facility is the same regardless of the number of televisions produced (within reason.) The janitor’s salary is an example of SG&A costs. SG&A stands for selling, general, and administrative. SG&A expenses occur when the company incurs an expense for
These types of costs will appear on the company’s quarterly (or annual) income statement for the period they were incurred. More specific examples of indirect SG&A costs include sales commissions, advertising and promotional materials, management compensation, compensation for support staff, rent, utilities, and office supplies.
The general rule is that direct costs do not include general overhead or administrative expenses. These expenses are not part of the COGS calculation.
COGS is key metric for cost analysis because shows the operational costs of producing a good and service. If cost of sales is rising while gross revenue is flat, net earnings (gross profit) will decrease. Remember that:
(Gross Revenue) – (COGS) = (Gross Profit)
Note that for a service business without a tangible, physical, product, COGS is a bit of a misnomer since there is not a “good.” That is why the term Cost of Sales is often used. But, the terms mean the same thing.
This is a good link to describe DFARS 252.204-7012, which is the set of security requirements that all DoD contracts must follow: