When i am trying to connect to other server using ssh coomand, it is prompting for password.
But i want to hardcode it with username so that it should not prompt for password.
And i dont want to use "ssh-keygen" method as it is not allowed.
If they don't even allow ssh-keygen, I'm sure they'd be horrified to have you kludging stored plaintext passwords into the login prompt with the expect third-party brute-forcing tool.
Keys are the safe and secure way to do it. If you're not allowed, you're only left with insecure methods.
A terrible position. Have you asked why generating a key pair is not allowed? Our security team are very hot on searching for anything that has hard-coded values.
Perhaps I'm miss-reading your message though. Are you actually saying that you are connected to your local server as User1, but you need to connect to the remote server as User2 perhaps? That is still achievable with keys and therefore a password-less connection.
Another option that you may be trying to explain is that the remote server does not accept SSH connections. Is that the case perhaps?
Can you clarify exactly what you have and what you need to achieve. Have you actually tried to run ssh-keygen? Did you get any output to screen or any files generated in sub-directory .ssh?
Hard-coding is always a bad idea. At worst, your code should read the values from a file that you can protect a bit further.
My designer has told not to use ssh-keygen as customer is not ok with that.
And it is good if we actually hard code.
Can u pls suggest how to hardcode that?
My code is like below
#!/bin/sh
ssh uname@ip_add
I thought it might be possible to do something like below like we do in sqlplus, but it doesnt work.
Short answer here is that ssh doesn't support any method of supplying a password on the command line.
You basically have two modes of operation A) public/private key pairs and passwordless authentication B) Password entered by a human at the keyboard.
expect uses kludges to trick ssh into thinking it is receiving input from a user.
If you could supply more about what you are trying to automate on the remote server using ssh we may be able to come up with some alternatives (cron jobs running on the remote server for example).