Mowser
Preface regarding comments and questions: Mikelococo.com is not a general linux support forum, please visit someplace like fedoraforum.org for generic linux questions. Comments that do not advance the community dialog regarding how to configure F8 on the D620 for optimal hardware support will be deleted in the moderation process.
Fedora 8 works quite well on the D620 right out of the box, and with a few tweaks can be just about fully supported. This guide summarizes what I’ve done to get things working to my satisfaction. It is not a step by step howto, but does attempt to link to more detailed resources when they are available. The table below shows at a glance what is and isn’t working well on my system. Green items worked immediately after install without manual intervention, yellow items were made fully functional after some manual configuration, red items have significant unsolved issues associated with them.
It’s not always possible to ssh to a host directly. Many networks require high-value systems to be accessed via an intermediate bastion/proxy host that receives extra attention in terms of security controls and log monitoring. The added security provided by this connection bouncing comes with a cost in convenience, though. It requires multiple logins to access the protected systems and substantially complicates scp/stfp file transfers.
Fortunately, there are a number of ways to automate connection bouncing and make it as convenient as direct connection. There are already a number of web-sites detailing the approaches to this issue, and I won’t repeat their contents, to get a broad overview of the topic read the following:
Connection “chaining” refers to any approach that involves sshing to an intermediate host, and then sshing from the intermediate host to the next host (for example: ssh 1 ’ssh 2 “ssh 3″‘). This solution is attractive for setups with many hops because it’s easy to extend, for example sshto makes this very easy. The primary disadvantage is that end-to-end encryption is lost. The connection is decrypted by every host in the chain, and an attacker with sufficient privilege on an intermediate system can sniff the connection without compromising either of the endpoints. I consider this to be a significant failing, and have a strong preference for “stacked” connections wherever they are logistically feasible.
Connection “stacking” refers to any solution that involves tunneling ssh connections inside each other. “Nesting” strikes me as a better term, but stacking seems to be more widely agreed upon. It is typically implemented with proxy-commands or with ssh port-forwarding. It can be more difficult to manage for connections with many hops, and it forces one of the endpoints to bear the encryption load of all the connections (in chained setups, the load is spread evenly among all the hosts in the chain). It does maintain end-to-end encryption, preventing connection/credential sniffing by intermediate hosts.
The key properties for my setup are:
The WinSCP Config is quite simple and utilizes its “tunnel” feature. Open WinSCP and configure a saved session for the final destination host as follows:
When you log in using the new profile, you will be prompted for two passwords. The first is for your account on the intermediate host, and the second is for your account on the final-destination host. After login, the bounce is entirely transparent and WinSCP works as if you had connected directly to the final-destination host. The connection process can be made even more transparent and secure by using public key authentication with Pageant instead of passwords.
The Putty setup is slightly more complicated and requires that public key authentication be used on the intermediate host. It utilizes Putty’s “local proxy” feature, which allows you to specify an arbitrary command on the local machine to act as a proxy. Instead of creating a TCP connection, PuTTY will communicate using the proxy program’s standard input and output streams. Our local proxy will be plink, which is a command-line ssh connection program included in the Putty default installation. Plink’s -nc option provides functionality similar to the ProxyCommand/netcat approach, but does so using the ssh server’s native port-forwarding interface and does not require that netcat be installed on the intermediate system. To set things up, configure a saved session for the final destination host:
If all is working properly, when you log in using the new profile plink will handle the login to the intermediate system silently. Putty isn’t smart enough to prompt if the proxy command requires user input, so you’ll get a connection error if public key authentication on the intermediate host isn’t working. If you use password authentication on the final destination host you’ll be prompted for your password, or if you use pubkey authentication there as well you’ll land at a prompt with no fuss at all.
If you have trouble, make sure plink is executing properly. You may need to enter the full pathname, usually c:\program files\putty\plink.exe. You can also try executing the plink command from a prompt, remembering to substitute the %host and %port values of your final destination host. If it’s working properly, you’ll be logged into the intermediate system with your pagean-cached private key, and instead of a prompt you’ll be presented with the SSH banner for your final destination system.
There are a number of excellent guides to setting up public key authentication for ssh, but they tend to stop short of describing how to integrate presence events like a screensaver turning on. It’s a topic that isn’t possible to cover in a generic way, since it depends heavily on your operating system, distribution, desktop environment, and preferred shell. I present here the information I’ve pulled together to get things running under Linux, specifically Fedora 8 with Gnome and Bash.
First off, if you’re not already quite familiar public key authentication, go read the three part IBM developerWorks series on the topic (1, 2, 3), which is the best primer I’ve found. I’m using public key authentication with encrypted keys, am caching my credentials with ssh-agent, and am using keychain as my interface to ssh-agent. My primary goal was to automatically run keychain –clear to clear my credentials any time I left my system unattended. I also outline how to run keychain ~/.ssh/id_rsa when you return to your system (or whenever you open a shell) in order to reload your ssh key.
When I log in to my system, keychain runs and does some housekeeping. It starts an ssh-agent process if one isn’t already running and prompts for the passwords to my ssh keys if they aren’t already loaded, or if all that has already been done it just reports its status and exits. The following lines can be placed in ~/.bash_profile which is executed when you log into your system (via remote ssh session, text console, and oddly enough gnome executes bash_profile on login as well).
if [ "$PS1" ]; then /usr/bin/keychain ~/.ssh/id_rsa source ~/.keychain/yourhostname-sh fi
The “if” statement ensures that keychain is only run for interactive shells. Because keychain generates output on execution it can confuse some programs that run non-interactively, notably sftp breaks if you don’t do this.
I actually like keychain to run every time I start a new shell, not just when I first log in. This means that I can clear my credentials manually if I won’t be using ssh for a while and when I open a fresh terminal window (or “window” in a screen session, or whatever) keychain automatically prompts me for my password. This can be done by placing the same lines from above in ~/.bashrc instead of bash_profile (bashrc is executed from bash_profile, so you only need one or the other).
When my screensaver turns on, it’s an indication that I’m away from my desk and that my credentials should be cleared. To my knowledge, gnome-screensaver does not provide per-user screensaver-on and screensaver-off scripts where you can easily add these sorts of things (it should, if you ask me). It does, however, emit a DBUS signal that you can listen for and act on. I found some folks using python scripts to handle similar needs and adapted them for my purpose, others have done similar things with bash script. Once you’ve customized your DBUS signal listener script, add it to your default gnome session using System –> Preferences –> Personal –> Sessions so that it’s automatically started when you log in.
#!/usr/bin/python
import dbus
from dbus.mainloop.glib import DBusGMainLoop
import gobject
import os
def clear_keychain(state):
"""Called when screensaver on/off events occur"""
# clear ssh keys when screensaver turns on
if state == True:
os.system('/usr/bin/keychain --clear')
# Load ssh keys when screensaver turns off
# if state == False:
# os.system('/usr/bin/keychain id_rsa')
# Connect to the gnome session bus:
dbus.mainloop.glib.DBusGMainLoop(set_as_default=True)
bus = dbus.SessionBus()
# Listen for SessionIdleChanged signals
bus.add_signal_receiver(clear_keychain,'SessionIdleChanged','org.gnome.ScreenSaver')
loop = gobject.MainLoop()
loop.run()
Logging out of the system (whether from a remote ssh session, a local text console, or a graphical gnome session) is an indication that my workstation is going to be idle for a while and that my credentials should be cleared. This can be (mostly) accomplished by making an addition to ~/.bash_logout. This file is run any time a non-gnome login shell exits, like a remote ssh session or a local text console session (but not terminal windows in gnome, screen windows, or other non-login shells):
/usr/bin/keychain --clear
For some utterly insane reason, gnome doesn’t execute bash_logout even though it does execute bash_profile on login, and it doesn’t provide a sane alternative. The only method I’m aware of for running a script on gnome-logout involves xsession hackery, but I’ve punted on this issue since I rarely exit my gnome session. If you find an elegant solution, leave a comment.
With the tips in the developerWorks series, and the information in this article, you can have an incredibly convenient ssh key management setup while you’re using your computer and know that your credentials will be automatically cleared when you’re away from your system.
Making good on the heels of my CISSP certification, I’m going to be joining the Security Services group at NYU in May as a Senior Network Security Analyst. Security Services is charged to protect the entire NYU network, which provides connectivity to around 40,000 nodes.
I’m incredibly excited about the move. Since my partner lives in New York, I’ve been job hunting there for almost a year and half and I’ve found that it’s a very competitive market. I needed to do a lot of professional development in order to be considered seriously for the positions I wanted, and this was the most interesting position I saw or applied for in my entire search. To have been hired into it just fantastic.
So anyhoo… I’ll be selling or giving away most of my stuff this month so Laura, Kip, and I can fit into an apartment the size of a shoebox. Have a gander if you need anything.
Dawid Lorenz, myself, and a number of other folks (read the comments on Dawid’s page, and also on the product pages for the D620 batteries) have all experienced poor battery life on Dell Latitude D620’s that are typically less than six months old. There may or may not be a high failure rate for this battery model, and this page details my experiences in diagnosing the health of my battery and obtaining a replacement under warranty.
There are several methods of determining your battery’s capacity relative to it’s initial specification (aka “health”).
Of course, you always have the option of purchasing a replacement battery from Dell (9-cell or 6-cell), or simply living with degraded battery life. There are some circumstances where you may be able to obtain a replacement under warranty, though. If the BIOS/Quickset health gauges are showing the battery as failed even though it’s less than a year old, Dell will replace it under warranty. According to the phone rep that I spoke to, a battery is considered to have failed when operating at less than 50% of its rated capacity. When I called, my battery was five months old and operating at 50%-60% of it’s capacity (5 death lights, BIOS noted lowered battery life but did not pronounce failure, FC6 power manager rated health at 56%, observed battery life was 50%-60% of expected). I was able to successfully make the case that the battery was clearly borderline and would certainly be replaced within a month or two, and that doing so now was an opportunity to provide excellent customer service whereas forcing me to wait would serve no purpose other than irritating me. To his credit, the phone rep immediately acknowledged that my line of thinking was reasonable, spoke to a supervisor, and was able to authorize the early replacement.
I love my laptop, and in general I’m very happy with it. It does look like there’s a trend toward premature battery failure, though, and if your situation is severe enough you may be eligible for a warranty replacement. Once you’re replacement arrives, go read about how to monitor and optimize battery performance.
You are viewing a mobilized version of this site...
View original page here
Mowser