unRAID OS Version:

6.0-beta8

 

Description:

Connection closes when I telnet to the unRAID server and log in as my non-root account

 

How to reproduce:

1.) Telnet to tower

2.) Enter non-root account name and password

 

Expected results:

A shell prompt

 

Actual results:

Putty has an error message stating the connection was closed.

 

 

Other information:

I don't recall this occurring in 6.0-beta7

I can telnet in and log in as root fine.  I get a shell prompt.

 

Syslog entries:

Sep  2 07:09:44 Tower kernel: md: correcting parity, sector=5274551120

Sep  2 09:36:25 Tower in.telnetd[14366]: connect from 192.168.1.48 (192.168.1.48)

Sep  2 09:36:56 Tower in.telnetd[14368]: connect from 192.168.1.48 (192.168.1.48)

Sep  2 09:36:58 Tower login[14369]: ROOT LOGIN  on '/dev/pts/0' from '192.168.1.48'

Sep  2 09:41:18 Tower in.telnetd[14381]: connect from 192.168.1.48 (192.168.1.48)

Sep  2 09:41:40 Tower in.telnetd[14383]: connect from 192.168.1

It works OK for me!

 

Have you checked (in /etc/passwd) that the user you are trying to use is allowed to run a shell (It should have /bin/bash at the end of the line defining the user).  If it has /bin/false that would explain what you are seeing.

This is by design.  There are no "user accounts" in unRaid.

 

itimpi- not sure what you did to make it work, but it shouldn't work

This is by design.  There are no "user accounts" in unRaid.

 

itimpi- not sure what you did to make it work, but it shouldn't work

I 'forced' it by editing the /etc/passwd file to prove that it IS possible if you know what you are doing   I thought that I could see by looking t the /etc/passwd file that it would normally not work without this level of 'hackery'.  I have set it back to default having done the test.

This is by design.  There are no "user accounts" in unRaid.

 

itimpi- not sure what you did to make it work, but it shouldn't work

I 'forced' it by editing the /etc/passwd file to prove that it IS possible if you know what you are doing   I thought that I could see by looking t the /etc/passwd file that it would normally not work without this level of 'hackery'.  I have set it back to default having done the test.

 

I did exactly what itimpi did to enable a user account to access via ssh.  After making an samba user, I edited the /etc/passwd file to enable /bin/bash (and thereby ssh):  Here are some of my accounts from that file (edited some):

 

nobody:x:99:100:nobody:/:/bin/false
media:x:1001:100:shared media:/mnt/user/Media:/bin/false
lurch:x:1005:100::/mnt/user/Media:/bin/bash

 

Note that the default samba user (media) has its shell set to /bin/false (akin to /dev/null, I suppose), while the user 'lurch' has a shell.

The colons delimit account features, I'm not sure I recall them all:

accountname:?:Usernumber:group:?:default/path:shell

 

I thought I'd have to reload this on boot via the go script, but it persists through upgrade and reboot.

 

I recognize that lurch could run amok with shell access, but given who has this account I'm not worried and it has has solved some problems for me.  If there's another means of allowing ssh access without /bin/bash that would be better.

 

D

 

 

 

I recognize that lurch could run amok with shell access, but given who has this account I'm not worried and it has has solved some problems for me.  If there's another means of allowing ssh access without /bin/bash that would be better.

You can specify any program to be run on the user login - it does not have to be /bin/bash.    However not sure what you think you might want to run if it is not the standard shell.