PuTTY

 

 

Download : Click Here

 

PuTTY  is a free and open-source terminal emulator, serial console and network file transfer application. It supports several network protocols, including SCP, SSH, Telnet, rlogin, and raw socket connection. It can also connect to a serial port. The name “PuTTY” has no definitive meaning.^[4]

PuTTY was originally written for Microsoft Windows, but it has been ported to various other operating systems. Official ports are available for some Unix-like platforms, with work-in-progress ports to Classic Mac OS and Mac OS X, and unofficial ports have been contributed to platforms such as Symbian,^[5][6] Windows Mobile and Windows Phone.

PuTTY was written and is maintained primarily by Simon Tatham and is currently beta software.

Features[edit]

PuTTY supports many variations on the secure remote terminal, and provides user control over the SSH encryption key and protocol version, alternate ciphers such as 3DES, Arcfour, Blowfish, DES, and Public-key authentication. It also can emulate control sequences from xterm, VT102 or ECMA-48 terminal emulation, and allows local, remote, or dynamic port forwardingwith SSH (including X11 forwarding). The network communication layer supports IPv6, and the SSH protocol supports the [email protected] delayed compression scheme. It can also be used with local serial port connections.

PuTTY comes bundled with command-line SCP and SFTP clients, called “pscp” and “psftp” respectively.

History[edit]

PuTTY’s development dates back to late 1998,^[1] and it has been a usable SSH-2 client since October 2000.^[7][8]

Components[edit]

PuTTY consists of several components:

• PuTTY: the Telnet, rlogin, and SSH client itself, which can also connect to a serial port
• PSCP: an SCP client, i.e. command-line secure file copy
• PSFTP: an SFTP client, i.e. general file transfer sessions much like FTP
• PuTTYtel: a Telnet-only client
• Plink: a command-line interface to the PuTTY back ends
• Pageant: an SSH authentication agent for PuTTY, PSCP and Plink
• PuTTYgen: an RSA and DSA key generation utility
• pterm: a standalone terminal emulator

Reception[edit]

Justin James of TechRepublic cited its reliability, cost, cross platform support, and features as positives. He faulted complex configuration, extended beta testing, and lack of support for scripting.^[9] J. Peter Bruzzese of InfoWorld included it in his list of 15 Essential Open Source Tools for Windows Admins and wrote that its imitators are not as good.

This FAQ is published on the PuTTY web site, and also provided as an appendix in the manual.

A.1 Introduction

A.1.1 What is PuTTY?

PuTTY is a client program for the SSH, Telnet and Rlogin network protocols.

These protocols are all used to run a remote session on a computer, over a network. PuTTY implements the client end of that session: the end at which the session is displayed, rather than the end at which it runs.

In really simple terms: you run PuTTY on a Windows machine, and tell it to connect to (for example) a Unix machine. PuTTY opens a window. Then, anything you type into that window is sent straight to the Unix machine, and everything the Unix machine sends back is displayed in the window. So you can work on the Unix machine as if you were sitting at its console, while actually sitting somewhere else.

A.2 Features supported in PuTTY

In general, if you want to know if PuTTY supports a particular feature, you should look for it on the PuTTY web site. In particular:

• try the changes page, and see if you can find the feature on there. If a feature is listed there, it’s been implemented. If it’s listed as a change made since the latest version, it should be available in the development snapshots, in which case testing will be very welcome.
• try the Wishlist page, and see if you can find the feature there. If it’s on there, and not in the ‘Recently fixed’ section, it probably hasn’t been implemented.

A.2.1 Does PuTTY support SSH-2?

Yes. SSH-2 support has been available in PuTTY since version 0.50.

Public key authentication (both RSA and DSA) in SSH-2 is new in version 0.52.

A.2.2 Does PuTTY support reading OpenSSH or ssh.com SSH-2 private key files?

PuTTY doesn’t support this natively (see the wishlist entry for reasons why not), but as of 0.53 PuTTYgen can convert both OpenSSH and ssh.com private key files into PuTTY’s format.

A.2.3 Does PuTTY support SSH-1?

Yes. SSH-1 support has always been available in PuTTY.

However, the SSH-1 protocol has many weaknesses and is no longer considered secure; you should use SSH-2 instead if at all possible.

A.2.4 Does PuTTY support local echo?

Yes. Version 0.52 has proper support for local echo.

