Which shell do you use?

I just tested again and can login to toor over ssh even without it having no shell configured in passwd. It uses csh. So it seems a misunderstanding here, it blocks su but not direct ssh login. So regardless of this, someone can setup an alternative shell for root and then enable the toor account for su. Still not a disaster to change root's shell.

Code: 
Jan 21 09:38:36 vm1 sshd[81144]: Accepted publickey for toor from 192.168.1.124 port 54316 ssh2

Code: 
# id
uid=0(root) gid=0(wheel) groups=0(wheel)

Code: 
# grep toor /etc/passwd
toor:*:0:0:Bourne-again Superuser:/root:
 
chrcol said:
I just tested again and can login to toor over ssh even without it having no shell configured in passwd. It uses csh. So it seems a misunderstanding here, it blocks su but not direct ssh login. So regardless of this, someone can setup an alternative shell for root and then enable the toor account for su. Still not a disaster to change root's shell.

Code: 
Jan 21 09:38:36 vm1 sshd[81144]: Accepted publickey for toor from 192.168.1.124 port 54316 ssh2

Code: 
# id
uid=0(root) gid=0(wheel) groups=0(wheel)

Code: 
# grep toor /etc/passwd
toor:*:0:0:Bourne-again Superuser:/root:
Click to expand...

Obviously by this point you're trolling at this point disseminating incomplete information to further your position. I encourage anyone who is actually interested in changing their shell to "verify" these statements before they proceed. You will find a different scenario than the one quoted above. ssh via pam authenticates against /etc/master.passwd. The only default scenario where ssh can bypass a disabled account is using ssh keys or some other type of authentication like openldap/NIS. If you have bypassed normal authentication paths in order to make toor work, that does invalidate your point about toor being accessible remotely by default. You did need to do extra steps prior to a bash login issue in order to resolve it.

Also as mentioned before, enabling a UID 0 user for remote login is generally not considered safe. It's somewhat more debatable if you're using keys and such, but even then it's another attack vector. The standard sshd config file doesn't allow root logins for a reason. This is also the policy of many companies so you may not have a choice in the matter.
 
will you stop calling me a troll I find it offensive.

the fact is this.

I use key login, I allow key login for root over ssh (but not password), and that allows me to login as toor using my key over ssh without modifying the toor account.

What is so incomplete about it? I dont call people trolls who disagree with me.
 
Stop the bickering, or you'll both get to know the /sbin/nologin shell! (:p)
 
bash :f
- since it's works flawlessly right out of the box on the Linux distro's I'm running, I use it on BSD's as well (for uniformity). And I really don't notice any difference speed-wise.. guessing I'm the bottle neck in the interaction hehe.
 
Bra1n0v3rfl0w said:
... and page 4 of this thread (January 5th, 2011, 22:53), by UNIXgod: reference to chapter 7.10 FAQbook.
Click to expand...

You have immortalized me!!!! =)

I'll quote it for all to see:
7.10. Why is /bin/sh so minimal? Why does FreeBSD not use bash or another shell?

Because POSIX® says that there shall be such a shell.

The more complicated answer: many people need to write shell scripts which will be portable across many systems. That is why POSIX specifies the shell and utility commands in great detail. Most scripts are written in Bourne shell, and because several important programming interfaces (make()(1), system()(3), popen()(3), and analogues in higher-level scripting languages like Perl and Tcl) are specified to use the Bourne shell to interpret commands. Because the Bourne shell is so often and widely used, it is important for it to be quick to start, be deterministic in its behavior, and have a small memory footprint.

The existing implementation is our best effort at meeting as many of these requirements simultaneously as we can. In order to keep /bin/sh small, we have not provided many of the convenience features that other shells have. That is why the Ports Collection includes more featureful shells like bash, scsh, tcsh, and zsh. (You can compare for yourself the memory utilization of all these shells by looking at the “VSZ” and “RSS” columns in a ps -u listing.)
Click to expand...

Here is a clean link to Csh Programming Considered Harmful
 
Galactic_Dominator said:
Also as mentioned before, enabling a UID 0 user for remote login is generally not considered safe. It's somewhat more debatable if you're using keys and such, but even then it's another attack vector. The standard sshd config file doesn't allow root logins for a reason. This is also the policy of many companies so you may not have a choice in the matter.
Click to expand...

This is not really true. There is not a significant benefit to logging in as a user, and using programs to escalate privileges. The problem becomes one of root equivalency. Indeed, the only consideration is that "root" is a known account name, if you were using password authentication. If a malicious party were able to capture credentials to login on a UID 0 account, then that is equal to an account that is able escalate its privileges. In particular, there have been several issues with sudo(8), and using su(1) to increase privileges (or, at all with a TTY, as opposed to a command) is not great. I suggest you search for Solar Designer's postings on the issues, if you are not aware of why this is the case.

To clarify, what I mean to say is: logging in as UID 0 is as safe as logging in as any account that can become UID 0; you should be using keys, not passwords, for any privileged account -- including accounts that can escalate privileges; the standard sshd configuration doesn't allow root logins primarily because it supports password authentication, and the root password may not have been correctly set by the time SSH is running; the policy of companies is related to accountability, not security per se (in fact, that is what sudo(8) is pretty good for: accountability).

That out of the way: I have tended to always use ksh, as I quite often use commands that would create a small script, and the syntax of csh is alien to me. For standard program invocation, and minor file manipulation, I found that FreeBSD's tcsh was actually quite nice (after using some tips from this bulletin board); I don't think I would swap to using it full time, though.
 
You must log in or register to reply here.
Back
Top