ssh-keygen

[hok1man]

Hi,

Does anyone know how to use ssh-keygen in unix solaris 8?
I'm trying to set ssh from one server to another passwordless.

here's what I tried

ssh-keygen -f id_rsa -t rsa
Enter passphrase (empty for no passphrase): 
Enter same passphrase again:
The one you have chosen is unsuitable because it's WAY too short.

for both above questions I pressed enter (I didnt fill anything), that was the message I got
seems like they don't like without password.

So I put the passphrase, and after id_rsa.pub generated and I copy it to authorized_keys.
when I ssh, they still require the password, any other way to setup ssh passwordless or I should try something else?


Thanks guys

 

[ZaSter]

hok1man,

Try the command without specifying "-f id_rsa".

Also, do you already have an "id_rsa" file in your ".ssh" directory?

 

[hok1man]

Hi Zaster,

Doesn't matter, I got directory ~/.ssh already,
if I didnt put -f id_rsa, they will ask me what file and directory I want to put into.

by default --> ~/.ssh/id_rsa

Cheers,

 

[Annihilannic]

I have never had a problem providing a blank passphrase to ssh-keygen. What version of SSH is this, do you know? Try ssh -V to see if it tells you.

Annihilannic.

 

[ZaSter]

hok1man,

Very odd. I have only one idea of what the problem might be. Try this:

ssh-keygen -f id_rsa -t rsa -N ""

Do you get the same result?

 

[hoinz]

when I ssh, they still require the password

One more thing to check, and a common mistake, is permission for file authorized_keys and all the directories in its path. For security reasons they must not be writable for anybody else but the owner and root.

hope this helps

 

[hok1man]

Anni,
bash-2.03$ ssh -V
OpenSSH_4.0p1, OpenSSL 0.9.7e 25 Oct 2004

Zaster,
your code is worked without password, but still my ssh to another server require the password.

hoinz,
I've checked my .ssh
drwx------ 2 test1 test2 4096 Mar 12 20:19 .ssh
should be fine..

Let me explain more details about this,
my home directory in server1 and server2 is the same exactly, so both server points to one home directory, but there are some other directory exists in different server which I'm going to write script to.

so, I've created to key in .ssh

bash-2.03$ ls -lart
total 64
-rw-r--r--   1 test1 test2      751 Mar 11 22:30 known_hosts
-rw-r--r--   1 test1 test2      244 Mar 12 20:13 id_rsa.pub
-rw-------   1 test1 test2      887 Mar 12 20:13 id_rsa
-rw-r--r--   1 test1 test2      242 Mar 12 20:19 tlm_rsa.pub
-rw-------   1 test1 test2      883 Mar 12 20:19 tlm_rsa
drwx------   2 test1 test2     4096 Mar 12 20:19 .
-rw-r--r--   1 test1 test2      486 Mar 12 20:19 authorized_keys
drwxr-xr-x   5 test1 test2     4096 Mar 12 20:54 ..

server1 is id_rsa.pub
server2 is tlm_rsa.pub

and cat id_rsa.pub tlm_rsa.pub >> authorized_keys

I checked
cat -vet authorized_keys
at the end of the line i see $

but I dont see it in vi,

is that because of it? if it is how do I get rid of it?
I have tried
dos2unix -ascii authorized_keys
it doeesnt work

any idea guys please?

 

[Annihilannic]

cat -vet displays $s to show you where the end of line characters are. You won't see them in vi unless you use the :set list command. That is normal and is not likely to be your problem.

sshd also cares about the permissions of your home directory and its parent directories, make sure they don't have 'group' or 'other' write access.

The best way to find out what's wrong is to run sshd in debug mode on an alternate port, e.g. on server2 /usr/sbin/sshd -d -p1234, and then from server1 ssh -p1234 server2 uptime, then examine the debug output to see why it is refusing to authenticate using keys.

Annihilannic.

 

[IRudebwoy]

Try

ssh-copy-id -i <key file> username@remote.host

Worth a shot.

 

[ZaSter]

hok1man,

I believe the reason the -N "" worked but entering an empty passphrase on the command line did not work is because your terminal settings are entering an invisible character every time you hit the "Enter" key, almost as if you are working on or from a Windows machine that enters "^M" when you hit the enter key. That one character would be seen as a passphrase entry and, since it really is so short, it would cause the "your passphrase is WAY too short" error message.

There are lots of great suggestions from the guys, and I have one other thing -- Your authorized_keys file should not be world and group readable as yours is. As folks here have pointed out, SSH can be very put off by file and directory permissions.

ZaSter

 

[Annihilannic]

There are lots of great suggestions from the guys, and I have one other thing -- Your authorized_keys file should not be world and group readable as yours is. As folks here have pointed out, SSH can be very put off by file and directory permissions.

Since the permissions of ~/.ssh have to be 700 for sshd to accept it, I woudln't stress about that. ;-)

