1
0
mirror of https://git.tartarus.org/simon/putty.git synced 2025-01-09 17:38:00 +00:00
putty-source/doc/plink.but

481 lines
19 KiB
Plaintext
Raw Permalink Normal View History

\C{plink} Using the command-line connection tool \i{Plink}
\i{Plink} is a command-line connection tool similar to UNIX \c{ssh}.
It is mostly used for \i{automated operations}, such as making CVS
access a repository on a remote server.
Plink is probably not what you want if you want to run an
\i{interactive session} in a console window.
\H{plink-starting} Starting Plink
Plink is a command line application. This means that you cannot just
double-click on its icon to run it and instead you have to bring up
a \i{console window}. In Windows 95, 98, and ME, this is called an
\q{MS-DOS Prompt}, and in Windows NT, 2000, and XP, it is called a
\q{Command Prompt}. It should be available from the Programs section
of your Start Menu.
In order to use Plink, the file \c{plink.exe} will need either to be
on your \i{\c{PATH}} or in your current directory. To add the
directory containing Plink to your \c{PATH} environment variable,
type into the console window:
\c set PATH=C:\path\to\putty\directory;%PATH%
This will only work for the lifetime of that particular console
window. To set your \c{PATH} more permanently on Windows NT, 2000,
and XP, use the Environment tab of the System Control Panel. On
Windows 95, 98, and ME, you will need to edit your \i\c{AUTOEXEC.BAT}
to include a \c{set} command like the one above.
\H{plink-usage} Using Plink
This section describes the basics of how to use Plink for
interactive logins and for automated processes.
Once you've got a console window to type into, you can type
\c{plink --help} to bring up a usage message. This tells you the
version of Plink you're using, and gives you a brief summary of how to
use Plink:
\c C:\>plink --help
\c Plink: command-line connection utility
\c Release 0.82
\c Usage: plink [options] [user@]host [command]
\c ("host" can also be a PuTTY saved session name)
\c Options:
\c -V print version information and exit
\c -pgpfp print PGP key fingerprints and exit
\c -v show verbose messages
\c -load sessname Load settings from saved session
\c -ssh -telnet -rlogin -raw -serial
\c force use of a particular protocol
\c -ssh-connection
\c force use of the bare ssh-connection protocol
\c -P port connect to specified port
\c -l user connect with specified username
\c -batch disable all interactive prompts
\c -proxycmd command
\c use 'command' as local proxy
\c -sercfg configuration-string (e.g. 19200,8,n,1,X)
\c Specify the serial configuration (serial only)
\c The following options only apply to SSH connections:
\c -pwfile file login with password read from specified file
\c -D [listen-IP:]listen-port
\c Dynamic SOCKS-based port forwarding
\c -L [listen-IP:]listen-port:host:port
\c Forward local port to remote address
\c -R [listen-IP:]listen-port:host:port
\c Forward remote port to local address
\c -X -x enable / disable X11 forwarding
\c -A -a enable / disable agent forwarding
\c -t -T enable / disable pty allocation
\c -1 -2 force use of particular SSH protocol version
\c -4 -6 force use of IPv4 or IPv6
\c -C enable compression
\c -i key private key file for user authentication
\c -noagent disable use of Pageant
\c -agent enable use of Pageant
\c -no-trivial-auth
\c disconnect if SSH authentication succeeds trivially
\c -noshare disable use of connection sharing
\c -share enable use of connection sharing
\c -hostkey keyid
\c manually specify a host key (may be repeated)
Plink: default to sanitising non-tty console output. If Plink's standard output and/or standard error points at a Windows console or a Unix tty device, and if Plink was not configured to request a remote pty (and hence to send a terminal-type string), then we apply the new control-character stripping facility. The idea is to be a mild defence against malicious remote processes sending confusing escape sequences through the standard error channel when Plink is being used as a transport for something like git: it's OK to have actual sensible error messages come back from the server, but when you run a git command, you didn't really intend to give the remote server the implicit licence to write _all over_ your local terminal display. At the same time, in that scenario, the standard _output_ of Plink is left completely alone, on the grounds that git will be expecting it to be 8-bit clean. (And Plink can tell that because it's redirected away from the console.) For interactive login sessions using Plink, this behaviour is disabled, on the grounds that once you've sent a terminal-type string it's assumed that you were _expecting_ the server to use it to know what escape sequences to send to you. So it should be transparent for all the use cases I've so far thought of. But in case it's not, there's a family of new command-line options like -no-sanitise-stdout and -sanitise-stderr that you can use to forcibly override the autodetection of whether to do it. This all applies the same way to both Unix and Windows Plink.
2019-02-20 07:03:57 +00:00
\c -sanitise-stderr, -sanitise-stdout, -no-sanitise-stderr, -no-sanitise-stdout
\c do/don't strip control chars from standard output/error
\c -no-antispoof omit anti-spoofing prompt after authentication
\c -m file read remote command(s) from file
\c -s remote command is an SSH subsystem (SSH-2 only)
\c -N don't start a shell/command (SSH-2 only)
\c -nc host:port
\c open tunnel in place of session (SSH-2 only)
\c -sshlog file
\c -sshrawlog file
\c log protocol details to a file
2020-11-25 15:12:56 +00:00
\c -logoverwrite
\c -logappend
\c control what happens when a log file already exists
\c -shareexists
\c test whether a connection-sharing upstream exists
Once this works, you are ready to use Plink.
\S{plink-usage-interactive} Using Plink for interactive logins
To make a simple interactive connection to a remote server, just
type \c{plink} and then the host name:
\c C:\>plink login.example.com
\c
\c Debian GNU/Linux 2.2 flunky.example.com
\c flunky login:
You should then be able to log in as normal and run a session. The
output sent by the server will be written straight to your command
prompt window, which will most likely not interpret terminal \i{control
codes} in the way the server expects it to. So if you run any
full-screen applications, for example, you can expect to see strange
characters appearing in your window. Interactive connections like
this are not the main point of Plink.
In order to connect with a different protocol, you can give the
command line options \c{-ssh}, \c{-ssh-connection}, \c{-telnet},
\c{-rlogin}, or \c{-raw}. To make an SSH connection, for example:
\c C:\>plink -ssh login.example.com
\c login as:
If you have already set up a PuTTY saved session, then instead of
supplying a host name, you can give the saved session name. This
allows you to use public-key authentication, specify a user name,
and use most of the other features of PuTTY:
\c C:\>plink my-ssh-session
\c Sent username "fred"
\c Authenticating with public key "fred@winbox"
\c Last login: Thu Dec 6 19:25:33 2001 from :0.0
\c fred@flunky:~$
(You can also use the \c{-load} command-line option to load a saved
session; see \k{using-cmdline-load}. If you use \c{-load}, the saved
session exists, and it specifies a hostname, you cannot also specify a
\c{host} or \c{user@host} argument - it will be treated as part of the
remote command.)
\S{plink-usage-batch} Using Plink for automated connections
More typically Plink is used with the SSH protocol, to enable you to
talk directly to a program running on the server. To do this you
have to ensure Plink is \e{using} the SSH protocol. You can do this
in several ways:
\b Use the \c{-ssh} option as described in
\k{plink-usage-interactive}.
\b Set up a PuTTY saved session that describes the server you are
connecting to, and that also specifies the protocol as SSH.
\b Set the Windows environment variable \i\c{PLINK_PROTOCOL} to the
word \c{ssh}.
Usually Plink is not invoked directly by a user, but run
automatically by another process. Therefore you typically do not
want Plink to prompt you for a user name or a password.
Next, you are likely to need to avoid the various interactive
prompts Plink can produce. You might be prompted to verify the host
key of the server you're connecting to, to enter a user name, or to
enter a password.
To avoid being prompted for the server host key when using Plink for
2021-03-27 18:35:43 +00:00
an automated connection, you can first make a \e{manual}
connection (using either of PuTTY or Plink) to the same server,
verify the host key (see \k{gs-hostkey} for more information), and
2021-03-27 18:35:43 +00:00
select \q{Accept} to add the host key to the Registry. After that,
Plink commands connecting to that server should not give a host key
prompt unless the host key changes. Alternatively, you can specify
the appropriate host key(s) on Plink's command line every time you
use it; see \k{using-cmdline-hostkey}.
To avoid being prompted for a user name, you can:
\b Use the \c{-l} option to specify a user name on the command line.
For example, \c{plink login.example.com -l fred}.
\b Set up a PuTTY saved session that describes the server you are
connecting to, and that also specifies the username to log in as
(see \k{config-username}).
To avoid being prompted for a password, you should almost certainly
set up \i{public-key authentication}. (See \k{pubkey} for a general
introduction to public-key authentication.) Again, you can do this
in two ways:
\b Set up a PuTTY saved session that describes the server you are
connecting to, and that also specifies a private key file (see
\k{config-ssh-privkey}). For this to work without prompting, your
private key will need to have no passphrase.
\b Store the private key in Pageant. See \k{pageant} for further
information.
Once you have done all this, you should be able to run a remote
command on the SSH server machine and have it execute automatically
with no prompting:
\c C:\>plink login.example.com -l fred echo hello, world
\c hello, world
\c
\c C:\>
Or, if you have set up a saved session with all the connection
details:
\c C:\>plink mysession echo hello, world
\c hello, world
\c
\c C:\>
Then you can set up other programs to run this Plink command and
talk to it as if it were a process on the server machine.
\S{plink-options} Plink command line options
Plink accepts all the general command line options supported by the
PuTTY tools. See \k{using-general-opts} for a description of these
options.
Plink also supports some of its own options. The following sections
describe Plink's specific command-line options.
\S2{plink-option-batch} \I{-batch-plink}\c{-batch}: disable all
interactive prompts
If you use the \c{-batch} option, Plink will never give an
interactive prompt while establishing the connection. If the
server's host key is invalid, for example (see \k{gs-hostkey}), then
the connection will simply be abandoned instead of asking you what
to do next.
This may help Plink's behaviour when it is used in automated
scripts: using \c{-batch}, if something goes wrong at connection
time, the batch job will fail rather than hang.
If another program is invoking Plink on your behalf, then you might
need to arrange that that program passes \c{-batch} to Plink. See
\k{plink-git} for an example involving Git.
\S2{plink-option-s} \I{-s-plink}\c{-s}: remote command is SSH subsystem
If you specify the \c{-s} option, Plink passes the specified command
as the name of an SSH \q{\i{subsystem}} rather than an ordinary command
line.
(This option is only meaningful with the SSH-2 protocol.)
\S2{plink-option-share} \I{-share-plink}\c{-share}:
Test and try to share an existing connection.
This option tries to detect if an existing connection can be shared
(See \k{config-ssh-sharing} for more information about SSH connection
sharing.) and reuses that connection.
A Plink invocation of the form:
\c plink -share <session>
\e iiiiiiiii
will test whether there is currently a viable \q{upstream} for the
session in question, which can be specified using any syntax you'd
normally use with Plink to make an actual connection (a host/port
number, a bare saved session name, \c{-load}, etc). If no \q{upstream}
viable session is found and \c{-share} is specified, this connection
will be become the \q{upstream} connection for subsequent connection
sharing tries.
(This option is only meaningful with the SSH-2 protocol.)
\S2{plink-option-shareexists} \I{-shareexists-plink}\c{-shareexists}:
test for connection-sharing upstream
This option does not make a new connection; instead it allows testing
for the presence of an existing connection that can be shared.
(See \k{config-ssh-sharing} for more information about SSH connection
sharing.)
A Plink invocation of the form:
\c plink -shareexists <session>
\e iiiiiiiii
will test whether there is currently a viable \q{upstream} for the
session in question, which can be specified using any syntax you'd
normally use with Plink to make an actual connection (a host/port
number, a bare saved session name, \c{-load}, etc). It returns a
zero exit status if a usable \q{upstream} exists, nonzero otherwise.
(This option is only meaningful with the SSH-2 protocol.)
Plink: default to sanitising non-tty console output. If Plink's standard output and/or standard error points at a Windows console or a Unix tty device, and if Plink was not configured to request a remote pty (and hence to send a terminal-type string), then we apply the new control-character stripping facility. The idea is to be a mild defence against malicious remote processes sending confusing escape sequences through the standard error channel when Plink is being used as a transport for something like git: it's OK to have actual sensible error messages come back from the server, but when you run a git command, you didn't really intend to give the remote server the implicit licence to write _all over_ your local terminal display. At the same time, in that scenario, the standard _output_ of Plink is left completely alone, on the grounds that git will be expecting it to be 8-bit clean. (And Plink can tell that because it's redirected away from the console.) For interactive login sessions using Plink, this behaviour is disabled, on the grounds that once you've sent a terminal-type string it's assumed that you were _expecting_ the server to use it to know what escape sequences to send to you. So it should be transparent for all the use cases I've so far thought of. But in case it's not, there's a family of new command-line options like -no-sanitise-stdout and -sanitise-stderr that you can use to forcibly override the autodetection of whether to do it. This all applies the same way to both Unix and Windows Plink.
2019-02-20 07:03:57 +00:00
\S2{plink-option-sanitise} \I{-sanitise-stderr}\I{-sanitise-stdout}\I{-no-sanitise-stderr}\I{-no-sanitise-stdout}\c{-sanitise-}\e{stream}: control output sanitisation
In some situations, Plink applies a sanitisation pass to the output
received from the server, to strip out control characters such as
backspace and the escape character.
Plink: default to sanitising non-tty console output. If Plink's standard output and/or standard error points at a Windows console or a Unix tty device, and if Plink was not configured to request a remote pty (and hence to send a terminal-type string), then we apply the new control-character stripping facility. The idea is to be a mild defence against malicious remote processes sending confusing escape sequences through the standard error channel when Plink is being used as a transport for something like git: it's OK to have actual sensible error messages come back from the server, but when you run a git command, you didn't really intend to give the remote server the implicit licence to write _all over_ your local terminal display. At the same time, in that scenario, the standard _output_ of Plink is left completely alone, on the grounds that git will be expecting it to be 8-bit clean. (And Plink can tell that because it's redirected away from the console.) For interactive login sessions using Plink, this behaviour is disabled, on the grounds that once you've sent a terminal-type string it's assumed that you were _expecting_ the server to use it to know what escape sequences to send to you. So it should be transparent for all the use cases I've so far thought of. But in case it's not, there's a family of new command-line options like -no-sanitise-stdout and -sanitise-stderr that you can use to forcibly override the autodetection of whether to do it. This all applies the same way to both Unix and Windows Plink.
2019-02-20 07:03:57 +00:00
The idea of this is to prevent remote processes from sending confusing
escape sequences through the standard error channel when Plink is
being used as a transport for something like \cw{git} or CVS. If the
server actually wants to send an error message, it will probably be
plain text; if the server abuses that channel to try to write over
unexpected parts of your terminal display, Plink will try to stop it.
By default, this only happens for output channels which are sent to a
Windows console device, or a Unix terminal device. (Any output stream
going somewhere else is likely to be needed by an 8-bit protocol and
must not be tampered with at all.) It also stops happening if you tell
Plink to allocate a remote pseudo-terminal (see \k{using-cmdline-pty}
and \k{config-ssh-pty}), on the basis that in that situation you often
\e{want} escape sequences from the server to go to your terminal.
But in case Plink guesses wrong about whether you want this
sanitisation, you can override it in either direction, using one of
these options:
2021-03-27 18:01:53 +00:00
\dt \c{-sanitise-stderr}
Plink: default to sanitising non-tty console output. If Plink's standard output and/or standard error points at a Windows console or a Unix tty device, and if Plink was not configured to request a remote pty (and hence to send a terminal-type string), then we apply the new control-character stripping facility. The idea is to be a mild defence against malicious remote processes sending confusing escape sequences through the standard error channel when Plink is being used as a transport for something like git: it's OK to have actual sensible error messages come back from the server, but when you run a git command, you didn't really intend to give the remote server the implicit licence to write _all over_ your local terminal display. At the same time, in that scenario, the standard _output_ of Plink is left completely alone, on the grounds that git will be expecting it to be 8-bit clean. (And Plink can tell that because it's redirected away from the console.) For interactive login sessions using Plink, this behaviour is disabled, on the grounds that once you've sent a terminal-type string it's assumed that you were _expecting_ the server to use it to know what escape sequences to send to you. So it should be transparent for all the use cases I've so far thought of. But in case it's not, there's a family of new command-line options like -no-sanitise-stdout and -sanitise-stderr that you can use to forcibly override the autodetection of whether to do it. This all applies the same way to both Unix and Windows Plink.
2019-02-20 07:03:57 +00:00
2021-03-27 18:01:53 +00:00
\dd Sanitise server data written to Plink's standard error channel,
Plink: default to sanitising non-tty console output. If Plink's standard output and/or standard error points at a Windows console or a Unix tty device, and if Plink was not configured to request a remote pty (and hence to send a terminal-type string), then we apply the new control-character stripping facility. The idea is to be a mild defence against malicious remote processes sending confusing escape sequences through the standard error channel when Plink is being used as a transport for something like git: it's OK to have actual sensible error messages come back from the server, but when you run a git command, you didn't really intend to give the remote server the implicit licence to write _all over_ your local terminal display. At the same time, in that scenario, the standard _output_ of Plink is left completely alone, on the grounds that git will be expecting it to be 8-bit clean. (And Plink can tell that because it's redirected away from the console.) For interactive login sessions using Plink, this behaviour is disabled, on the grounds that once you've sent a terminal-type string it's assumed that you were _expecting_ the server to use it to know what escape sequences to send to you. So it should be transparent for all the use cases I've so far thought of. But in case it's not, there's a family of new command-line options like -no-sanitise-stdout and -sanitise-stderr that you can use to forcibly override the autodetection of whether to do it. This all applies the same way to both Unix and Windows Plink.
2019-02-20 07:03:57 +00:00
regardless of terminals and consoles and remote ptys.
2021-03-27 18:01:53 +00:00
\dt \c{-no-sanitise-stderr}
Plink: default to sanitising non-tty console output. If Plink's standard output and/or standard error points at a Windows console or a Unix tty device, and if Plink was not configured to request a remote pty (and hence to send a terminal-type string), then we apply the new control-character stripping facility. The idea is to be a mild defence against malicious remote processes sending confusing escape sequences through the standard error channel when Plink is being used as a transport for something like git: it's OK to have actual sensible error messages come back from the server, but when you run a git command, you didn't really intend to give the remote server the implicit licence to write _all over_ your local terminal display. At the same time, in that scenario, the standard _output_ of Plink is left completely alone, on the grounds that git will be expecting it to be 8-bit clean. (And Plink can tell that because it's redirected away from the console.) For interactive login sessions using Plink, this behaviour is disabled, on the grounds that once you've sent a terminal-type string it's assumed that you were _expecting_ the server to use it to know what escape sequences to send to you. So it should be transparent for all the use cases I've so far thought of. But in case it's not, there's a family of new command-line options like -no-sanitise-stdout and -sanitise-stderr that you can use to forcibly override the autodetection of whether to do it. This all applies the same way to both Unix and Windows Plink.
2019-02-20 07:03:57 +00:00
2021-03-27 18:01:53 +00:00
\dd Do not sanitise server data written to Plink's standard error
Plink: default to sanitising non-tty console output. If Plink's standard output and/or standard error points at a Windows console or a Unix tty device, and if Plink was not configured to request a remote pty (and hence to send a terminal-type string), then we apply the new control-character stripping facility. The idea is to be a mild defence against malicious remote processes sending confusing escape sequences through the standard error channel when Plink is being used as a transport for something like git: it's OK to have actual sensible error messages come back from the server, but when you run a git command, you didn't really intend to give the remote server the implicit licence to write _all over_ your local terminal display. At the same time, in that scenario, the standard _output_ of Plink is left completely alone, on the grounds that git will be expecting it to be 8-bit clean. (And Plink can tell that because it's redirected away from the console.) For interactive login sessions using Plink, this behaviour is disabled, on the grounds that once you've sent a terminal-type string it's assumed that you were _expecting_ the server to use it to know what escape sequences to send to you. So it should be transparent for all the use cases I've so far thought of. But in case it's not, there's a family of new command-line options like -no-sanitise-stdout and -sanitise-stderr that you can use to forcibly override the autodetection of whether to do it. This all applies the same way to both Unix and Windows Plink.
2019-02-20 07:03:57 +00:00
channel.
2021-03-27 18:01:53 +00:00
\dt \c{-sanitise-stdout}
Plink: default to sanitising non-tty console output. If Plink's standard output and/or standard error points at a Windows console or a Unix tty device, and if Plink was not configured to request a remote pty (and hence to send a terminal-type string), then we apply the new control-character stripping facility. The idea is to be a mild defence against malicious remote processes sending confusing escape sequences through the standard error channel when Plink is being used as a transport for something like git: it's OK to have actual sensible error messages come back from the server, but when you run a git command, you didn't really intend to give the remote server the implicit licence to write _all over_ your local terminal display. At the same time, in that scenario, the standard _output_ of Plink is left completely alone, on the grounds that git will be expecting it to be 8-bit clean. (And Plink can tell that because it's redirected away from the console.) For interactive login sessions using Plink, this behaviour is disabled, on the grounds that once you've sent a terminal-type string it's assumed that you were _expecting_ the server to use it to know what escape sequences to send to you. So it should be transparent for all the use cases I've so far thought of. But in case it's not, there's a family of new command-line options like -no-sanitise-stdout and -sanitise-stderr that you can use to forcibly override the autodetection of whether to do it. This all applies the same way to both Unix and Windows Plink.
2019-02-20 07:03:57 +00:00
2021-03-27 18:01:53 +00:00
\dd Sanitise server data written to Plink's standard output channel.
Plink: default to sanitising non-tty console output. If Plink's standard output and/or standard error points at a Windows console or a Unix tty device, and if Plink was not configured to request a remote pty (and hence to send a terminal-type string), then we apply the new control-character stripping facility. The idea is to be a mild defence against malicious remote processes sending confusing escape sequences through the standard error channel when Plink is being used as a transport for something like git: it's OK to have actual sensible error messages come back from the server, but when you run a git command, you didn't really intend to give the remote server the implicit licence to write _all over_ your local terminal display. At the same time, in that scenario, the standard _output_ of Plink is left completely alone, on the grounds that git will be expecting it to be 8-bit clean. (And Plink can tell that because it's redirected away from the console.) For interactive login sessions using Plink, this behaviour is disabled, on the grounds that once you've sent a terminal-type string it's assumed that you were _expecting_ the server to use it to know what escape sequences to send to you. So it should be transparent for all the use cases I've so far thought of. But in case it's not, there's a family of new command-line options like -no-sanitise-stdout and -sanitise-stderr that you can use to forcibly override the autodetection of whether to do it. This all applies the same way to both Unix and Windows Plink.
2019-02-20 07:03:57 +00:00
2021-03-27 18:01:53 +00:00
\dt \c{-no-sanitise-stdout}
Plink: default to sanitising non-tty console output. If Plink's standard output and/or standard error points at a Windows console or a Unix tty device, and if Plink was not configured to request a remote pty (and hence to send a terminal-type string), then we apply the new control-character stripping facility. The idea is to be a mild defence against malicious remote processes sending confusing escape sequences through the standard error channel when Plink is being used as a transport for something like git: it's OK to have actual sensible error messages come back from the server, but when you run a git command, you didn't really intend to give the remote server the implicit licence to write _all over_ your local terminal display. At the same time, in that scenario, the standard _output_ of Plink is left completely alone, on the grounds that git will be expecting it to be 8-bit clean. (And Plink can tell that because it's redirected away from the console.) For interactive login sessions using Plink, this behaviour is disabled, on the grounds that once you've sent a terminal-type string it's assumed that you were _expecting_ the server to use it to know what escape sequences to send to you. So it should be transparent for all the use cases I've so far thought of. But in case it's not, there's a family of new command-line options like -no-sanitise-stdout and -sanitise-stderr that you can use to forcibly override the autodetection of whether to do it. This all applies the same way to both Unix and Windows Plink.
2019-02-20 07:03:57 +00:00
2021-03-27 18:01:53 +00:00
\dd Do not sanitise server data written to Plink's standard output
Plink: default to sanitising non-tty console output. If Plink's standard output and/or standard error points at a Windows console or a Unix tty device, and if Plink was not configured to request a remote pty (and hence to send a terminal-type string), then we apply the new control-character stripping facility. The idea is to be a mild defence against malicious remote processes sending confusing escape sequences through the standard error channel when Plink is being used as a transport for something like git: it's OK to have actual sensible error messages come back from the server, but when you run a git command, you didn't really intend to give the remote server the implicit licence to write _all over_ your local terminal display. At the same time, in that scenario, the standard _output_ of Plink is left completely alone, on the grounds that git will be expecting it to be 8-bit clean. (And Plink can tell that because it's redirected away from the console.) For interactive login sessions using Plink, this behaviour is disabled, on the grounds that once you've sent a terminal-type string it's assumed that you were _expecting_ the server to use it to know what escape sequences to send to you. So it should be transparent for all the use cases I've so far thought of. But in case it's not, there's a family of new command-line options like -no-sanitise-stdout and -sanitise-stderr that you can use to forcibly override the autodetection of whether to do it. This all applies the same way to both Unix and Windows Plink.
2019-02-20 07:03:57 +00:00
channel.
2021-03-27 18:01:53 +00:00
\S2{plink-option-antispoof} \i{-no-antispoof}: turn off authentication spoofing protection prompt
In SSH, some possible server authentication methods require user input
(for example, password authentication, or entering a private key
passphrase), and others do not (e.g. a private key held in Pageant).
If you use Plink to run an interactive login session, and if Plink
authenticates without needing any user interaction, and if the server
is malicious or compromised, it could try to trick you into giving it
authentication data that should not go to the server (such as your
private key passphrase), by sending what \e{looks} like one of Plink's
local prompts, as if Plink had not already authenticated.
To protect against this, Plink's default policy is to finish the
authentication phase with a final trivial prompt looking like this:
\c Access granted. Press Return to begin session.
so that if you saw anything that looked like an authentication prompt
\e{after} that line, you would know it was not from Plink.
That extra interactive step is inconvenient. So Plink will turn it off
in as many situations as it can:
\b If Plink's standard input is not pointing at a console or terminal
device \dash for example, if you're using Plink as a transport for
some automated application like version control \dash then you
\e{can't} type passphrases into the server anyway. In that situation,
Plink won't try to protect you from the server trying to fool you into
doing so.
\b If Plink is in batch mode (see \k{plink-usage-batch}), then it
\e{never} does any interactive authentication. So anything looking
like an interactive authentication prompt is automatically suspect,
and so Plink omits the anti-spoofing prompt.
But if you still find the protective prompt inconvenient, and you
trust the server not to try a trick like this, you can turn it off
using the \cq{-no-antispoof} option.
\H{plink-batch} Using Plink in \i{batch files} and \i{scripts}
Once you have set up Plink to be able to log in to a remote server
without any interactive prompting (see \k{plink-usage-batch}), you
can use it for lots of scripting and batch purposes. For example, to
start a backup on a remote machine, you might use a command like:
\c plink root@myserver /etc/backups/do-backup.sh
Or perhaps you want to fetch all system log lines relating to a
particular web area:
\c plink mysession grep /~fred/ /var/log/httpd/access.log > fredlog
Any non-interactive command you could usefully run on the server
command line, you can run in a batch file using Plink in this way.
\H{plink-git} Using Plink with \i{Git}
To use Plink for Git operations performed over SSH, you can set the
environment variable \i\c{GIT_SSH_COMMAND} to point to Plink.
For example, if you've run PuTTY's full Windows installer and it has
installed Plink in the default location, you might do this:
\c set GIT_SSH_COMMAND="C:\Program Files\PuTTY\plink.exe"
or if you've put Plink somewhere else then you can do a similar thing
with a different path.
This environment variable accepts a whole command line, not just an
executable file name. So you can add Plink options to the end of it if
you like. For example, if you're using Git in a batch-mode context,
where your Git jobs are running unattended and nobody is available to
answer interactive prompts, you might also append the \cq{-batch}
option (\k{plink-option-batch}):
\c set GIT_SSH_COMMAND="C:\Program Files\PuTTY\plink.exe" -batch
and then if Plink unexpectedly prints a prompt of some kind (for
example, because the SSH server's host key has changed), your batch
job will terminate with an error message, instead of stopping and
waiting for user input that will never arrive.
(However, you don't \e{always} want to do this with Git. If you're
using Git interactively, you might \e{want} Plink to stop for
interactive prompts \dash for example, to let you enter a password for
the SSH server.)
\H{plink-cvs} Using Plink with \i{CVS}
To use Plink with CVS, you need to set the environment variable
\i\c{CVS_RSH} to point to Plink:
\c set CVS_RSH=\path\to\plink.exe
You also need to arrange to be able to connect to a remote host
without any interactive prompts, as described in
\k{plink-usage-batch}.
You should then be able to run CVS as follows:
\c cvs -d :ext:user@sessionname:/path/to/repository co module
If you specified a username in your saved session, you don't even
need to specify the \q{user} part of this, and you can just say:
\c cvs -d :ext:sessionname:/path/to/repository co module
\H{plink-wincvs} Using Plink with \i{WinCVS}
Plink can also be used with WinCVS. Firstly, arrange for Plink to be
able to connect to a remote host non-interactively, as described in
\k{plink-usage-batch}.
Then, in WinCVS, bring up the \q{Preferences} dialogue box from the
\e{Admin} menu, and switch to the \q{Ports} tab. Tick the box there
labelled \q{Check for an alternate \cw{rsh} name} and in the text
entry field to the right enter the full path to \c{plink.exe}.
Select \q{OK} on the \q{Preferences} dialogue box.
Next, select \q{Command Line} from the WinCVS \q{Admin} menu, and type
a CVS command as in \k{plink-cvs}, for example:
\c cvs -d :ext:user@hostname:/path/to/repository co module
or (if you're using a saved session):
\c cvs -d :ext:user@sessionname:/path/to/repository co module
Select the folder you want to check out to with the \q{Change Folder}
button, and click \q{OK} to check out your module. Once you've got
modules checked out, WinCVS will happily invoke plink from the GUI for
CVS operations.
\# \H{plink-whatelse} Using Plink with... ?