I'm trying to help someone with their Debian server.
They have Plesk. I made myself an user with Plesk and enabled SSH access.
I can log on ... but only for one second. I see the MOTD, I see a Debian disclaimer, then I'm logged out again. "Connection closed".
The only thing I could think to try is to change the shell settings, Plesk has a dropdown list of bash, csh, tcsh and so on next to the "allow ssh using:" option. But none of them works.
Any ideas gratefully received.
The way I fixed this problem is, unfortunately, to manually change the last parameter in /etc/passwd for users I want to give shell access. It is /bin/bash instead of /bin/false.
Plesk can get a bit quirky sometimes...
That behavior is similar to the one you get when a user account has a 'nologin' shell selected on the Plesk config. I would do some things:
Connect using ssh with the verbose option activated (ssh -v user#host) so you can get more detail.
Check the /etc/passwd file, look for your user and check that, the final field on that line, is pointing to a valid shell (something like /bin/bash instead of /bin/nologin or /bin/false).
Check also in that line that the home directory for that user ( that's configured on the field before of the shell ), is valid, exists, and has proper permissions and owner
Finally, check your logs (in /var/log; I think I would check syslog, messages and user), so maybe you can get any meaningful message.
When a user logs on, the shell takes them to their user directory and possibly runs a "startup" script.
Is the user directory on the local machine? Does it have to be mounted from a fileshare (this has happened to me on more than one occasion)? If that fileshare is not mounted you will get disconnected.
Take a look at the startup scripts for those shells. Bash uses various startup scripts depending on the circumstance, these include /etc/profile and ~/.bashrc. These scripts sometimes do wacky things that may disconnect you for any number of reasons.
Related
In Linux, need to write a shell script which can be ran as other users (via doas permissions for this one script), but I need to know in the script who ran it originally. How would I go about doing this?
From the man page
By default, a new environment is created. The variables HOME, LOGNAME, PATH, SHELL, and USER and the umask(2) are set to values appropriate for the target user. DOAS_USER is set to the name of the user executing doas.
So use $DOAS_USER to get the original username.
I have just got an account to access a remote server(not root), and I was trying to replace the default bash with zsh.
Then awkward thing happened, I wrote something like exec zsh in bashrc, hoping that it can replace bash with zsh everytime I log in. However, I mistakenly misspelled the path of zsh, now every time I want to ssh my server, it will say .bashrc: line 28: exec: zsh: not found and end the session, I cannot log in my account anymore...
Is there a way to fix it without bothering the administrator? Because it's weekend and I need to use the remote server...
Thanks everyone!
Use sftp to rename the file. This will work so long as sshd is configured to use its internal sftp server implementation, as opposed to an external subsystem.
Marked community wiki as this is a known-off-topic question (not being "unique to software development"; in the future, questions about interacting with a UNIX system as an end-user, as opposed to writing software for same, should be asked at Unix & Linux StackExchange or SuperUser, not StackOverflow.
In our cluster with PBS batch system (torque) installed, we want all the users to execute their jobs by qsub so that the CPU resources can be well managed. However, we found that users in our cluster can still run their programs directly in their bash shell.
I have noticed that some other cluster systems have restricted users from running their own binary. Their command prompt is different from full privileged command prompt.(starting from ~>)
qczhan2#barrine1:~>echo $0
-bash
In their configuration, users can run basic commands, like ls, pwd, cp, and 'cd' to system folders, but when users run their own binary, the system states "permission not allowed." It is also necessary to mention that if one tries to call user-owned binary using any mpi command, it is also not allowed either.
For example:
qczhan2#barrine1:~>mpiexec -n 64 ./abc.out
permission denied
where abc.out is a user-defined binary file.
I am just wondering how to configure the system to be like that?
You want to change the default shell for all your users from /bin/bash to:
/bin/bash -r
so their shell becomes a restricted shell. Amonst other restriction the users are not allowed to cd, set or unset PATH or issue commands containing /. This locks them into only running commands you give them access to.
If you use Linux: mount filesystems where users have write permission (e.g. /home, /tmp, /var/tmp, /dev/shm) with option "noexec".
I need to execute a command which is needed to run as root.
I read some post about using hard-coded passwords in scripts could be insecure, but actually I don't care because I'm providing root password to users anyway. It's an stripped system and there's only 2 users: client and root, so avoid warning me about security issues, Go ahead and give a quick and dirty solution.
For this bash script I need to
get as superuser using su,
then "my command",
and then logout.
I don't want the terminal prompt to type the password myself, instead read the password that I'm providing somewhere in script and run the command. It's a priority to not prompt any input by user.
Alternatively, maybe I could install sudo, but is there any chance to run a command without any prompt of password (editing sudoers or something)?
What about of using expect?
Update: I forgot to say that is also a portable SO, used for USB sticks (maybe later for CDLive too), as you know, in some distros of this kind is provided a root password if users needed. The command mentioned before is a package extensions for some application install, and only root have privilegies to execute such command (I have to say it's not a apt-get install or rpm command, so don't worry about this).
If you want a command to be runnable with no password, set that specific command as runnable with no password in your /etc/sudoers file (limiting the arguments to only the specific ones you wish to allow, if your use case allows that limitation).
This is as simple as setting the NOPASSWD: flag for the relevant sudoers entry.
If you really, really don't care about security, it could be as simple as this:
%admin ALL=(ALL) NOPASSWD: ALL
(after putting sudo-capable users in the admin UNIX group)
...or, if you did care, you could do something specific:
someuser ALL = NOPASSWD: /usr/local/sbin/my_admin_command
Note that if these commands will be run with no user present, they also may not have a TTY assigned; in such a case, you must be sure that your sudoers file doesn't contain the (oft-present-by-default) line:
Defaults requiretty
...or that the effect of this default is being specifically discarded by the line granting permissions.
I would like to know if there is a (simple) solution to the following issue:
When I log in with ssh to a specific host, I would like to automatically execute a (bash)script on that host. This way I could -for example- load my aliases on that host.
Definitively the bashrc script is not executed; The ssh configuration files do not seem to help in this issue either.
Any suggestions?
Thanks in advance!
BTW: The host is running on Gentoo
If .bashrc isn't being run, try .profile, which has a similar function. Different shells use different startup scripts at different times, so knowing when to run things is useful.
On many systems where you have a choice of which shell to use, you are put through ~/.profile only. This way there is no need to find out (and no probably wrong guessing) which shell you're running in and which profile to actually load (.bashrc, .cshrc, .kshrc etc.) and which ones to avoid loading.
The easiest solution in your case would be to create a link (a symbolic one if you prefer visibility) to your favourite shell's startup script as in ln -s ~/.bashrc ~/.profile. If you don't intend to ever using anything other than bash, you're set.