In version 0.51 and before, local echo could not be separated from local line editing (where you type a line of text locally, and it is not sent to the server until you press Return, so you have the chance to edit it and correct mistakes before the server sees it). New in version 0.52, local echo and local line editing are separate options, and by default PuTTY will try to determine automatically whether to enable them or not, based on which protocol you have selected and also based on hints from the server. If you have a problem with PuTTY’s default choice, you can force each option to be enabled or disabled as you choose. The controls are in the Terminal panel, in the section marked ‘Line discipline options’.

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.29 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 8in 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.

If someone else wants to use bits of PuTTY in the process of writing a Windows SSH server, they’d be perfectly welcome to of course, but I really can’t see it being a lot less effort for us to do that than it would be for us to write a server from the ground up. We don’t have time, and we don’t have motivation. The code is available if anyone else wants to try it.

A.2.11 Can PSCP or PSFTP transfer files in ASCII mode?

Unfortunately not.

Until recently, this was a limitation of the file transfer protocols: the SCP and SFTP protocols had no notion of transferring a file in anything other than binary mode. (This is still true of SCP.)

The current draft protocol spec of SFTP proposes a means of implementing ASCII transfer. At some point PSCP/PSFTP may implement this proposal.

A.3 Ports to other operating systems

The eventual goal is for PuTTY to be a multi-platform program, able to run on at least Windows, Mac OS and Unix.

Porting will become easier once PuTTY has a generalised porting layer, drawing a clear line between platform-dependent and platform-independent code. The general intention was for this porting layer to evolve naturally as part of the process of doing the first port; a Unix port has now been released and the plan seems to be working so far.

A.3.1 What ports of PuTTY exist?

Currently, release versions of PuTTY tools only run on full Win32 systems and Unix. ‘Win32’ includes versions of Windows from Windows 95 onwards (as opposed to the 16-bit Windows 3.1; see question A.3.5), up to and including Windows 7; and we know of no reason why PuTTY should not continue to work on future versions of Windows.

The Windows executables we provide are for the 32-bit ‘x86’ processor architecture, but they should work fine on 64-bit processors that are backward-compatible with that architecture. (We used to also provide executables for Windows for the Alpha processor, but stopped after 0.58 due to lack of interest.)

In the development code, a partial port to Mac OS exists (see question A.3.6).

Currently PuTTY does not run on Windows CE (see question A.3.4).

We do not have release-quality ports for any other systems at the present time. If anyone told you we had an Android port, or an iOS port, or any other port of PuTTY, they were mistaken. We don’t.

There are some third-party ports to various platforms, mentioned on the Links page of our website.

A.3.2 Is there a port to Unix?

As of 0.54, there are Unix ports of most of the traditional PuTTY tools, and also one entirely new application.

If you look at the source release, you should find a unix subdirectory. There are a couple of ways of building it, including the usual configure/make; see the file README in the source distribution. This should build you Unix ports of Plink, PuTTY itself, PuTTYgen, PSCP, PSFTP, and also pterm – an xterm-type program which supports the same terminal emulation as PuTTY. We do not yet have a Unix port of Pageant.

If you don’t have Gtk, you should still be able to build the command-line tools.

A.3.3 What’s the point of the Unix port? Unix has OpenSSH.

All sorts of little things. pterm is directly useful to anyone who prefers PuTTY’s terminal emulation to xterm‘s, which at least some people do. Unix Plink has apparently found a niche among people who find the complexity of OpenSSL makes OpenSSH hard to install (and who don’t mind Plink not having as many features). Some users want to generate a large number of SSH keys on Unix and then copy them all into PuTTY, and the Unix PuTTYgen should allow them to automate that conversion process.

There were development advantages as well; porting PuTTY to Unix was a valuable path-finding effort for other future ports, and also allowed us to use the excellent Linux tool Valgrind to help with debugging, which has already improved PuTTY’s stability on all platforms.

However, if you’re a Unix user and you can see no reason to switch from OpenSSH to PuTTY/Plink, then you’re probably right. We don’t expect our Unix port to be the right thing for everybody.

A.3.4 Will there be a port to Windows CE or PocketPC?

We have done some work on such a port, but it only reached an early stage, and certainly not a useful one. It’s no longer being actively worked on.

However, there’s a third-party port at http://www.pocketputty.net/.

A.3.5 Is there a port to Windows 3.1?

PuTTY is a 32-bit application from the ground up, so it won’t run on Windows 3.1 as a native 16-bit program; and it would be very hard to port it to do so, because of Windows 3.1’s vile memory allocation mechanisms.

However, it is possible in theory to compile the existing PuTTY source in such a way that it will run under Win32s (an extension to Windows 3.1 to let you run 32-bit programs). In order to do this you’ll need the right kind of C compiler – modern versions of Visual C at least have stopped being backwards compatible to Win32s. Also, the last time we tried this it didn’t work very well.

