I am running options in putty for long hours and would like to find out if there is a possibility to have a continuous event log exported to either a .txt or a MS Word document.
Use Plink (PuTTY command-line connection tool) instead of PuTTY, use the -v (show verbose messages) command-line switch and redirect both its standard and error output to a log file:
The Plink has the same command-line options as PuTTY.
plink.exe user#host -v > output.log 2>&1
See Using the command-line connection tool Plink.
This also an option in the settings of putty to output the log to a text file. You can chose to overwrite the file everytime you start a new session or just append to the end of text file.
Related
I have tectia ssh server in a windows environment.
When I use sftpg3 -B cmd.txt username#host that works fine. The only problem is that it doesnt let me execute files remotely, it only lets me move files. It reads the commands from cmd.txt but since I cant execute anything it ignores the commands.
Well when I do the same thing but use sshg3, it doesnt recognize the -B flag at all.
SSHG3 -B cmd.txt username#host
cmd.txt' is not recognized as an internal or external command,
operable program or batch file.
I've tried putting -B "cmd.txt"
I tried just putting the cmd.txt contents in the same script instead of housing them in cmd.txt and getting rid of -B, but it doesnt run them that way either.
The docs dont have much to go off of. All it says is use -B for batch processing.
Contents of cmd.txt:
D:
cd Library
cd Backup
parseLibrary.cmd
exit
Trying to sshg3 into a host, navigate to a path and run a batch file on that host.
Any ideas?
-B, --batch-mode
Uses batch mode. Fails authentication if it requires user interaction on the terminal.
Using batch mode requires that you have previously saved the server host key on the client and set up a non-interactive method for user authentication (for example, host-based authentication or public-key authentication without a passphrase).
It does use public key authentication, there is no user interaction needed on the terminal.
Noticed this on the docs for sftpg3
-B [ - | batch_file ]
The -B - option enables reading from the standard input. This option is useful when you want to launch processes with sftpg3 and redirect the stdin pipes.
By defining the name of a batch_file as an attribute, you can execute SFTP commands from the given file in batch mode. The file can contain any allowed SFTP commands. For a description of the commands, see the section called “Commands”.
Using batch mode requires that you have previously saved the server host key on the client and set up a non-interactive method for user authentication (for example, host-based authentication or public-key authentication without a passphrase).
I'm guessing batch file is different than batch mode?
*I figured it out. You have to use the -B flag for every command you want to execute.
I figured it out. You have to use the -B flag for every command you want to execute.
sshg3 user#host -B dir -B ipconfig -B etc.cmd
I'm attempting to launch putty via the command line in such a way that it runs a command on the server (I want to create a windows shortcut, to tail a log file)
So far I have a batch file containing this
"C:\Program Files (x86)\PuTTY\putty.exe" -ssh -t -pw -m tail_catalina_out -load "myprofile"
And within my server I have a file at the root directory named tail_catalina_out with the following contents.
tail -f /opt/tomcat/logs/catalina.out
Putty launches and my session starts successfully, but no command appears to be carried out despite this? Am I misunderstanding how this works?
You don't need -ssh with -load profile (and if you use a nonstandard port like my test it doesn't work at all); in fact you don't need it with [user#]host because it's the default
-pw -m tail_catalina_out uses -m as your password (which I hope is incorrect, so you should be reprompted unless publickey auth is set-up) and ignores tail_catalina_out
the file for -m must be local i.e. on the PuTTY machine not on the server (although the commands in it will be sent to, and must be valid on, the server)
Thus: "\path\to\putty" -t -m localcmdfile -load profile
You could also use plink which runs in the console and takes either -m localfile or the actual remote command on the command line after the last option (like the OpenSSH client ssh):
"\path\to\plink" -t -load profile tail -f remotefile
As usual, you can omit the quotes around the path if it contains no space. Personally I use \progra~2 instead of bothering with "\program files (x86)" but that's just me, and it may depend on a clean install (instead of upgrade).
I'm using plink to run a script on a remote server (Linux) from a Windows machine. Part of the script prompts for inputs (authentication to various other remote servers that use different credentials). I don't want to store the password in the script as each use will be using their own for auditing reasons.
I need the prompt to be transmitted to the Windows terminal window and I need the input transmitted back to the Linux box. Additionally I need to write log all this into a file, like this:
plink username#unixbox /etc/scrips/myscript.bash > report.txt
At the moment the above works but all that prints to report.txt is the prompts
please enter password for reportBox1?
please enter password for reportBox2?
Instead I need it to send the password prompt and input to the Linux box to continue running the script as it normally would, only remotely. So the output of report.txt would read:
please enter password for reportBox1? *
File 1
File 2
File 3
please enter password for reportBox2? *
Data a
data b
data b
Hope that makes sense. If there's something better than plink can be used such as putty's ssh.exe please let me know that one instead.
First off: plink is PuTTY's ssh.exe.
If you want to be able to answer the password prompt on the Windows machine, you need to tell plink to allocate a pseudo-terminal with -t:
plink -t username#unixbox /etc/scrips/myscript.bash
Now you get the prompt and input will be sent back. But if you redirect STDOUT to report.txt...
plink -t username#unixbox /etc/scrips/myscript.bash > report.txt
...you won't see the prompt, because it's redirected into report.txt (although the script still runs and waits for your input). To get around this, you need some tool which allows you to redirect the output to multiple destinations - STDOUT and report.txt at the same time. In the *nix world, the command for this is tee. There are ports of tee for Windows:
as part of GnuWin32 (this is what I'm using)
as part of UnxUtils
as batch, perl and rexx versions
Having set one of those up, you'd do:
plink -t username#unixbox /etc/scrips/myscript.bash | tee report.txt
Security note: If the password prompts in the script on the Linux machine echo what was input, the passwords will of course also be logged in report.txt, which might be a problem.
I am using ftp in the command line (terminal) to transfer multiple data files from a remote server to my local computer. There are multiple files (~40) in the directory and I would like to transfer them all without having to answer yes in the prompt for each file. I tried mget * but this only transferred the first file and then a prompt popped up for the second file.
Issue a prompt command first to turn interactive prompting off.
Alternatively, if you have control over the way the ftp command is called, use the command line option, as suggested by #reg-edit:
ftp [-i | --no-prompt] [OPTIONS] [HOST [PORT]]
As an alternative to issuing a prompt command ahead of your other commands, you may invoke ftp with the -i switch.
When you already started ftp you can issue the prompt command to toggle between getting prompted and not getting prompted. So this should do the trick:
> ftp <some server>
ftp> prompt
Interactive mode OFF .
ftp> mget *
I need to create SSH tunnel with PuTTY in Windows, that would do the same as this command in Linux:
ssh -fN -L 2000:SomeIp:2000 myusername#myLinuxBox
I tried many options in PuTTY, including setting source port in GUI to "2000" and destination to "SomeIp:2000". Destination is set to local (as the -L switch suggests).
I successfully login to my SSH box but port forward is not made.
Is this even possible in Windows, so that all the connections made by programs that use this port (2000) will go through this tunnel?
With the PuTTY suite, you can set up a tunnel either using the PuTTY itself (GUI) or using the command-line tool plink.exe.
With the plink.exe, you use the same arguments as with the OpenSSH ssh, except for the -f, which does not have an equivalent in Windows.
plink.exe -N -L 2000:SomeIp:2000 myusername#myLinuxBox
Reference: Using the command-line connection tool Plink
With the PuTTY, the -L 2000:SomeIp:2000 translates to:
So it's actually, what you claim to have tried. If you have any problems, use the PuTTY event log to investigate:
The -N translates to the option "Don't start a shell or command at all".
But it probably does not make sense with a GUI client to enable it, as you get a window anyway, you just cannot do anything with it. See also the PuTTY wish no-terminal-window.
If you are going to use the tunnel to connect with PuTTY to another server, you can actually set up the tunnel as a part of the session settings with use of plink as a proxy, see: PuTTY configuration equivalent to OpenSSH ProxyCommand.
You probably want to use plink.exe instead of the GUI client. The command line syntax is compatible iirc.
Or you can wade through the putty GUI, which also allows this. See Connection > SSH > Tunnels on the left side with the option tree.
The answers above mention two different ways of resolving the problem:
using plink
using putty GUI
I don't have plink and I can't download the plink.exe file (it is a closely monitored restricted environment) so used a different way to script the solution with a one-line script:
start putty -ssh myusername#myLinuxBox -pw my_pw -L 2000:localhost:2000
Store this in a batch file (file extension ".bat", e.g. "tunnel.bat"). So every time you double-click on this file the command is run and putty creates the ssh tunnel. If you want more tunnels just repeat this part
-L 2000:localhost:2000
by changing the ports accordingly.
"Source" port is a port number on the same machine from which you are running putty (eg. open this in your browser: 127.0.0.1:source). "Destination" is your remote port that you want to connect to from your local machine. It started to work after I realized this.