Annihilannic.

 

[ZaSter]

Hi, Anni,

Since the permissions of ~/.ssh have to be 700 for sshd to accept it, I woudln't stress about that. ;-)

You might not stress about it but take a look at the OpenSSH FAQ "I copied my public key to authorized_keys but public-key authentication still doesn't work." which, among other things, includes:

$ chmod 600 $HOME/.ssh/authorized_keys

Use the FAQ, Luke.

 

[Annihilannic]

Never been a problem for me.

Annihilannic.

 

[ZaSter]

Never been a problem for me.

I have seen the problem many times, especially with Solaris and networked file systems such as AFS or NFS.

 

[hok1man]

Hi guys,

sorry come back abit late,
been busy for other things while fixing this as well.

Zaster,
I've changed the permission to 600 but still doesn't help.

Anni,
we dont have sshd in Solaris

$ which sshd
unknown mode: 1500:5:5bd:803b:3:1c:8:15:4:0:0:0:11:13:1a:0:12:0:17:0:0:0
no sshd in /usr/local/bin /apps/bin /usr/dt/bin /usr/openwin/bin /usr/ccs/bin /usr/bin /usr/sbin /usr/ucb

I have tried using ssh, but it's error :

$ ssh -d -p1234
ssh: illegal option -- d
usage: ssh [-1246AaCfgkMNnqsTtVvXxY] [-b bind_address] [-c cipher_spec]
           [-D port] [-e escape_char] [-F configfile]
           [-i identity_file] [-L [bind_address:]port:host:hostport]
           [-l login_name] [-m mac_spec] [-O ctl_cmd] [-o option] [-p port]
           [-R [bind_address:]port:host:hostport] [-S ctl_path]
           [user@]hostname [command]

Sigh, I never find any problem with this in Linux, why it's complicated in Solaris?

Any other idea guys?

 

[ZaSter]

hok1man,

On Solaris, the sshd daemon is /usr/lib/ssh/sshd.

But you would have to be logged in as "root" to stop or start the sshd.

Did you notice?:

$ which sshd
unknown mode: 1500:5:5bd:803b:3:1c:8:15:4:0:0:0:11:13:1a:0:12:0:17:0:0:0

I think that message is referring to your terminal modes again and will continue to be a problem for you with SSH and other programs, such as vi or vim.

Try this which will reset your terminal modes "to some reasonable values":

stty sane

Then try to ssh to the other machine again, but this time use ssh -v and post the output here so we can get a better idea of what's happening.

Thanks

- ZaSter -

 

[hok1man]

Thanks Zaster,

I have tried your command, here's the result

$ stty sane
$ ssh -v SERVER2
OpenSSH_4.0p1, OpenSSL 0.9.7e 25 Oct 2004
debug1: Reading configuration data /etc/IBtech/ssh/ssh_config
debug1: Connecting to SERVER2 [169.123.166.42] port 22.
debug1: Connection established.
debug1: identity file /home/eq_operate/[myID]/.ssh/identity type -1
debug1: identity file /home/eq_operate/[myID]/.ssh/id_rsa type 1
debug1: identity file /home/eq_operate/[myID]/.ssh/id_dsa type -1
debug1: Remote protocol version 1.99, remote software version OpenSSH_4.0
debug1: match: OpenSSH_4.0 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_4.0
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 'SERVER2' is known and matches the RSA host key.
debug1: Found key in /home/eq_operate/[myID]/.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: /home/eq_operate/[myID]/.ssh/identity
debug1: Offering public key: /home/eq_operate/[myID]/.ssh/id_rsa
debug1: Authentications that can continue: publickey,password
debug1: Trying private key: /home/eq_operate/[myID]/.ssh/id_dsa
debug1: Next authentication method: password
[myID]@SERVER1 password:

 

[ZaSter]

hok1man,

Looks like SERVER2 did not accept your public key. I would check the /etc/IBtech/ssh/sshd_config file on SERVER2 to make sure it has

RSAAuthentication yes
PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys

Is your home directory in AFS, DFS, or NFS?

You can also increase the verbosity level of the ssh command up to ssh -vvv to get even more details of the ssh connection.

- ZaSter -

 

[hok1man]

I think I found the problem, but I don't think I can change it.

This what I got in /etc/IBtech/ssh/sshd_config file

RSAAuthentication yes
PubkeyAuthentication yes
AuthorizedKeysFile      /etc/IBtech/ssh/auth_keys/%u

so the AuthorizedKeysFile in that directory, and that directory is not writable except for root,

what %u means? username?

 

[ZaSter]

Yep, requiring the user authorized keys to be in that directory instead of the default .ssh/authorized_keys file is sure to be the problem. Perhaps your site requires you to request to have your SSH keys officially blessed into the SSH configuration?

what %u means? username?

Yes, per "man 5 sshd_config", "%u is replaced by the username."


- ZaSter -