A.3.6 Will there be a port to the Mac?

We hope so!

We attempted one around 2005, written as a native Cocoa application, but it turned out to be very slow to redraw its window for some reason we never got to the bottom of.

In 2015, after porting the GTK front end to work with GTK 3, we began another attempt based on making small changes to the GTK code and building it against the OS X Quartz version of GTK 3. This doesn’t seem to have the window redrawing problem any more, so it’s already got further than the last effort, but it is still substantially unfinished.

If any OS X and/or GTK programming experts are keen to have a finished version of this, we urge them to help out with some of the remaining problems!

A.3.7 Will there be a port to EPOC?

I hope so, but given that ports aren’t really progressing very fast even on systems the developers do already know how to program for, it might be a long time before any of us get round to learning a new system and doing the port for that.

However, some of the work has been done by other people; see the Links page of our website for various third-party ports.

A.3.8 Will there be a port to the iPhone?

We have no plans to write such a port ourselves; none of us has an iPhone, and developing and publishing applications for it looks awkward and expensive.

However, there is a third-party SSH client for the iPhone and iPod Touch called pTerm, which is apparently based on PuTTY. (This is nothing to do with our similarly-named pterm, which is a standalone terminal emulator for Unix systems; see question A.3.2.)

A.4 Embedding PuTTY in other programs

A.4.1 Is the SSH or Telnet code available as a DLL?

No, it isn’t. It would take a reasonable amount of rewriting for this to be possible, and since the PuTTY project itself doesn’t believe in DLLs (they make installation more error-prone) none of us has taken the time to do it.

Most of the code cleanup work would be a good thing to happen in general, so if anyone feels like helping, we wouldn’t say no.

See also the wishlist entry.

A.4.2 Is the SSH or Telnet code available as a Visual Basic component?

No, it isn’t. None of the PuTTY team uses Visual Basic, and none of us has any particular need to make SSH connections from a Visual Basic application. In addition, all the preliminary work to turn it into a DLL would be necessary first; and furthermore, we don’t even know how to write VB components.

If someone offers to do some of this work for us, we might consider it, but unless that happens I can’t see VB integration being anywhere other than the very bottom of our priority list.

A.4.3 How can I use PuTTY to make an SSH connection from within another program?

Probably your best bet is to use Plink, the command-line connection tool. If you can start Plink as a second Windows process, and arrange for your primary process to be able to send data to the Plink process, and receive data from it, through pipes, then you should be able to make SSH connections from your program.

This is what CVS for Windows does, for example.

A.5 Details of PuTTY’s operation

A.5.1 What terminal type does PuTTY use?

For most purposes, PuTTY can be considered to be an xterm terminal.

PuTTY also supports some terminal control sequences not supported by the real xterm: notably the Linux console sequences that reconfigure the colour palette, and the title bar control sequences used byDECterm (which are different from the xterm ones; PuTTY supports both).

By default, PuTTY announces its terminal type to the server as xterm. If you have a problem with this, you can reconfigure it to say something else; vt220 might help if you have trouble.

A.5.2 Where does PuTTY store its data?

On Windows, PuTTY stores most of its data (saved sessions, SSH host keys) in the Registry. The precise location is

HKEY_CURRENT_USER\Software\SimonTatham\PuTTY

and within that area, saved sessions are stored under Sessions while host keys are stored under SshHostKeys.

PuTTY also requires a random number seed file, to improve the unpredictability of randomly chosen data needed as part of the SSH cryptography. This is stored by default in a file called PUTTY.RND; this is stored by default in the ‘Application Data’ directory, or failing that, one of a number of fallback locations. If you want to change the location of the random number seed file, you can put your chosen pathname in the Registry, at

HKEY_CURRENT_USER\Software\SimonTatham\PuTTY\RandSeedFile

You can ask PuTTY to delete all this data; see question A.8.2.

On Unix, PuTTY stores all of this data in a directory ~/.putty.

A.6 HOWTO questions

A.6.1 What login name / password should I use?

This is not a question you should be asking us.

PuTTY is a communications tool, for making connections to other computers. We maintain the tool; we don’t administer any computers that you’re likely to be able to use, in the same way that the people who make web browsers aren’t responsible for most of the content you can view in them. We cannot help with questions of this sort.

If you know the name of the computer you want to connect to, but don’t know what login name or password to use, you should talk to whoever administers that computer. If you don’t know who that is, see the next question for some possible ways to find out.

A.6.2 What commands can I type into my PuTTY terminal window?

Again, this is not a question you should be asking us. You need to read the manuals, or ask the administrator, of the computer you have connected to.

