restriction of ssh for a particular user

[madhuchakkaravarthy]

done ssh passwd less login for a user and its working fine and in the same machine i tried for another user,but ssh passwd less not working.

is there any restriction for a particular user .

regards

MC

[Steven Schweda]

> [...] i tried for another user, [...]

Not a very detailed description of what you
did.

> [...] but ssh passwd less not working.

Not a very detailed description of what
happened when you did it.

As usual, showing actual commands with their
actual output can be more helpful than vague
descriptions or interpretations. You might
begin with some basic information:

uname -a
ssh -V

As a look through old SSH-related Forum
threads would show, the usual first step is
to add "-v" (or "-vv", or "-vvv", ...) to
your "ssh" command, and then not keep the
results a secret.

Common problems include bad file permissions
and/or ownership on or under the user's home
directory. With approximately no useful
information, detailed guessing would probably
not be productive.

[madhuchakkaravarthy]

hi

permission for .ssh is 700 and for authorized_keys 600.

generated key by ssh-keygen -t rsa.

output 0f ssh -v



OpenSSH_4.7p1+sftpfilecontrol-v1.2-hpn12v17, OpenSSL 0.9.7m 23 Feb 2007
HP-UX Secure Shell-A.04.70.023, HP-UX Secure Shell version
debug1: Reading configuration data /opt/ssh/etc/ssh_config

debug1: Connecting to 10.59.118.47 [10.59.118.47] port 22.

debug1: Connection established.

debug1: identity file /home/ftadm/.ssh/id_rsa type 1

debug1: identity file /home/ftadm/.ssh/id_dsa type -1

debug1: Remote protocol version 2.0, remote software version OpenSSH_4.7p1+sftpfilecontrol-v1.2-hpn12v17

debug1: match: OpenSSH_4.7p1+sftpfilecontrol-v1.2-hpn12v17 pat OpenSSH*

debug1: Enabling compatibility mode for protocol 2.0

debug1: Local version string SSH-2.0-OpenSSH_4.7p1+sftpfilecontrol-v1.2-hpn12v17

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

The authenticity of host '10.59.118.47 (10.59.118.47)' can't be established.
RSA key fingerprint is 7b:28:1f:63:8a:4a:72:d0:f7:a1:31:ec:cc:59:47:e2.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '10.59.118.47' (RSA) to the list of known hosts.

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,keyboard-interactive

debug1: Next authentication method: publickey

debug1: Offering public key: /home/ftadm/.ssh/id_rsa

debug1: Authentications that can continue: publickey,password,keyboard-interactive

debug1: Trying private key: /home/ftadm/.ssh/id_dsa

debug1: Next authentication method: keyboard-interactive

Password:

and its asking for password

regards

MC

[madhuchakkaravarthy]

hi

shell used for the user is /usr/bin/ksh

regards

MC

[Steven Schweda]

> permission for .ssh is 700 and for
> authorized_keys 600.

I'm sorry. Which part of this was unclear?:

> As usual, showing actual commands with their
> actual output can be more helpful than vague
> descriptions or interpretations.

> uname -a

With my weak psychic powers, I can't tell
which ".ssh" or "authorized_keys" you're
looking at, or who owns them. Actual "ls -l"
output might be more helpful, if I also knew
on which system you were running the
command(s).


> generated key by ssh-keygen -t rsa.

Same complaint. Also, I don't know what (if
anything) you copied, how, from where to
where.


[...]
debug1: Offering public key: /home/ftadm/.ssh/id_rsa

debug1: Authentications that can continue: publickey,password,keyboard-interactive

debug1: Trying private key: /home/ftadm/.ssh/id_dsa

debug1: Next authentication method: keyboard-interactive
[...]

Apparently, the server doesn't like your
keys. You might find some useful info in the
server's log file.


> shell used for the user is /usr/bin/ksh

The user's shell (on either system) should
not be important.

[Kenan Erdey]

Hi,

please look at the my post in this thread.

http://h30499.www3.hp.com/t5/System-Administration/ssh-public/m-p/4754656#M388547

[Doug O'Leary]

Hey;

As people have already stated, if a particular user is having problems logging in via ssh, it's probably due to ownership or permissions of their home directory, their ~/.ssh directory and/or their ~/.ssh/authorized_keys or ~/.ssh/id_dsa key file.  

run a "tail -f /var/adm/syslog/syslog.log" while the user is attempting to log in; ssh is usually very good about logging why it's not letting someone in.

From the deepest:

~/.ssh/id_dsa must be 600 permissions.

~/.ssh/authorized_keys no more open than 644

~/.ssh must be 700 permissions

~ can't be more open than 755

/home (assuming ${HOME} is below that directory) can't be more open than 755

Those are the first things to check and account for ~90% of the issues that individual users will have logging in via ssh/pka.

Doug O'Leary

[Michael Steele_2]

HI

There are two places to look first before worrying about permissions which are handled by the system during installation:  The known_host file and the authorized_keys file.

a)  Many people make the mistake of verifying the known_hosts file on the destination server when you should be checking the known_hosts file on the source server.

b) If you are working with servers that have been around along time then sometimes their ip addresses change but their hostnames remain the same.  Verify the ips in the known_hosts file even if listed by hostnames.