Hi all,
I got a preconfigured Debian 4 (etch) box. When I add a user, it tells me it added and I can "su" as a new user but I can't login with it through SSH, SFTP, etc.
Why?
Thanks for your help.
What error do you get? You should set the password for your new user before you try to connect via ssh etc.
Creating user:
root@somewhere:~# adduser tt --no-create-home
Adding user `tt' ...
Adding new group `tt' (1011) ...
Adding new user `tt' (1000) with group `tt' ...
Not creating home directory `/home/tt'.
New UNIX password:
Retype new UNIX password:
passwd: password updated successfully
Changing the user information for tt
Enter the new value, or press ENTER for the default
Full Name []:
Room Number []:
Work Phone []:
Home Phone []:
Other []:
Is the information correct? [y/N] y
root@somewhere:~# su tt
tt@somewhere:/root$
But when I use putty to login via SSH, after entering the password, suddenly:
The lack of a home directory would seem like a plausible explanation.
No, the system has some users without home directory and I can login with them without any problem.
I think some where must be a configuration to allow/disallow users to login but I don't know "where".
Try it with "useradd" instead of adduser, just to see if there is a difference.
userdel tt
mkdir -p /home/tt
useradd -d /home/tt tt
passwd tt
If this still does not work, check if some more info is in you /var/log/messages. Or try if you can get in via another service like ftp to see if it is a ssh problem or not.
Didn't work and there was no info in /var/log/messages. I tried the SFTP and it also said:
"Server unexpectedly closed network connection."
Firewall? PAM?
Both is enabled but I've local account enabled and I think there is no restriction in firewall for new added users. (How can I check it?)
I meant ftp not sftp since sftp is handeled by the same daemon like ssh, the sshd. ftpd is a different daemon.
FTP daemon is not enabled on this server and I want do so. (Because of security issues)
Can you ssh tt@localhost? I'm not capable of telling you what or how to troubleshoot PAM but PAM being enabled is, to me, a possible problem, not a solution. (PAM is wonderful if correctly configured and all that, but it's complex.)
Result: (not woriking)
root@somewhere:~# ssh tt@localhost -p 2222
tt@localhost's password:
Connection closed by 127.0.0.1
(My SSH listens on port 2222 not on 22)
That pretty much rules out firewalls as an issue. Can't really come up with anything more to investigate, except maybe try with ssh -v and if possible, running the sshd server process with verbose debugging enabled as well.
Just tested a failed ssh login on my Debian box:
It writes into /var/log/auth.log:
Aug 14 14:21:46 isau02 sshd[26012]: (pam_unix) authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=wsvu2388 user=tester
Aug 14 14:21:48 isau02 sshd[26012]: Failed password for tester from 10.xx.xx.xx port 1769 ssh2
Aug 14 14:21:49 isau02 sshd[26012]: Accepted password for tester from 10.xx.xx.xx port 1769 ssh2
Aug 14 14:21:49 isau02 sshd[26014]: (pam_unix) session opened for user tester by (uid=0)
Aug 14 14:21:51 isau02 sshd[26014]: (pam_unix) session closed for user tester
Maybe you check if you can find something helpful with:
find /var -type f -exec grep -l " tt " {} \;
Command:
root@somewhere:~# ssh -v tt@localhost -p 2222
Result:
OpenSSH_4.3p2 Debian-9etch2, OpenSSL 0.9.8c 05 Sep 2006
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to localhost [127.0.0.1] port 2222.
debug1: Connection established.
debug1: permanently_set_uid: 0/0
debug1: identity file /root/.ssh/identity type -1
debug1: identity file /root/.ssh/id_rsa type -1
debug1: identity file /root/.ssh/id_dsa type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_4.3p2 Debian-9etch2
debug1: match: OpenSSH_4.3p2 Debian-9etch2 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_4.3p2 Debian-9etch2
debug1: An invalid name was supplied
Configuration file does not specify default realm
debug1: An invalid name was supplied
A parameter was malformed
Validation error
debug1: An invalid name was supplied
Configuration file does not specify default realm
debug1: An invalid name was supplied
A parameter was malformed
Validation error
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-cbc hmac-md5 none
debug1: kex: client->server aes128-cbc hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host 'localhost' is known and matches the RSA host key.
debug1: Found key in /root/.ssh/known_hosts:3
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Trying private key: /root/.ssh/identity
debug1: Trying private key: /root/.ssh/id_rsa
debug1: read PEM private key done: type RSA
debug1: Authentications that can continue: publickey,password
debug1: Trying private key: /root/.ssh/id_dsa
debug1: Next authentication method: password
tt@localhost's password:
Connection closed by 127.0.0.1
There is some info in /var/log/auth.log about the new user "tt":
Aug 14 16:42:39 somewhere passwd[18923]: (pam_unix) password changed for tt
Aug 14 16:42:39 somewhere passwd[18923]: (pam_unix) Password for tt was changed
Aug 14 16:42:44 somewhere pam_access[18928]: access denied for user `tt' from `localhost'
Aug 14 16:42:44 somewhere sshd[18928]: Failed password for tt from 127.0.0.1 port 40627 ssh2
Aha... take a very simple password like 1234 and try again or just write the password where you enter the username to see what you type. And check if you caps lock isn't active just at this time 
The "invalid name" and "invalid parameter" errors are definitely not routine. See if you can figure out what causes them. I'd guess there's a syntax error in your sshd or PAM config. (Or does "realm" here refer to Kerberos maybe?)
No man! I'm sure that I've entered the password correctly.
I tried the "ssh -v" to verbose a working account. It also showed that error. So the problem isn't related to that.