PuTTY does not process the commands you type into it. It’s only a communications tool. It makes a connection to another computer; it passes the commands you type to that other computer; and it passes the other computer’s responses back to you. Therefore, the precise range of commands you can use will not depend on PuTTY, but on what kind of computer you have connected to and what software is running on it. The PuTTY team cannot help you with that.

(Think of PuTTY as being a bit like a telephone. If you phone somebody up and you don’t know what language to speak to make them understand you, it isn’t the telephone company‘s job to find that out for you. We just provide the means for you to get in touch; making yourself understood is somebody else’s problem.)

If you are unsure of where to start looking for the administrator of your server, a good place to start might be to remember how you found out the host name in the PuTTY configuration. If you were given that host name by e-mail, for example, you could try asking the person who sent you that e-mail. If your company’s IT department provided you with ready-made PuTTY saved sessions, then that IT department can probably also tell you something about what commands you can type during those sessions. But the PuTTY maintainer team does not administer any server you are likely to be connecting to, and cannot help you with questions of this type.

A.6.3 How can I make PuTTY start up maximised?

Create a Windows shortcut to start PuTTY from, and set it as ‘Run Maximized’.

A.6.4 How can I create a Windows shortcut to start a particular saved session directly?

To run a PuTTY session saved under the name ‘mysession’, create a Windows shortcut that invokes PuTTY with a command line like

\path\name\to\putty.exe -load "mysession"

(Note: prior to 0.53, the syntax was @session. This is now deprecated and may be removed at some point.)

A.6.5 How can I start an SSH session straight from the command line?

Use the command line putty -ssh host.name. Alternatively, create a saved session that specifies the SSH protocol, and start the saved session as shown in question A.6.4.

A.6.6 How do I copy and paste between PuTTY and other Windows applications?

Copy and paste works similarly to the X Window System. You use the left mouse button to select text in the PuTTY window. The act of selection automatically copies the text to the clipboard: there is no need to press Ctrl-Ins or Ctrl-C or anything else. In fact, pressing Ctrl-C will send a Ctrl-C character to the other end of your connection (just like it does the rest of the time), which may have unpleasant effects. The only thing you need to do, to copy text to the clipboard, is to select it.

To paste the clipboard contents into a PuTTY window, by default you click the right mouse button. If you have a three-button mouse and are used to X applications, you can configure pasting to be done by the middle button instead, but this is not the default because most Windows users don’t have a middle button at all.

You can also paste by pressing Shift-Ins.

A.6.7 How do I use all PuTTY’s features (public keys, proxying, cipher selection, etc.) in PSCP, PSFTP and Plink?

Most major features (e.g., public keys, port forwarding) are available through command line options. See the documentation.

Not all features are accessible from the command line yet, although we’d like to fix this. In the meantime, you can use most of PuTTY’s features if you create a PuTTY saved session, and then use the name of the saved session on the command line in place of a hostname. This works for PSCP, PSFTP and Plink (but don’t expect port forwarding in the file transfer applications!).

A.6.8 How do I use PSCP.EXE? When I double-click it gives me a command prompt window which then closes instantly.

PSCP is a command-line application, not a GUI application. If you run it without arguments, it will simply print a help message and terminate.

To use PSCP properly, run it from a Command Prompt window. See chapter 5 in the documentation for more details.

A.6.9 How do I use PSCP to copy a file whose name has spaces in?

If PSCP is using the traditional SCP protocol, this is confusing. If you’re specifying a file at the local end, you just use one set of quotes as you would normally do:

pscp "local filename with spaces" user@host:
pscp user@host:myfile "local filename with spaces"

But if the filename you’re specifying is on the remote side, you have to use backslashes and two sets of quotes:

pscp user@host:"\"remote filename with spaces\"" local_filename
pscp local_filename user@host:"\"remote filename with spaces\""

Worse still, in a remote-to-local copy you have to specify the local file name explicitly, otherwise PSCP will complain that they don’t match (unless you specified the -unsafe option). The following command will give an error message:

c:\>pscp user@host:"\"oo er\"" .
warning: remote host tried to write to a file called 'oo er'
         when we requested a file called '"oo er"'.

Instead, you need to specify the local file name in full:

c:\>pscp user@host:"\"oo er\"" "oo er"

If PSCP is using the newer SFTP protocol, none of this is a problem, and all filenames with spaces in are specified using a single pair of quotes in the obvious way:

pscp "local file" user@host:
pscp user@host:"remote file" .

A.7 Troubleshooting

A.7.1 Why do I see ‘Incorrect MAC received on packet’?

