We are using Putty v0.62 through a tool on on Windows 2008 R2 Standard Edition and connecting to an external server using SSH version 2. We see that the following command works
psftp.exe Host -l Username –pw -2 -batch -l Username -i PrivateKeyLocation
but the following doesn't
psftp.exe Host -l Username –pw –batch -2 -l Username -i PrivateKeyLocation
Please help us to understand this problem and suggest a solution.
All comments are welcomed but keep in mind that our tool has a limitation of changing the sequence to -2 -batch.
Did you type these commands into the terminal, or did you copy and paste them from somewhere? The reason I ask is because of the hyphens. In the first line, the "hyphen" before pw is not a hyphen, nor are the "hyphens" before "pw" and "batch" in the second line. The characters that I've pointed out actually translate to ascii 8211 "en dash".
Hyphen characters are often converted to this character by word processors or wysiwyg HTML editors. This makes it near impossible at times to copy and paste command lines from web sites. Try typing the commands manually and see if it works.
It could also be that SO has converted the characters in your question for you, but I think that quite unlikely.
Related
I'm trying to change the root password on Solaris in a single command. So far I've tried:
echo "password" | passwd --stdin root
returns illegal option -- stdin on Solaris.
echo -e "password\npassword" | passwd root
Returns a 'New Password' prompt.
Using Solaris 10 and Bash 3.2.51 for the script.
You could do this via expect.
You could directly edit the /etc/shadow with sed or perl (of course you have to hash your password before, however as you want to hardcode it in your script you could use a different system, set the password manually copy it in your script and run the script of the target system. Or hash it on your own. is not that hard.
In solaris 11.3 starting with SRU4 there is a passwd -p to directly set the hash of the password. Would at least obfuscate the password by just putting the hash into the commandline.
But my real answer is:
Don't do it ... just don't do it. By setting the root password this way you essentially write a note with pink,blue and green marker around it with the root password in public for everyone who is on the system able to run ps in the moment you set the password. And this don't include the problem of management software putting ps outputs into central repositories and so put this information totally out of control of the system administrator.
Passwd doesn't read from STDIN, and there isn't an option, on Solaris, to read from STDIN.
A possible solution is to use an expect script
see: http://www.unix.com/solaris/161023-solaris-passwd-script.html
I have exported a db file from our staging server and need to secure copy the file from the remote server to my local machine. The issue that I am having, my username has a '#' character in it.
When I login via ssh I have to use a slightly weird syntax because of this:
ssh -o User=username#companyname 192.xxx.xxx.xx
Everything I try is resulting in a syntax error.
What I have tried:
scp 'username#companyname'192.xxx.xx.xx:/file/to/send /where/to/put
scp -o User=username#remote 192.xxx.xxx.xx:/file/to/send /where/to/put
Not really sure what else to try and don't want to spend too much time shooting in the dark.
At this point I could just use Filezilla and grab the file via sftp, but i'd like to know how to do this.
Thanks for any solid input with this.
So I have been working on this for some time. Would like to know if there is a better way or if I am on the right track.
I would basically like to allow some users to login to my server via SSH and then have a squid tunnel via that SSH connection.
The tricky part however is that I dont want these users to be able to execute ANY commands. I mean NOTHING at all.
So at this stage I have setup a Jail via - jailkit. The specific user is then placed in the jail and given the bash shell as a shell.
The next step would be to remove all the commands in the /jail/bin/ directories etc so that they are not able to execute any commands.
Am I on the right path here? What would you suggest?
Also...I see that it will give them many command not found errors...how do I remove these.
Is there any other shell I could look at giving them that would not let them do anything?
You could set their shell to something like /bin/true, or maybe a simple script that will output an informational message, and then have them logon using ssh -N (see the ssh manual page). I believe that allows them to use portforwarding without having an actuall shell on the system.
EDIT:
The equivalent of ssh -N in PuTTY is checking the "Don't start a shell or command at all" checkbox in its SSH configuration tab (Connection->SSH).
EDIT2:
As an alternative to this you could use a script that enters an infinite sleep loop. Until it is interrupted using Ctrl-C the connection will remain alive. I just tried this:
#!/bin/sh
echo "DNSH: Do-Nothing Shell"
while sleep 3600; do :; done
If you use this as a shell (preferrably with a more helpful message) your users will be able to use port-forwarding without an actual shell and without having to know about ssh -N and friends.
I know that we shuld do
ssh user#target
but where do we specify the password ?
Hmm thanks for all your replies.
My requirement is I have to start up some servers on different machines. All servers should be started with one shell script. Well, entering password every time seems little bad but I guess I will have to resort to that option. One reason why I don't want to save the public keys is I may not connect to same machines every time. It is easy to go back and modify the script to change target addresses though.
The best way to do this is by generating a private/public key pair, and storing your public key on the remote server. This is a secure way to login w/o typing in a password each time.
Read more here
This cannot be done with a simple ssh command, for security reasons. If you want to use the password route with ssh, the following link shows some scripts to get around this, if you are insistent:
Scripts to automate password entry
The ssh command will prompt for your password. It is unsafe to specify passwords on the commandline, as the full command that is executed is typically world-visible (e.g. ps aux) and also gets saved in plain text in your command history file. Any well written program (including ssh) will prompt for the password when necessary, and will disable teletype echoing so that it isn't visible on the terminal.
If you are attempting to execute ssh from cron or from the background, use ssh-agent.
The way I have done this in the past is just to set up a pair of authentication keys.
That way, you can log in without ever having to specify a password and it works in shell scripts. There is a good tutorial here:
http://linuxproblem.org/art_9.html
SSH Keys are the standard/suggested solution. The keys must be setup for the user that the script will run as.
For that script user, see if you have any keys setup in ~/.ssh/ (Key files will end with a .pub extension)
If you don't have any keys setup you can run:
ssh-keygen -t rsa
which will generate ~/.ssh/id_rsa.pub (the -t option has other types as well)
You can then copy the contents of this file to ~(remote-user)/.ssh/authorized_keys on the remote machine.
As the script user, you can test that it works by:
ssh remote-user#remote-machine
You should be logged in without a password prompt.
Along the same lines, now when your script is run from that user, it can auto SSH to the remote machine.
If you really want to use password authentication , you can try expect. See here for an example
How can I use expect to send a password to an ssh connection.
say the password was p#ssword
and the ssh command was
ssh me#127.0.0.1
What would I do with expect to a make it input the password when it says
me#127.0.0.1's password:
?
The proper action of using an SSH key pair isn't an option because I would have to use ssh (scp) to put the key on the server, which would ask for a password.
I always used the "proper" solution, but I used expect in other situations.
Here I found following suggestion:
#!/usr/local/bin/expect
spawn sftp -b cmdFile user#yourserver.com
expect "password:"
send "shhh!\n";
interact
Would it not be easier to use public key authentication and use a key with no passphrase?
As the user on the source machine do this to make an RSA key
ssh-keygen -t rsa
Now copy ~/.ssh/id_rsa.pub to the target machine and append it to the authorized_keys file of the target user
Your quickest way forward (unless you want to become a Tcl expert, which would be... unusual... in 2009) is probably to use autoexpect. Here's the man page:
http://expect.nist.gov/example/autoexpect.man.html
In short, fire up autoexpect, run your ssh session, finish up what you need to do, stop autoexpecting and then beat your keyboard over the resulting mess until it works :) I'm assuming you don't need anything more than a quick hack to get your keys sorted out and then, well it sounds like you know the score already with that.
And there's this question which already contains an example close to what you seek.
Cygwin has autoexpect just not in the bin package. run setup.exe and search for expect and check the source checkbox. you will see the resulting tree in /usr/src and in there there is a expect/expect/examples directory. in there lives a copy of the autoexpect script.
Key solution will not work... because the keys have to be readable only by the person running ssh. On xp you cannot create key structure with the correct permissions. So ssh will not read them. This may have changed, but last i checked it still not not work.
I'm pretty sure it is not possible to do what you're trying to do. Most *nix applications that prompt for a password read from the TTY directly, not stdin, so you can't pipe the password in. You can, as others have mentioned, configure SSH to not prompt for a password, as explained here.
After I was downvoted for no apparent reason, I went and did a little more research on the expect command and discovered that it has a send_tty command that sends to /dev/tty instead of stdin, which might actually do what you want... I was previously unaware of this feature. I still recommend putting the key on the server, however.