A.2.5 Does PuTTY support storing settings, so I don't have to change them every time?
Yes, all of PuTTY's settings can be saved in named session profiles. You can also change the default settings that are used for new sessions. See
section 4.1.2
in the documentation for how to do this.
A.2.6 Does PuTTY support storing its settings in a disk file?
Not at present, although
section 4.28
in the documentation gives a method of achieving the same effect.
A.2.7 Does PuTTY support full-screen mode, like a DOS box?
Yes; this is a new feature in version 0.52.
A.2.8 Does PuTTY have the ability to remember my password so I don't have to type it every time?
No, it doesn't.
Remembering your password is a bad plan for obvious security reasons: anyone who gains access to your machine while you're away from your desk can find out the remembered password, and use it, abuse it or change it.
In addition, it's not even possible for PuTTY to automatically send your password in a Telnet session, because Telnet doesn't give the client software any indication of which part of the login process is the password prompt. PuTTY would have to guess, by looking for words like ‘password’ in the session data; and if your login program is written in something other than English, this won't work.
In SSH, remembering your password would be possible in theory, but there doesn't seem to be much point since SSH supports public key authentication, which is more flexible and more secure. See
chapter 8
in the documentation for a full discussion of public
key authentication.
A.2.9 Is there an option to turn off the annoying host key prompts?
No, there isn't. And there won't be. Even if you write it yourself and send us the patch, we won't accept it.
Those annoying host key prompts are the whole point of SSH. Without them, all the cryptographic technology SSH uses to secure your session is doing nothing more than making an attacker's job slightly harder; instead of sitting between you and the server with a packet sniffer, the attacker must actually subvert a router and start modifying the packets going back and forth. But that's not all that much harder than just sniffing; and without host key checking, it will go completely undetected by client or server.
Host key checking is your guarantee that the encryption you put on your data at the client end is the same encryption taken off the data at the server end; it's your guarantee that it hasn't been removed and replaced somewhere on the way. Host key checking makes the attacker's job astronomically hard, compared to packet sniffing, and even compared to subverting a router. Instead of applying a little intelligence and keeping an eye on Bugtraq, the attacker must now perform a brute-force attack against at least one military-strength cipher. That insignificant host key prompt really does make that much difference.
If you're having a specific problem with host key checking - perhaps you want an automated batch job to make use of PSCP or Plink, and the interactive host key prompt is hanging the batch process - then the right way to fix it is to add the correct host key to the Registry in advance, or if the Registry is not available, to use the -hostkey command-line option. That way, you retain the important feature of host key checking: the right key will be accepted and the wrong ones will not. Adding an option to turn host key checking off completely is the wrong solution and we will not do it.
If you have host keys available in the common known_hosts format, we have a script called
kh2reg.py
to convert them to a
Windows .REG file, which can be installed ahead of time by double-clicking or using REGEDIT.
A.2.10 Will you write an SSH server for the PuTTY suite, to go with the client?
No. The only reason we might want to would be if we could easily re-use existing code and significantly cut down the effort. We don't believe this is the case; there just isn't enough common ground between an SSH client and server to make it worthwhile.