Sun SSH without a password (not OpenSSH)
The Derfer
that are both using SUN SSH (NOT OpenSSH!) different than it is
for OpenSSH. Per recent dictates, we've had to revert to Sun SSH
where I work. (Too bad, I liked OpenSSH better).
I follow the same procedures: generate public key (dsa or rsa), copy
it to
authorized_keys2 (and/or "authorized_keys") on the server you want to
access
without a password, and it is always NO GO. Always prompts for a
password.
Is this perhaps a problem indigenous to Sun SSH? I follow the
directions (exactly)
as seen on sites like:
http://www.securitydocs.com/library/3385
and
http://www.sunsolarisadmin.com/solaris-7/ssh-access-without-password-in-sun-solaris/
... but they, along with everybody else, assume OpenSSH is in use.
Anyone tried this with Sun SSH recently or ever?
Does anyone have reproducable steps?
The obvious questions for me need not be asked: yes, the permissions
and ownerships are
right, double-checked everything ... this is the only difference I can
think of.
Thanks in advance to anyone who can help.
Louis Wevers
This works for me:
# cd ~/.ssh
# ssh-keygen -t rsa -f id_rsa
Generating public/private rsa key pair.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in id_rsa.
Your public key has been saved in id_rsa.pub.
The key fingerprint is:
xx:xx:xx:08:d1:d1:29:da:29:8b:8f:c3:de:xx:xx:xx user@system
Log in as the intended user on the target machine. Add the public key
(id_rsa.pub) to ~/.ssh/authorized_keys. The file should look something
like this.
ssh-rsa
AAAAB3NzaC1yc2EAAAABIwAAAIEAtfjDtf/xhw2trKYAJ61MmzADkG+0ma7DrvIqjoRUswfPglRWrbDpD+An
A72dzJB8UcLCMB0jyEhNz3yN/tH8FQ4JAHQDDWyt47wAqf1PZGxxsXxxxxxxxxxxkx1ke4PM17rH5IK7uxJ5AnOU8jCJvXUxbdaYdReWnBSpInJHotE=
root@system
Note that this is all on one line. If you accidentally split it over
multiple lines, you'll get something like this:
# scp file user@system:/tmp
Connection closed by 10.10.16.10
lost connection
On system, you'll see something like the error below in /var/adm/messages
Jul 7 11:48:18 system sshd[26022]: [ID 800047 auth.crit] fatal:
buffer_get: trying to get more bytes 129 than in buffer 34
mtfe...@netmapsonscape.net
> This works for me:
Also, make sure the .ssh directory has permissions 700, and making the
authorized_keys file 600 wouldn't hurt, either.
Mike
Doug McIntyre
>Is the procedure for password-less SSH between 2 servers
>that are both using SUN SSH (NOT OpenSSH!) different than it is
>for OpenSSH. Per recent dictates, we've had to revert to Sun SSH
>where I work. (Too bad, I liked OpenSSH better).
You know that SunSSH is just a fork of OpenSSH with patches to make
things like Sun RBAC and their ideas of privsep work correctly, right?
Mark Bartelt
>> Check the permissions of .ssh and all files below.
>> Everything should be readable only by the owner.
Not true. Sun's ssh doesn't require this (nor does
OpenSSH); for example ...
$ sed 1q /etc/release
Solaris 10 10/08 s10x_u6wos_07b X86
$
$ ls -ld $HOME $HOME/.ssh $HOME/.ssh/authorized_keys
drwxr-xr-x 5 mark mark 6 Dec 8 07:54 /export/home/mark
drwxr-xr-x 2 mark mark 5 Aug 31 11:10 /export/home/mark/.ssh
-rw-r--r-- 1 mark mark 222 Jul 1 2004 /export/home/mark/.ssh/authorized_keys
$
And this configuration lets me connect using public
key authentication, with no problem.
But what _is_ important is that all three of $HOME,
$HOME/.ssh, and $HOME/.ssh/authorized_keys have the
"group" and "other" _write_ permissions disabled.
Dunno about Sun's SSH; but OpenSSH, at least, will
refuse to try public key authentication if any of
those three are writable by anybody other than the
owner.
ITguy
> >> Everything should be readable only by the owner.
>
> Not true. Sun's ssh doesn't require this (nor does
> OpenSSH); for example ...
Depends entirely on your sshd_config file. Check the "StrickModes"
setting.
Mark Bartelt
First, to review: Emil Naepflein wrote ...
EN> Check the permissions of .ssh and all files below.
EN> Everything should be readable only by the owner.
... to which I replied ...
MB> Not true. Sun's ssh doesn't require this (nor does
MB> OpenSSH); for example ...
MB>
MB> $ sed 1q /etc/release
MB> Solaris 10 10/08 s10x_u6wos_07b X86
MB> $
MB> $ ls -ld $HOME $HOME/.ssh $HOME/.ssh/authorized_keys
MB> drwxr-xr-x 5 mark mark 6 Dec 8 07:54 /export/home/mark
MB> drwxr-xr-x 2 mark mark 5 Aug 31 11:10 /export/home/mark/.ssh
MB> -rw-r--r-- 1 mark mark 222 Jul 1 2004 /export/home/mark/.ssh/authorized_keys
MB> $
MB>
MB> And this configuration lets me connect using public
MB> key authentication, with no problem.
MB>
MB> But what _is_ important is that all three of $HOME,
MB> $HOME/.ssh, and $HOME/.ssh/authorized_keys have the
MB> "group" and "other" _write_ permissions disabled.
MB>
MB> Dunno about Sun's SSH; but OpenSSH, at least, will
MB> refuse to try public key authentication if any of
MB> those three are writable by anybody other than the
MB> owner.
There were _two_ followups to this, both basically saying
the same (incorrect) thing. Emil Naepflein wrote ...
EN> Then you have changed the default behaviour in sshd_config.
EN> (StrictModes)
... and "ITguy" said basically the same thing ...
ITG> Depends entirely on your sshd_config file. Check the "StrickModes"
ITG> setting.
So, two things: First, our "StrictModes" setting hasn't
been changed from Sun's default:
$ diff /etc/ssh/sshd_config_ORIG /etc/ssh/sshd_config
76c76
< LogLevel info
---
> LogLevel verbose
119c119
< PasswordAuthentication yes
---
> PasswordAuthentication no
$
Secondly (and more important), let's look at the manpage
to see what "StrictModes" actually does:
$ man sshd_config
[ ... ]
StrictModes
Specifies whether sshd should check file modes and own-
ership of the user's files and home directory before
accepting login. This is normally desirable because
novices sometimes accidentally leave their directory or
files world-writable. The default is yes.
Note the reference to "world-writable". This is what the
"StrictModes" keyword controls: Whether sshd will check
whether the _write_ permission of $HOME, $HOME/.ssh, and
$HOME/.ssh/authorized_keys is correct (where "correct" is
"not enabled").
Nothing, either in the documentation, or in the observed
behaviour, suggests that anything needs to be set either
non-world-readable or non-group readable. Mode 0755 for
the directories and 0644 for authorized_keys is perfectly
fine.
LnxGnome
wrote:
> Nothing, either in the documentation, or in the observed
> behaviour, suggests that anything needs to be set either
> non-world-readable or non-group readable. Mode 0755 for
> the directories and 0644 for authorized_keys is perfectly
> fine.
Don't forget to check the CLIENT side permissions too
$HOME/.ssh/identity
$HOME/.ssh/id_dsa
Contains the RSA and the DSA authentication identity of the user.
These files contain sensitive data and should be readable by the user
but not accessible by others (read/write/execute).
Dave
IIRC, the ssh implementation uses $HOME/.ssh2 for the ssh files - I would check
the man pages.
There is by the way an ssh newsgroup. comp.security.ssh
I guess someone might have mentioned this before, but why bother using the
commercial ssh.com implementation?
--
I respectfully request that this message is not archived by companies as
unscrupulous as 'Experts Exchange' . In case you are unaware,
'Experts Exchange' take questions posted on the web and try to find
idiots stupid enough to pay for the answers, which were posted freely
by others. They are leeches.
Darren Dunham
> ... but they, along with everybody else, assume OpenSSH is in use.
> Anyone tried this with Sun SSH recently or ever?
Sun SSH isn't much different from OpenSSH. It's mainly just an older
codebase.
In both cases, you should ask the server why it's not working.
Easiest way is often to start a separate server in debug mode and
watch it when you try to log in with your key.
server# sshd -p 5555 -d
[watch output...]
client# ssh -p 5555 server
The server output should have information about looking for the
authorized key file and may give some output about why it's not
working.
--
Darren