SSH – Can It Be More Secure?
Posted: 17 March 2013 Filed under: Linux, Security, Slackware | Tags: remote login, RSA key pairs, security, Slackware Documentation Project, ssh 4 CommentsYes, actually. There are ways to harden your ssh implementations that aren’t that difficult.
An example of a simple way to increase your security when using ssh is to utilize the public/private key security rather than using your remote system’s user passwords to access the device. By using RSA key pairs, you can initialize your remote connection without ever having to expose your remote login’s password to the transfer at all.
I recently reinstalled my Slackware on my main machine (It’s a long story for another time, maybe). One of the things I needed to do was to reestablish my ssh connections between the machines on my local network. I settled in this evening to do just that. I ended up having some laughable issues while attempting to get all my machines talking again. We won’t go there, though.
In the process of troubleshooting my issues with ssh, I ran across Noryungi‘s excellent how-to at the Slackware Documentation Project. This place is really shaping up, no thanks to me. I haven’t been too active there because of my other pursuits lately. However, the dedicated folks who contribute there on a regular basis are kicking ass!
Anyway, using this tutorial, I easily set all three of my machines to use RSA public/private key exchange to initiate my ssh connections. I don’t have to sling my user’s passwords around the Ether anymore. Now anyone sniffing packets will only see the public RSA key bouncing around.
Ain’t technology wonderful? 🙂
Well, back to studying tomorrow. My Cisco ICND2/CCNA examination is rapidly approaching. Gotta’ go study up on those pesky routing protocols before bedtime.
Later,
~Eric
SSH in Slackware and Arch – a Brief How-To
Posted: 19 March 2012 Filed under: How-tos, Linux | Tags: Arch, computer networking, file transfer, gFTP, openssh, security, Slackware, ssh, ssh protocol 2, ssh-agent, static IP 7 CommentsLet me state right out in the open here that my knowledge of computer networking is lacking. I’m learning as I go.
For most of the time that I’ve used computers in my home, I’ve only had one machine going at any given time. This past year or so, though, I’ve gained two more systems in addition to my main system. I have a laptop and a shop system up and running now in my home. The laptop connects via Ethernet or wireless. The shop system, which is outside in my workshop connects via wireless 100% of the time.
The main OS on all three of these systems is Slackware. For a year now, I’ve been running back and forth with thumb drives or CDs filled with data to keep the systems in sync with one another; mostly my personal documents, music, and Mozilla settings. I occasionally use DropBox for small files, but it’s not feasible for larger stuff due to its slow upload speeds. Cloud computing ain’t never going to work as long as ISPs throttle upload speeds.
Anyway, back when I first got the laptop, I attempted to network it with my main system. I failed miserably and ended up throwing in the towel. You can read about that learning experience in this long thread at Scot’s Newsletter Forums – Bruno’s All Things Linux. You’ll see that quite a few folks there were trying to help the dunderhead get his systems linked. Well, I finally succeeded just this past weekend.
Sometimes, you just have to walk away from a problem for a while. 😉
Here’s how I finally got it working using ssh:
- Make sure that the ssh daemon script is executable so that it will run at boot up
#chmod 755 /etc/rc.d/rc.sshd
- Modify the /etc/ssh/ssh_config as follows:
#vim /etc/ssh/ssh_config
<snip>
#Â Â Port 22
Port <your port choice>
#Â Â Protocol 2,1
Protocol 2
</snip>
*Either un-comment and change the default port setting and the protocol or just add a line, as I did.
The purpose of this is mostly for security. Changing the port to a port of your choosing enhances your “security by obscurity” chances. Changing to to Protocol 2 is recommended because there are security flaws in Protocol 1.
- Modify the /etc/ssh/sshd_config as follows:
#vim /etc/ssh/sshd_config
<snip>
#Port 22
 Port <your port choice>
#AddressFamily any
#ListenAddress 0.0.0.0
#ListenAddress ::
# The default requires explicit activation of protocol 1
 Protocol 2
</snip>
- In your router’s Administration preferences (see your manufacturer’s instructions) you’ll need to set each device you plan on linking via ssh to use a static IP address. This has nothing to do with your ISP’s assigned IP address. This is just your home network we’re talking about here. The router assigns an IP to each device hooked to it. In order to ssh into remote devices, you’ll need to make sure the devices’ IP addresses don’t change (static).
That’s it. You are ssh’ing now, my friends.
It’s easy to access your remote machines now.
$ssh <username>@<device name>
Password: *********
The username is the name of the account that your are trying to access on the remote machine, say your wife Debbie’s account. The device name is the domain name of the device. Like this…
#ssh debbie@debbieslaptop01
Once you enter the password for Debbie’s account, you’ll have access to her user data and privileges.
In Arch Linux, the process is a bit simpler. First, make sure you have openssh installed on your Arch system. You still need to modify the ssh_config and sshd_config files in a similar fashion, but the getting the daemon to run at boot time is as simple as just adding “ssh” to your /etc/rc.conf file.
You can manipulate (edit, backup, copy, etc.) files on remote machines using ssh from the command line. However, to transfer files between machines, you might want to use ftp. It’s easier, in my opinion. Personally, I use gFTP in Slackware and Arch for this. There are many other choices out there, though. Use whatever works best for you.
So, there you have it. My next project is going to be adding my printer to my router’s USB connection and setting it up as a network printer for all three of my systems.
Stay tuned…
~Eric
Further reading: