Plink error - "unix shell commands cannot be executed using this account" [closed] - plink

Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 9 years ago.
Improve this question
I'm trying to run plink.exe to execute a command on a remote UNIX machine.
When logging in using Putty, my command is executed successfully. My problem is when using the same credentials (same user and password) to execute the same command exactly with plink.
I keep getting a message "UNIX shell commands cannot be executed using this account".
I get the same message for every command I type in.
The syntax I'm using to run the command is this :
C:>plink.exe -pw PASSWORD -m FILENAME USER#REMOTEHOST
I also tried typing it differently, for example:
C:>plink.exe -l USER -pw PASSWORD -ssh REMOTEMACHINE -m FILENAME
but the result is always the same.
I am using a user with Admin capabilities.
I'll be glad to get any assistance.

I think the issue has to do with interactive vs. non-interactive modes. When you login with putty or you call plink without specifying a command, then you are in interactive mode.
However, if you specify a command, or a file with a list of commands, then the remote shell will treat your login as non-interactive, and apparently reject your connection.
I'm not exactly sure how the remote decides to treat your login as interactive or not. I would suggest to try one of these options:
Put your commands in a script.sh shell script and copy it to the remote server, and run it like this:
C:>plink.exe -pw PASSWORD USER#REMOTEHOST "bash /path/to/remote/script.sh"
If you don't want to put the script on the remote server, you can try to redirect local input to the remote bash, but I'm not sure this works in Windows:
C:>plink.exe -pw PASSWORD USER#REMOTEHOST bash < C:\path\to\local\script.sh
In both suggestions the hope is that by sticking bash there, your shell will be treated as interactive.

Related

Solaris/Unix password change in-line

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

Copying files from server to local computer using SSH [closed]

Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 7 years ago.
Improve this question
I am having trouble copying files from a remote server using SSH. Using PuTTY I log in to the server using SSH. Once I find the file I would like to copy over to my computer, I use the command:
scp username#host.com:/dir/of/file.txt \local\dir\
It looks like it was successful, but it only ends up creating a new folder labeled 'localdir' in the remote directory /dir/of/.
How can I copy the file to my local computer over SSH?
It depends on what your local OS is.
If your local OS is Unix-like, then try:
scp username#remoteHost:/remote/dir/file.txt /local/dir/
If your local OS is Windows ,then you should use pscp.exe utility.
For example, below command will download file.txt from remote to D: disk of local machine.
pscp.exe username#remoteHost:/remote/dir/file.txt d:\
It seems your Local OS is Unix, so try the former one.
For those who don't know what pscp.exe is and don't know where it is, you can always go to putty official website to download it. And then open a CMD prompt, go to the pscp.exe directory where you put it. Then execute the command as provided above
EDIT
if you are using Windows OS above Windows 10, then you can use scp directly from its terminal, just like how Unix-like OS does.
Thanks to #gijswijs #jaunt #icanfathom
Your question is a bit confusing, but I am assuming - you are first doing 'ssh' to find out which files or rather specifically directories are there and then again on your local computer, you are trying to scp 'all' files in that directory to local path. you should simply do scp -r.
So here in your case it'd be something like
local> scp -r username#host.com:/path/to/dir local/path
If youare using some other executable that provides 'scp like functionality', refer to it's manual for recursively copying files.
You need to name the file in both directory paths.
scp username#host.com:/dir/of/file.txt \local\dir\file.txt
Make sure the scp command is available on both sides - both on the
client and on the server.
BOTH Server and Client, otherwise you will encounter this kind of (weird)error message on your client: scp: command not found or something similar even though though you have it all configured locally.
that scp command must be issued on the local command-line, for putty the command is pscp.
C:\something> pscp username#host.com:/dir/of/file.txt \local\dir\

What is the difference between bin/sh, bin/bash, sbin/nologin, bin/tcsh, etc? [closed]

Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 9 years ago.
Improve this question
I am new to linux so please go easy and talk slow =)
In Plesk I have some options for accessing the server over SSH. I just want to connect, add my public key and run rsync for backup.
What is the difference between these options?
Which option should I choose?
What are these? They look like directories to me.
Access to the server over SSH:
/bin/sh
/bin/bash
/sbin/nologin
/bin/tcsh
/bin/csh
/bin/ksh
/bin/bash (chrooted)
/bin/rbash
Here is an image of the Plesk control panel:
Use /bin/bash
What are these? They look like directories to me.
These are different options for default shell given to users who connect via SSH
If you haven't used any of these shells before, I think bash is the best option for you. Most tutorials and articles for linux commands online assume you are using bash.
However, you have two options for bash: /bin/bash and /bin/bash (chrooted).
To do backups, you will probably need the bash to have full access to execute all commands.
I'm not sure whether you can get what you want done with a chrooted bash.
Basically, chrooted bash is for avoiding mishaps.
To know more about chrooting, you can read this article
Most of options are various Unix shells. A shell is basically what interprets the text that you type in the window. Some people prefer one shell over others. If you are not familiar with any shell in particular, pick one based on your needs Comparison Chart
If you don't know, you should use /bin/bash. It's the most popular, and will be the easiest for you to get help using. That said, they all do the same thing, just in slightly different ways.

automatic ssh session when moving to mapped sshfs [closed]

Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 11 years ago.
Improve this question
If you have a network drive mapped via sshfs, is there a way to automatically log on via ssh whenever changing to that directory?
$USER:$LOCALHOST:~: sshfs $USER:$REMOTEHOST /Volumes/dev0
$USER:$LOCALHOST:~: cd /Volumes/dev0
$USER:$REMOTEHOST:~
Thomas Jansson provides a guide on integrating sshfs with autofs. I'll summarize his guide here, so this answer will still be worth something if his site ever goes offline:
Create an /etc/auto.master:
/mnt/sshfs /etc/auto.sshfs uid=1000,gid=1000,--timeout=30,--ghost
Make sure your uid and gid match your userid and guid in /etc/passwd or whatever you use to provide system accounts.
Now add lines into /etc/auto.sshfs, one per desired filesystem, in the following form:
bar -fstype=fuse,rw,nodev,nonempty,noatime,allow_other,max_read=65536 :sshfs\#tjansson#bar.com\:
Be sure to change tjansson#bar.com to whatever user account and hostname you're going to be using. Change the leading bar to whatever you'd like the directory to be named. When you cd /mnt/sshfs/bar, autofs will automatically mount the FUSE filesystem for you. Of course, using SSH keys and the ssh-agent(1) will make this far more pleasant.
Update
... create a directory that literally logs you into the other machine.
Hey, that's pretty clever idea. You could either write a shell function that checks the directory name you want to cd into and start a new ssh for you. Maybe you can (ab)use the PROMPT_COMMAND variable to ssh to the host if the directory name matches. Be warned that either approach will slow down your normal cd or every prompt display.
Another approach that I've used and enjoyed is a small little helper script, ~/bin/ssh-to:
#!/bin/bash
hostname=`basename $0`
ssh $hostname $*
Symlink new names to this shell script: ln -s ssh-to sarnold.org and then you can run a command or log in on a remote site without typing the ssh all the time:
sarnold.org python foo.py
It'll log you in to whatever machine you've used for the name of the symbolic link and run whatever command you give it.

Limit SSH - bash with no commands

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.