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
Related
I have a user ID set up on a server that doesn't require a password. I'd like to be able to use scp to transfer a file from it. My problem is scp keeps asking for my password even though there isn't one; I can telnet to the server and log on without the password. Is there any option (-o) I can specify to disable the password prompt? Using keys is not an option.
I'm no expert, but I'm guessing you might have to set PermitEmptyPasswords to Yes in /etc/ssh/sshd_config as per the instructions here.
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.
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
I want to know how to identify if the currently logged in user in Solaris is a LDAP user or local user.
Any command?
or any C Run time functions like getspname, getpwnam which returns an attribute saying it is an LDAP user or local user after user logged in?
Ldaplist will tell you if the user has an entry in the ldap database. It doesn't sort out the case where the user has also an entry in the /etc/passwd file though.
ldaplist passwd username
I am assuming that UID's that are "local" are in separate range from "LDAP". I'm also assuming that nsswitch is configured to use files and ldap for passwd, shadow, and or group. The command 'getent' should be present on GNU libc systems. I'm going to assume that the local 'files' databases are smaller than ldap source and so we will want to test the smaller and / or faster of the two sources.
if you wanted to determine if a given UID was present one of the databses you could run somthing similar to
$ getent --service=files passwd | grep 655
This could match the the default GID in the file so a more creative grep may be in order.
$ getent --service=files passwd | grep -e $.*:.*:655
If you are looking to turn this into a script-able item, then you will want to tack 'wc' on the end to do integer testing.
$ getent --service=files passwd | grep -e $.*:.*:655 | wc -l
This should return 0 if not found, or 1 (or more) if found. We would only test one source because we are assuming that we are testing a valid UID and that it will be in the other source if its not in here.
Lastly, as long as you are using nsswitch you should be able to use any of the C Libraries that support this to check if they are valid. I don't have any first hand experience with them, but i would assume that you can pass an option like we did here to only use a specific source. Alternately you can use the same logic as above and just cat /etc/passwd. Assuming again that if they arn't in here they are in ldap.
It is not going to be easy. You can open the password file and look for them. If they aren't there, conclude LDAP. Unless, of course, it's NIS. Or Kerberos. If your version of Solaris has PAM you could read up on that to see if it has any relief to offer.
If you are using sss as part of the ipaclient package,
getent --service=sss passwd $USER | wc -l
will tell you if the user exists in the LDAP Database of the FreeIPA server.
I have no idea how to tell what credentials they used to actually authenticate, but it should be easier to just look them up in the LDAP database and see if they are there. I use the ldap_client utility to look people up all the time. You need to know the name of the ldap server, and a few other details. Check the man page for it. For example, if the user has a local account, and they are in LDAP, the passwords that get checked at login will depend on the system configuration.
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.