Sponsored Content
Operating Systems Linux Unable to ssh using identity keys Post 302169364 by new2ss on Thursday 21st of February 2008 04:21:37 AM
Old 02-21-2008
Unable to ssh using identity keys

Hi all, i am trying to ssh into a remote server without password, i tried the command with the verbose command 'ssh -v -l user1 10.10.10.10'
Code:
OpenSSH_3.6.1p2, SSH protocols 1.5/2.0, OpenSSL 0x0090701f
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Rhosts Authentication disabled, originating port will not be trusted.
debug1: Connecting to 10.10.10.10 [10.10.10.10] port 22.
debug1: Connection established.
debug1: identity file /home/user1/.ssh/identity type 0
debug1: identity file /home/user1/.ssh/id_rsa type 1
debug1: Remote protocol version 1.99, remote software version OpenSSH_3.9p1
debug1: match: OpenSSH_3.9p1 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_3.6.1p2
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 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 '10.10.10.10' is known and matches the RSA host key.
debug1: Found key in /home/user1/.ssh/known_hosts:33
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,gssapi-with-mic,password
debug1: Next authentication method: publickey
debug1: Offering public key: /home/user1/.ssh/id_rsa
debug1: Authentications that can continue: publickey,gssapi-with-mic,password
debug1: Next authentication method: password

i have already copied the public key(id_dsa.pub) to both authorized_keys and authorized_keys2.what could be the problem?

On the remote server, i am seeing this error
Code:
Authentication refused: bad ownership or modes for directory /home/user1

Update:
Hi all, problem resolved. The home directory permission was set incorrectly.

Last edited by new2ss; 02-21-2008 at 06:36 AM..
 

6 More Discussions You Might Find Interesting

1. SCO

Unable to use funtion keys with Kea term

Hi I have a server SCO_SV mantrak 3.2 5.0.5 i386 and i use a terminal emulator called Kea 420 term ! when i log in to the session i am unable to use the funtions keys then i reset the server and works fine just some minutes any comment ? i really apreciate your help regards... (1 Reply)
Discussion started by: Rdavila
1 Replies

2. UNIX for Advanced & Expert Users

SSH Keys Help

Hello, I'm wondering if anyone has a step-by-step instruction set for setting up ssh keys? I've gone through many of the manuals online (most seem to be from the same source) and it's a little bit unclear when the documentation is talking about the server versus the client machine. I'm missing... (1 Reply)
Discussion started by: sysera
1 Replies

3. UNIX for Dummies Questions & Answers

SSH keys

Hi everyone, i wanted to generate ssh keys so that i can include the public key in the remote sever, so that for subsequent logins, i can do away with the keying in of the password. I consulted the man ssh-keygen man pages. "..Normally each user wishing to use SSH with RSA or DSA... (1 Reply)
Discussion started by: new2ss
1 Replies

4. Shell Programming and Scripting

What are public keys in ssh and how do we create the public keys??

Hi All, I am having knowledge on some basics of ssh and wanted to know what are the public keys and how can we create and implement it in connecting server. Please provide the information for the above, it would be helpful for me. Thanks, Ravindra (1 Reply)
Discussion started by: ravi3cha
1 Replies

5. Solaris

help with SSH keys

Hello, I could use some help with my ssh keys and agent. This is the issue. I have 2 different UNIX systems at work. One is the normal Solaris servers with my uid being the same throughout all the servers. I now have a different system for my desktop. A contractor came in and installed some SUN... (0 Replies)
Discussion started by: bitlord
0 Replies

6. Shell Programming and Scripting

Find active SSH servers w/ ssh keys on LAN

Hi, I am trying to complete my bash script in order to find which SSH servers on LAN are still active with the ssh keys, but i am frozen at this step: #!/bin/bash # LAN SSH KEYS DISCOVERY SCRIPT </etc/passwd \ grep /bin/bash | cut -d: -f6 | sudo xargs -i -- sh -c ' && cat... (11 Replies)
Discussion started by: syrius
11 Replies
SSH-VULNKEY(1)						    BSD General Commands Manual 					    SSH-VULNKEY(1)

