Poderosa – A Viable PuTTY Replacement

I’m a long-time PuTTY user, but one of the annoyances is that it does not save passwords. I understand the reasoning behind why, but the creators of PuTTY took the stance of never going to add that as a feature. I found a decent replacement that does have password saving capabilities, and that is Poderosa. Poderosa is an open-source, free SSH tool with tabs, split window panes, and yes, password saving capabilities. It’s written in C# and built on the .NET 2.0 platform. A lot of people don’t like that fact, but .NET is so standard on Windows nowadays that it’s really no big deal.

I searched for quite awhile for how to have the passwords saved. Nothing I tried worked, so having the source code was useful. I ran the system through my Visual Studio debugger and found out exactly how the passwords are read in from the XML-based shortcut file. There is a configuration setting inside Poderosa that is turned off by default. Click on the “Tools” menu, then “Detailed preferences editor…”. Find the setting named “org.poderosa.protocols.ReadSerializedPasswords” and change it to “true”. Then, in the shortcut file (these have the extension “.gts”) in the second element, next to the “account” attribute, create a new attribute named “passphrase” and add your password there. Here’s what it might look like.

<?xml version="1.0" encoding="Windows-1252"?>
<poderosa-shortcut version="4.0">
  <Poderosa.Terminal.TerminalSettings encoding="iso-8859-1" caption="Remove Server Name Goes Here" />
  <Poderosa.Protocols.SSHLoginParameter destination="127.0.0.1" account="joe" passphrase="myTotallyUnsecurePassword" />
</poderosa-shortcut>

Obviously, you would have the destination equal the IP address of the remote server.

Now, before you go all nuts about clear text passwords, let me just say that I agree with you 100% that passwords in clear text are a bad, bad, bad idea. Since I have the source code, I will be working on a way to have passwords saved in a different, more secured fashion, but for the moment, this meets my needs. Perhaps it will meet your needs, too.

Autogrow stopped working again

Back in December, we had a client who ran a defrag while SQL Server was running. This caused the main database to run out of filegroups space in the ‘PRIMARY’ filegroup. Well, it happened again this week. This time, though, a defrag was not the culprit. We’re still trying to determine what causes this from time to time. Here’s the error in the event log:

MODIFY FILE encountered operating system error 1450(Insufficient system resources exist to complete the requested service.) while attempting to expand the physical file

The solution? Stop all SQL services. Make a physical copy of the database’s MDF file. Change the name of the original MDF file to something else. Rename the copied MDF file to the same name as the original MDF file. Restart SQL services.

Original research showed that this was probably a highly fragmented data file that caused this error, but I don’t know if that’s the case here. Making a copy definitely wrote the physical bits to another area of the disk. For this to happen twice in a three month period is highly suspicious. I’m thinking there’s a drive issue, but system checks didn’t show anything. The investigation continues . . .