Suppose I've got a server foo.com which only allows keyboard-interactive authentication, and that I can't change this. This means I can do,
sshpass -p PASSWORD ssh foo.com
but I can't create public/private keys to log in without a password.
Now, I could just create an alias ssh_foo="sshpass -p PASSWORD ssh foo.com", but then I have to create aliases for scp, for sftp, and in general it won't work for any other programs that use these, e.g. graphical programs based on sftp which mount remote folders. So I'm looking for a more generic solution.
In particular, is there any way to set up my .ssh/config file to allow password-less login in this case? This should then work for everything. I feel like some clever combination of ProxyCommand and LocalCommand might do it, but I can't figure out what.
(Note, I do understand the security implication of this, I'm just curious if you can do it)
Have you attempted using expect? According to the documentation it "[Expect] is a tool for automating interactive applications such as telnet, ftp, passwd, fsck, rlogin, tip, etc."
The Wiki Page for except is also a very good resource for examples as the ones on the Expect page are broken.
You can also use plink which you can download and compile. You can use the -pw argument to automate this.
Related
So far with the ssh package in go I have been able to create some sort of client that will allow two forms of authentication. Either the user inputs a password or it will use keys to authenticate. This works great, however StrictHostKeyChecking may be causing an issue. Normally the first time you would SSH into a remote you'll be prompted with a message asking about the host authorization.
Is there anyway in Go to provide the user with that yes / no prompt or to disable StrictHostKeyChecking altogether?
They don't implement this for you, but you could provide HostKeyCallback in the ClientConfig struct passed to Dial. The function you provide should validate the hostname and host key against some known list and prompt the user if it doesn't match. The documentation says that the default is to accept all host keys, which is like setting StrictHostKeyChecking no in the ssh client config.
I would need some advice for those who want to help :
I have a linux server, and I want to provide an ssh (openssh) access to services like rsync, and sftp, for a specific user (extuser).
1) I'd like to restrict extuser to only process rsync or sftp, no other commands
2) extuser needs to read/write some specific directories, so I want to restrict what he can see and where he can write.
3) I'd read some about rbash or lshell, but i wanted to know if by "basic" configuration of openssh, without adding specific tools, i could manage it ?
Here is my reflexion (not very far, sorry)
For the 1) If i had only rsync to deal with, i've seen the rrsync script that is really helpfull :) But how to add the sftp restriction ? I've read about the "command=" in authorized_keygen and the use of variable SSH_ORIGINAL_COMMAND, but not sure if it is mainly dedicated for ssh command explicitely used (i.e ssh user#host "mycommand"), not for command that "internally" use ssh like rsync or sftp ?
For the 2), I think the chroot option for sftp will help
If you have any advices, remarks, are if you see i'm going in wrong way, i'd apreciate some returns :)
Thanks a lot :)
Ok, so it appears that the chroot can fullfill all the needs, since it's up to me to choose the commands i want to allow in the "chrooted" bin :)
So no commands restrictions by openssh configuration, but by chroot arborescence. And therefore i don't seem to need extra tools :)
What I would do is using Putty (or other solution) on Windows to connect to a SAN switch and get results from a command with ssh.
I use Powershell as scripting language and it could be done easily but i don't want to save the password in the script.
I'm looking for a solution to use Putty from command line and set the password not stored in clear in the script.
What I thought is to launch the script with \RUNAS (through a Scheduled task) and pass the actual credentials directly to Putty. (The switch would have the same password as the account used with the Runas). Is that possible?
Or is there any solution using putty with a certificate or something like this?
You may want to consider using key authentication as opposed to a password.
People will say use a password in addition to the key, but if your alternative is storing the password on your PC in a file anyway, someone with access to your machine owns you in either case.. So you just need to generate the keys. The requirement is: no-one but you has access to that key file.
http://www.linuxproblem.org/art_9.html
I'm in the same boat, have to use Windows, but for me www.mingw.org which gives you a shell, and the basic *nix tools - extremely useful for SSH, connect to remote Linux VPS, etc.. Cygwin, of course which is similar, and has an easier tool (setup.exe if I recall) to install new apps. I actually use git-bash with is mingw with git. No-GUIs. I've found this easy to just drop to the mingw shell when I need to use ssh openssl cut awk etc..
So running any remote command using SSH from the command line without third-party programs like Putty, or those with GUIs, etc.. Using the key authentication and offing password auth completely in ssh on the remote device (at least on devices where you have control) is some additional lockdown for the remote device, especially if you're the only one need access it.
Which leaves, scheduling the script. There should be a way to do that via batch file and Windows or within the command line environment.
I'll suggest following options:
use password authentication. Store the text file with password in a file with limited access (some service account) and launch your script under this account's credentials
same as above, but instead of text file use certificate file
write a small program (C#) which uses DPAPI to store the certificate or password in service account-specific store.
combine any of the above with the use of BitLocker/EFS
No options are can protect you from an attacker having admin access to the server, but implementing them will give an increasing (in order of number) headache to someone who will be trying to break it.
The script will be a weak spot in any case, though.
This is probably not the answer you're looking for, but I wouldn't use Putty for this, and would rather communicate with the SSH server directly using SSH.NET library. It's available in both source and binary form, and you could use it from PowerShell too if you like.
Examples: http://sshnet.codeplex.com/wikipage?title=Draft%20for%20Documentation%20page.
Then you'd have a lot of options to store your login credentials securely.
I recommend setting up 2-factor authentication on the ssh machine that you have to communicate with IF you can't use key authentication.
Google's 2 factor authentication can be implemented for ssh and is relatively easy to set up as long as SE linux is disabled...if it isn't disabled, you can add an exception and that would essentially help reduce the risk of compromise and increase security.
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.