HPE GreenLake Administration
- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - HP-UX
- >
- Re: Public Key Authentication Failing with Secure ...
Operating System - HP-UX
1833775
Members
3467
Online
110063
Solutions
Forums
Categories
Company
Local Language
back
Forums
Discussions
Forums
- Data Protection and Retention
- Entry Storage Systems
- Legacy
- Midrange and Enterprise Storage
- Storage Networking
- HPE Nimble Storage
Discussions
Forums
Discussions
Discussions
Discussions
Forums
Discussions
back
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
- BladeSystem Infrastructure and Application Solutions
- Appliance Servers
- Alpha Servers
- BackOffice Products
- Internet Products
- HPE 9000 and HPE e3000 Servers
- Networking
- Netservers
- Secure OS Software for Linux
- Server Management (Insight Manager 7)
- Windows Server 2003
- Operating System - Tru64 Unix
- ProLiant Deployment and Provisioning
- Linux-Based Community / Regional
- Microsoft System Center Integration
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Blogs
Information
Community
Resources
Community Language
Language
Forums
Blogs
Go to solution
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
05-13-2003 05:42 AM
05-13-2003 05:42 AM
I have installed Secure Shell 3.50 from the HP depot(T147...). I have some of the symptoms listed in the earlier post about problems with that download, but not all of them.
If I run sum against the depot, I get 33086. If I run getconf KERNEL_BITS, I get 64. /sbin/init.d/secsh start works fine.
I transferred *.pub files from each of my 2 test systems to the other test system and copied them into authorized_keys. I ran cksum on the *.pub files before and after each transfer and they matched.
Everything seems to work except the public key authorization. Finally I get prompted for my password and that works.
Unfortunately, I want to use public key authentication.
Below are the permissions and files in my .ssh directory,
-rw-rw-r-- me my_group authorized_keys
-rw-r--r-- me my_group id_dsa.pub
-rw-r--r-- me my_group id_rsa.pub
-rw------- me my_group id_dsa
-rw------- me my_group id_rsa
-rw-r--r-- me my_group known_hosts
-rw------- me my_group prng_seed
Below is the output from trying to connect from test_1 to test_2:
(test_1:cblake)/home/cblake/.ssh [28]$ ssh -v test_2
OpenSSH_3.5p1, SSH protocols 1.5/2.0, OpenSSL 0x0090609f
29630: debug1: Reading configuration data /opt/ssh/etc/ssh_config
29630: debug1: Rhosts Authentication disabled, originating port will not be trusted.
29630: debug1: ssh_connect: needpriv 0
29630: debug1: Connecting to world [172.27.193.42] port 22.
29630: debug1: Connection established.
29630: debug1: identity file /home/cblake/.ssh/id_rsa type -1
29630: debug1: identity file /home/cblake/.ssh/id_dsa type -1
29630: debug1: Remote protocol version 2.0, remote software version OpenSSH_3.5p1
29630: debug1: match: OpenSSH_3.5p1 pat OpenSSH*
29630: debug1: Enabling compatibility mode for protocol 2.0
29630: debug1: Local version string SSH-2.0-OpenSSH_3.5p1
29630: debug1: SSH2_MSG_KEXINIT sent
29630: debug1: SSH2_MSG_KEXINIT received
29630: debug1: kex: server->client aes128-cbc hmac-md5 none
29630: debug1: kex: client->server aes128-cbc hmac-md5 none
29630: debug1: SSH2_MSG_KEX_DH_GEX_REQUEST sent
29630: debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
29630: debug1: dh_gen_key: priv key bits set: 127/256
29630: debug1: bits set: 1603/3191
29630: debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
29630: debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
29630: debug1: Host 'world' is known and matches the RSA host key.
29630: debug1: Found key in /home/cblake/.ssh/known_hosts:1
29630: debug1: bits set: 1579/3191
29630: debug1: ssh_rsa_verify: signature correct
29630: debug1: kex_derive_keys
29630: debug1: newkeys: mode 1
29630: debug1: SSH2_MSG_NEWKEYS sent
29630: debug1: waiting for SSH2_MSG_NEWKEYS
29630: debug1: newkeys: mode 0
29630: debug1: SSH2_MSG_NEWKEYS received
29630: debug1: done: ssh_kex2.
29630: debug1: send SSH2_MSG_SERVICE_REQUEST
29630: debug1: service_accept: ssh-userauth
29630: debug1: got SSH2_MSG_SERVICE_ACCEPT
29630: debug1: authentications that can continue: publickey,password,keyboard-interactive
29630: debug1: next auth method to try is publickey
29630: debug1: try privkey: /home/cblake/.ssh/id_rsa
29630: debug1: read PEM private key done: type RSA
29630: debug1: authentications that can continue: publickey,password,keyboard-interactive
29630: debug1: try privkey: /home/cblake/.ssh/id_dsa
29630: debug1: read PEM private key done: type DSA
29630: debug1: authentications that can continue: publickey,password,keyboard-interactive
29630: debug1: next auth method to try is keyboard-interactive
29630: debug1: authentications that can continue: publickey,password,keyboard-interactive
29630: debug1: next auth method to try is password
cblake@test_2's password:
29630: debug1: ssh-userauth2 successful: method password
What am I doing wrong? Is it the problem with the depot?
Coleman Blake
If I run sum against the depot, I get 33086. If I run getconf KERNEL_BITS, I get 64. /sbin/init.d/secsh start works fine.
I transferred *.pub files from each of my 2 test systems to the other test system and copied them into authorized_keys. I ran cksum on the *.pub files before and after each transfer and they matched.
Everything seems to work except the public key authorization. Finally I get prompted for my password and that works.
Unfortunately, I want to use public key authentication.
Below are the permissions and files in my .ssh directory,
-rw-rw-r-- me my_group authorized_keys
-rw-r--r-- me my_group id_dsa.pub
-rw-r--r-- me my_group id_rsa.pub
-rw------- me my_group id_dsa
-rw------- me my_group id_rsa
-rw-r--r-- me my_group known_hosts
-rw------- me my_group prng_seed
Below is the output from trying to connect from test_1 to test_2:
(test_1:cblake)/home/cblake/.ssh [28]$ ssh -v test_2
OpenSSH_3.5p1, SSH protocols 1.5/2.0, OpenSSL 0x0090609f
29630: debug1: Reading configuration data /opt/ssh/etc/ssh_config
29630: debug1: Rhosts Authentication disabled, originating port will not be trusted.
29630: debug1: ssh_connect: needpriv 0
29630: debug1: Connecting to world [172.27.193.42] port 22.
29630: debug1: Connection established.
29630: debug1: identity file /home/cblake/.ssh/id_rsa type -1
29630: debug1: identity file /home/cblake/.ssh/id_dsa type -1
29630: debug1: Remote protocol version 2.0, remote software version OpenSSH_3.5p1
29630: debug1: match: OpenSSH_3.5p1 pat OpenSSH*
29630: debug1: Enabling compatibility mode for protocol 2.0
29630: debug1: Local version string SSH-2.0-OpenSSH_3.5p1
29630: debug1: SSH2_MSG_KEXINIT sent
29630: debug1: SSH2_MSG_KEXINIT received
29630: debug1: kex: server->client aes128-cbc hmac-md5 none
29630: debug1: kex: client->server aes128-cbc hmac-md5 none
29630: debug1: SSH2_MSG_KEX_DH_GEX_REQUEST sent
29630: debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
29630: debug1: dh_gen_key: priv key bits set: 127/256
29630: debug1: bits set: 1603/3191
29630: debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
29630: debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
29630: debug1: Host 'world' is known and matches the RSA host key.
29630: debug1: Found key in /home/cblake/.ssh/known_hosts:1
29630: debug1: bits set: 1579/3191
29630: debug1: ssh_rsa_verify: signature correct
29630: debug1: kex_derive_keys
29630: debug1: newkeys: mode 1
29630: debug1: SSH2_MSG_NEWKEYS sent
29630: debug1: waiting for SSH2_MSG_NEWKEYS
29630: debug1: newkeys: mode 0
29630: debug1: SSH2_MSG_NEWKEYS received
29630: debug1: done: ssh_kex2.
29630: debug1: send SSH2_MSG_SERVICE_REQUEST
29630: debug1: service_accept: ssh-userauth
29630: debug1: got SSH2_MSG_SERVICE_ACCEPT
29630: debug1: authentications that can continue: publickey,password,keyboard-interactive
29630: debug1: next auth method to try is publickey
29630: debug1: try privkey: /home/cblake/.ssh/id_rsa
29630: debug1: read PEM private key done: type RSA
29630: debug1: authentications that can continue: publickey,password,keyboard-interactive
29630: debug1: try privkey: /home/cblake/.ssh/id_dsa
29630: debug1: read PEM private key done: type DSA
29630: debug1: authentications that can continue: publickey,password,keyboard-interactive
29630: debug1: next auth method to try is keyboard-interactive
29630: debug1: authentications that can continue: publickey,password,keyboard-interactive
29630: debug1: next auth method to try is password
cblake@test_2's password:
29630: debug1: ssh-userauth2 successful: method password
What am I doing wrong? Is it the problem with the depot?
Coleman Blake
Solved! Go to Solution.
2 REPLIES 2
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
05-13-2003 06:00 AM
05-13-2003 06:00 AM
Solution
Check the permissions on your .ssh directory itself. If they are too loose, sshd will ignore the key files there and fall-back to password auth.
You can also generate a debug session from sshd on the server side. This will frequently list errors that the client does not see. To do this, run
sshd -d
and connect to your server using
ssh
sshd -d runs the deamon in debug mode, which means it stays in the foreground and prints debugging messages to the terminal it was started from. The deamon also exits after one connection attempt.
You can also generate a debug session from sshd on the server side. This will frequently list errors that the client does not see. To do this, run
sshd -d
and connect to your server using
ssh
sshd -d runs the deamon in debug mode, which means it stays in the foreground and prints debugging messages to the terminal it was started from. The deamon also exits after one connection attempt.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
05-13-2003 06:25 AM
05-13-2003 06:25 AM
Re: Public Key Authentication Failing with Secure Shell 3.50
Thanks to Bill Douglass.
Running sshd -d (the debug mode) showed that the permissions or ownership of authorized_keys was wrong. I had overlooked the 664 permissions.
Changing them to 644 got it to work.
Great list. First reply solved the problem.
Coleman Blake.
Running sshd -d (the debug mode) showed that the permissions or ownership of authorized_keys was wrong. I had overlooked the 664 permissions.
Changing them to 644 got it to work.
Great list. First reply solved the problem.
Coleman Blake.
The opinions expressed above are the personal opinions of the authors, not of Hewlett Packard Enterprise. By using this site, you accept the Terms of Use and Rules of Participation.
Company
Events and news
Customer resources
© Copyright 2025 Hewlett Packard Enterprise Development LP