One possible cause of this that used to be common is a bug in old SSH-2 servers distributed by ssh.com. (This is not the only possible cause; see section 10.12 in the documentation.) Version 2.3.0 and below of their SSH-2 server constructs Message Authentication Codes in the wrong way, and expects the client to construct them in the same wrong way. PuTTY constructs the MACs correctly by default, and hence these old servers will fail to work with it.

If you are using PuTTY version 0.52 or better, this should work automatically: PuTTY should detect the buggy servers from their version number announcement, and automatically start to construct its MACs in the same incorrect manner as they do, so it will be able to work with them.

If you are using PuTTY version 0.51 or below, you can enable the workaround by going to the SSH panel and ticking the box labelled ‘Imitate SSH2 MAC bug’. It’s possible that you might have to do this with 0.52 as well, if a buggy server exists that PuTTY doesn’t know about.

In this context MAC stands for Message Authentication Code. It’s a cryptographic term, and it has nothing at all to do with Ethernet MAC (Media Access Control) addresses.

A.7.2 Why do I see ‘Fatal: Protocol error: Expected control record’ in PSCP?

This happens because PSCP was expecting to see data from the server that was part of the PSCP protocol exchange, and instead it saw data that it couldn’t make any sense of at all.

This almost always happens because the startup scripts in your account on the server machine are generating output. This is impossible for PSCP, or any other SCP client, to work around. You should never use startup files (.bashrc, .cshrc and so on) which generate output in non-interactive sessions.

This is not actually a PuTTY problem. If PSCP fails in this way, then all other SCP clients are likely to fail in exactly the same way. The problem is at the server end.

A.7.3 I clicked on a colour in the Colours panel, and the colour didn’t change in my terminal.

That isn’t how you’re supposed to use the Colours panel.

During the course of a session, PuTTY potentially uses all the colours listed in the Colours panel. It’s not a question of using only one of them and you choosing which one; PuTTY will use them all. The purpose of the Colours panel is to let you adjust the appearance of all the colours. So to change the colour of the cursor, for example, you would select ‘Cursor Colour’, press the ‘Modify’ button, and select a new colour from the dialog box that appeared. Similarly, if you want your session to appear in green, you should select ‘Default Foreground’ and press ‘Modify’. Clicking on ‘ANSI Green’ won’t turn your session green; it will only allow you to adjust the shade of green used when PuTTY is instructed by the server to display green text.

A.7.4 Plink on Windows 95 says it can’t find WS2_32.DLL.

Plink requires the extended Windows network library, WinSock version 2. This is installed as standard on Windows 98 and above, and on Windows NT, and even on later versions of Windows 95; but early Win95 installations don’t have it.

In order to use Plink on these systems, you will need to download the WinSock 2 upgrade:

http://www.microsoft.com/windows95/downloads/contents/
  wuadmintools/s_wunetworkingtools/w95sockets2/

A.7.5 After trying to establish an SSH-2 connection, PuTTY says ‘Out of memory’ and dies.

If this happens just while the connection is starting up, this often indicates that for some reason the client and server have failed to establish a session encryption key. Somehow, they have performed calculations that should have given each of them the same key, but have ended up with different keys; so data encrypted by one and decrypted by the other looks like random garbage.

This causes an ‘out of memory’ error because the first encrypted data PuTTY expects to see is the length of an SSH message. Normally this will be something well under 100 bytes. If the decryption has failed, PuTTY will see a completely random length in the region of two gigabytes, and will try to allocate enough memory to store this non-existent message. This will immediately lead to it thinking it doesn’t have enough memory, and panicking.

If this happens to you, it is quite likely to still be a PuTTY bug and you should report it (although it might be a bug in your SSH server instead); but it doesn’t necessarily mean you’ve actually run out of memory.

A.7.6 When attempting a file transfer, either PSCP or PSFTP says ‘Out of memory’ and dies.

This is almost always caused by your login scripts on the server generating output. PSCP or PSFTP will receive that output when they were expecting to see the start of a file transfer protocol, and they will attempt to interpret the output as file-transfer protocol. This will usually lead to an ‘out of memory’ error for much the same reasons as given in question A.7.5.

This is a setup problem in your account on your server, not a PSCP/PSFTP bug. Your login scripts should never generate output during non-interactive sessions; secure file transfer is not the only form of remote access that will break if they do.

On Unix, a simple fix is to ensure that all the parts of your login script that might generate output are in .profile (if you use a Bourne shell derivative) or .login (if you use a C shell). Putting them in more general files such as .bashrc or .cshrc is liable to lead to problems.