NAME
ssh-vulnkey -- check blacklist of compromised keys SYNOPSIS
ssh-vulnkey [-q | -v] file ... ssh-vulnkey -a DESCRIPTION
ssh-vulnkey checks a key against a blacklist of compromised keys. A substantial number of keys are known to have been generated using a broken version of OpenSSL distributed by Debian which failed to seed its random number generator correctly. Keys generated using these OpenSSL versions should be assumed to be compromised. This tool may be useful in checking for such keys. Keys that are compromised cannot be repaired; replacements must be generated using ssh-keygen(1). Make sure to update authorized_keys files on all systems where compromised keys were permitted to authenticate. The argument list will be interpreted as a list of paths to public key files or authorized_keys files. If no suitable file is found at a given path, ssh-vulnkey will append .pub and retry, in case it was given a private key file. If no files are given as arguments, ssh-vulnkey will check ~/.ssh/id_rsa, ~/.ssh/id_dsa, ~/.ssh/identity, ~/.ssh/authorized_keys and ~/.ssh/authorized_keys2, as well as the system's host keys if readable. If ``-'' is given as an argument, ssh-vulnkey will read from standard input. This can be used to process output from ssh-keyscan(1), for example: $ ssh-keyscan -t rsa remote.example.org | ssh-vulnkey - Unless the PermitBlacklistedKeys option is used, sshd(8) will reject attempts to authenticate with keys in the compromised list. The output from ssh-vulnkey looks like this: /etc/ssh/ssh_host_key:1: COMPROMISED: RSA1 2048 xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx root@host /home/user/.ssh/id_dsa:1: Not blacklisted: DSA 1024 xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx /home/user/.ssh/id_dsa.pub /home/user/.ssh/authorized_keys:3: Unknown (blacklist file not installed): RSA 1024 xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx user@host Each line is of the following format (any lines beginning with ``#'' should be ignored by scripts): filename:line: status: type size fingerprint comment It is important to distinguish between the possible values of status: COMPROMISED These keys are listed in a blacklist file, normally because their corresponding private keys are well-known. Replacements must be generated using ssh-keygen(1). Not blacklisted A blacklist file exists for this key type and size, but this key is not listed in it. Unless there is some particular reason to believe otherwise, this key may be used safely. (Note that DSA keys used with the broken version of OpenSSL distributed by Debian may be compromised in the event that anyone captured a network trace, even if they were generated with a secure version of OpenSSL.) Unknown (blacklist file not installed) No blacklist file exists for this key type and size. You should find a suitable published blacklist and install it before deciding whether this key is safe to use. The options are as follows: -a Check keys of all users on the system. You will typically need to run ssh-vulnkey as root to use this option. For each user, ssh-vulnkey will check ~/.ssh/id_rsa, ~/.ssh/id_dsa, ~/.ssh/identity, ~/.ssh/authorized_keys and ~/.ssh/authorized_keys2. It will also check the system's host keys. -q Quiet mode. Normally, ssh-vulnkey outputs the fingerprint of each key scanned, with a description of its status. This option sup- presses that output. -v Verbose mode. Normally, ssh-vulnkey does not output anything for keys that are not listed in their corresponding blacklist file (although it still produces output for keys for which there is no blacklist file, since their status is unknown). This option causes ssh-vulnkey to produce output for all keys. EXIT STATUS
ssh-vulnkey will exit zero if any of the given keys were in the compromised list, otherwise non-zero. BLACKLIST FILE FORMAT
The blacklist file may start with comments, on lines starting with ``#''. After these initial comments, it must follow a strict format: o All the lines must be exactly the same length (20 characters followed by a newline) and must be in sorted order. o Each line must consist of the lower-case hexadecimal MD5 key fingerprint, without colons, and with the first 12 characters removed (that is, the least significant 80 bits of the fingerprint). The key fingerprint may be generated using ssh-keygen(1): $ ssh-keygen -l -f /path/to/key This strict format is necessary to allow the blacklist file to be checked quickly, using a binary-search algorithm. FILES
~/.ssh/id_rsa If present, contains the protocol version 2 RSA authentication identity of the user. ~/.ssh/id_dsa If present, contains the protocol version 2 DSA authentication identity of the user. ~/.ssh/identity If present, contains the protocol version 1 RSA authentication identity of the user. ~/.ssh/authorized_keys If present, lists the public keys (RSA/DSA) that can be used for logging in as this user. ~/.ssh/authorized_keys2 Obsolete name for ~/.ssh/authorized_keys. This file may still be present on some old systems, but should not be created if it is missing. /etc/ssh/ssh_host_rsa_key If present, contains the protocol version 2 RSA identity of the system. /etc/ssh/ssh_host_dsa_key If present, contains the protocol version 2 DSA identity of the system. /etc/ssh/ssh_host_key If present, contains the protocol version 1 RSA identity of the system. /usr/share/ssh/blacklist.TYPE-LENGTH If present, lists the blacklisted keys of type TYPE (``RSA'' or ``DSA'') and bit length LENGTH. The format of this file is described above. RSA1 keys are converted to RSA before being checked in the blacklist. Note that the fingerprints of RSA1 keys are computed differently, so you will not be able to find them in the blacklist by hand. /etc/ssh/blacklist.TYPE-LENGTH Same as /usr/share/ssh/blacklist.TYPE-LENGTH, but may be edited by the system administrator to add new blacklist entries. SEE ALSO
ssh-keygen(1), sshd(8) AUTHORS
Colin Watson <cjwatson@ubuntu.com> Florian Weimer suggested the option to check keys of all users, and the idea of processing ssh-keyscan(1) output. BSD
May 12, 2008 BSD
All times are GMT -4. The time now is 11:15 AM.
Unix & Linux Forums Content Copyright 1993-2022. All Rights Reserved.
Privacy Policy