I am away from my office for the week. In Sacramento for the IEEE 802.1 interim meeting (for anyone in the neighborhood...).
And I am working on SSH with my Centos install(s).
1) For right now I am using my XP drive with Tectia client. I have SSHed into my Centos server using password method and uploaded my public key and such. I see everything there. I think. I then delete all authentication methods but public key and am told that no recognized authentication match. When I add password back into my client, I get the password authentication method.
My hunch is there is something I need to do with the SSH server config to access client certificate authentication? What do I need to do, and remember, all I have is a text window into my machine (can su) and I do not have my VI manual with me! (I will go and look for one online).
2) later this evening, I will pop in my Centos drive and then SSH from a Centos client. But of course my keys and such are on my XP drive. I know where Tectia keeps all of its keys, as I have moved them from one XP drive to another. Anyone know what I need to do? I do have a USB drive for the transfer. Or I can upload everything to my Centos server, then download to my Centos client.
Thank you for your continued help.
Oh, I have been going back into all of my threads here and pulling out notes on what to do to avoid asking something more than once.
the server file /home/username/.ssh/authorized_keys must contain a line containing /home/username/.ssh/id_dsa.pub (use ssh-keygen -t dsa to generate it)
Furthermore /etc/ssh/sshd_config must not have PubkeyAuthentication no (yes is the default) [if you delete it remember to /etc/init.d/sshd restart]
cheers, MaZe.
On Tue, 10 Jan 2006, Robert Moskowitz wrote:
I am away from my office for the week. In Sacramento for the IEEE 802.1 interim meeting (for anyone in the neighborhood...).
And I am working on SSH with my Centos install(s).
- For right now I am using my XP drive with Tectia client. I have SSHed
into my Centos server using password method and uploaded my public key and such. I see everything there. I think. I then delete all authentication methods but public key and am told that no recognized authentication match. When I add password back into my client, I get the password authentication method.
My hunch is there is something I need to do with the SSH server config to access client certificate authentication? What do I need to do, and remember, all I have is a text window into my machine (can su) and I do not have my VI manual with me! (I will go and look for one online).
- later this evening, I will pop in my Centos drive and then SSH from a
Centos client. But of course my keys and such are on my XP drive. I know where Tectia keeps all of its keys, as I have moved them from one XP drive to another. Anyone know what I need to do? I do have a USB drive for the transfer. Or I can upload everything to my Centos server, then download to my Centos client.
Thank you for your continued help.
Oh, I have been going back into all of my threads here and pulling out notes on what to do to avoid asking something more than once.
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
On Tue, 10 Jan 2006, Maciej ?enczykowski wrote:
the server file /home/username/.ssh/authorized_keys must contain a line containing /home/username/.ssh/id_dsa.pub (use ssh-keygen -t dsa to generate it)
Further, you must ensure that, on the remote machine into which you're attempting to login,
a) $HOME is not group-writeable or world-writeable
b) $HOME/.ssh has 0700 permissions
c) $HOME/.ssh/* have 0600 permissions
(Actually, there are some $HOME/ssh/* files that can have looser permissions than 600, but they all work with 0600, so that's the way I keep them.)
At 02:45 PM 1/10/2006, Paul Heinlein wrote:
Further, you must ensure that, on the remote machine into which you're attempting to login,
You just went beyond my Un*x memory stack. I learned this stuff once upon a time, but I forget how to check this out...
a) $HOME is not group-writeable or world-writeable
Is this the directory /home/user ? Or some environment variable?
b) $HOME/.ssh has 0700 permissions
c) $HOME/.ssh/* have 0600 permissions
As I said, mine are /ssh2 and how do I check this?
(Actually, there are some $HOME/ssh/* files that can have looser permissions than 600, but they all work with 0600, so that's the way I keep them.)
~]$ ls -la total 52 . . . drwxrwxr-x 2 user user 4096 Jan 10 17:01 .ssh2
.ssh2]$ls -l total 8 -rw-r--r-- 1 user user 12 Jan 10 17:01 authorization -rw-r--r-- 1 user user 1252 Jul 8 2005 user.pub
Paul Heinlein wrote:
On Tue, 10 Jan 2006, Maciej ?enczykowski wrote:
the server file /home/username/.ssh/authorized_keys must contain a line containing /home/username/.ssh/id_dsa.pub (use ssh-keygen -t dsa to generate it)
Further, you must ensure that, on the remote machine into which you're attempting to login,
a) $HOME is not group-writeable or world-writeable
b) $HOME/.ssh has 0700 permissions
c) $HOME/.ssh/* have 0600 permissions
(Actually, there are some $HOME/ssh/* files that can have looser permissions than 600, but they all work with 0600, so that's the way I keep them.)
And the cheap way I do this is either "ssh-keygen -t dsa" or "ssh-keygen -t rsa" which creates the directory structure every time, and consistenly too.
Also if I remember correctly, ssh2 references were deprecated somewhere along openssh 2.96 release. Just ssh is used. e.g. /home/$username/.ssh/
On Tue, 2006-01-10 at 16:58 -0800, Keith Morse wrote:
Paul Heinlein wrote:
On Tue, 10 Jan 2006, Maciej ?enczykowski wrote:
Also if I remember correctly, ssh2 references were deprecated somewhere along openssh 2.96 release. Just ssh is used. e.g. /home/$username/.ssh/
If the server is running the Tectia (formerly known as ssh.com) ssh server, then the keys and other stuff are stored in ~/.ssh2/. And the structure of the key files is different than with openssh.
At 05:30 PM 1/10/2006, Tony Schreiner wrote:
On Tue, 2006-01-10 at 16:58 -0800, Keith Morse wrote:
Paul Heinlein wrote:
On Tue, 10 Jan 2006, Maciej ?enczykowski wrote:
Also if I remember correctly, ssh2 references were deprecated somewhere along openssh 2.96 release. Just ssh is used. e.g. /home/$username/.ssh/
If the server is running the Tectia (formerly known as ssh.com) ssh server, then the keys and other stuff are stored in ~/.ssh2/. And the structure of the key files is different than with openssh.
And although, I probably only have to ask SSH, I do not want to go the Tectia server route (I have various connections to them and have received software in the past (like their client!), but need to wean myself from $$ software).
I might have to 'bite the bullet' and push them to just help me get this working (or I will write this up somewhere visible? nah, I am not mean).
Illegitimi non Carborundum
On Tue, 2006-01-10 at 17:46 -0800, Robert Moskowitz wrote:
At 05:30 PM 1/10/2006, Tony Schreiner wrote:
On Tue, 2006-01-10 at 16:58 -0800, Keith Morse wrote:
Paul Heinlein wrote:
On Tue, 10 Jan 2006, Maciej ?enczykowski wrote:
Also if I remember correctly, ssh2 references were deprecated somewhere along openssh 2.96 release. Just ssh is used. e.g. /home/$username/.ssh/
If the server is running the Tectia (formerly known as ssh.com) ssh server, then the keys and other stuff are stored in ~/.ssh2/. And the structure of the key files is different than with openssh.
And although, I probably only have to ask SSH, I do not want to go the Tectia server route (I have various connections to them and have received software in the past (like their client!), but need to wean myself from $$ software).
I might have to 'bite the bullet' and push them to just help me get this working (or I will write this up somewhere visible? nah, I am not mean).
The Tectia client interoperates perfectly well with OpenSSH server, so you probably don't need to stick with their server. I just meant to point out that you might have some files in the Tectia server format.
As has been said, use ssh-keygen on the server to generate your private and public keys (and the ~/.ssh/ ) directory, and copy the public key to your client.
I don't normally use the Tectia client with public keys, so I'm afraid I can't remember if you need to convert the key to ssh2 format for the Tectia client. You would do that with
ssh-keygen -t dsa -x (if you used -t dsa when you created the key).
will output the ssh2 format public key to stdout
Tony
At 06:06 PM 1/10/2006, Tony Schreiner wrote:
On Tue, 2006-01-10 at 17:46 -0800, Robert Moskowitz wrote:
At 05:30 PM 1/10/2006, Tony Schreiner wrote:
On Tue, 2006-01-10 at 16:58 -0800, Keith Morse wrote:
Paul Heinlein wrote:
On Tue, 10 Jan 2006, Maciej ?enczykowski wrote:
Also if I remember correctly, ssh2 references were deprecated somewhere along openssh 2.96 release. Just ssh is
used. e.g. /home/$username/.ssh/
If the server is running the Tectia (formerly known as ssh.com) ssh server, then the keys and other stuff are stored in ~/.ssh2/. And the structure of the key files is different than with openssh.
And although, I probably only have to ask SSH, I do not want to go the Tectia server route (I have various connections to them and have received software in the past (like their client!), but need to wean myself from $$ software).
I might have to 'bite the bullet' and push them to just help me get this working (or I will write this up somewhere visible? nah, I
am not mean).
The Tectia client interoperates perfectly well with OpenSSH server, so you probably don't need to stick with their server. I just meant to point out that you might have some files in the Tectia server format.
But when I set my client to ONLY use publickey, and I have done, I think, all of the host setup, the host reports that there is no authentication method to use. i.e. it is not willing to use publickey for some reason...
As has been said, use ssh-keygen on the server to generate your private and public keys (and the ~/.ssh/ ) directory, and copy the public key to your client.
I don't normally use the Tectia client with public keys, so I'm afraid I can't remember if you need to convert the key to ssh2 format for the Tectia client. You would do that with
ssh-keygen -t dsa -x (if you used -t dsa when you created the key).
will output the ssh2 format public key to stdout
Tony _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Insight from /var/log/secure
Jan 10 20:28:56 z9m9z sshd[2705]: Authentication refused: bad ownership or modes for file /home/rgm/.ssh/authorized_keys
So here are all of the permissions, I think:
starting at root:
drwxr-xr-x 3 root root 4096 Jan 5 13:33 home
drwx------ 4 rgm rgm 4096 Jan 10 21:13 rgm
drwxrwxr-x 2 rgm rgm 4096 Jan 10 20:28 .ssh
-rw-rw-r-- 1 rgm rgm 1101 Jan 10 20:25 authorized_keys
so what now????
On Tue, 2006-01-10 at 18:19 -0800, Robert Moskowitz wrote:
Insight from /var/log/secure
Jan 10 20:28:56 z9m9z sshd[2705]: Authentication refused: bad ownership or modes for file /home/rgm/.ssh/authorized_keys
So here are all of the permissions, I think:
starting at root:
drwxr-xr-x 3 root root 4096 Jan 5 13:33 home
drwx------ 4 rgm rgm 4096 Jan 10 21:13 rgm
drwxrwxr-x 2 rgm rgm 4096 Jan 10 20:28 .ssh
-rw-rw-r-- 1 rgm rgm 1101 Jan 10 20:25 authorized_keys
so what now????
.ssh needs to be 700
authorized_keys needs to be 400
chmod 700 .ssh
and
chmod 400 authorized_keys
At 06:40 PM 1/10/2006, Johnny Hughes wrote:
drwxrwxr-x 2 rgm rgm 4096 Jan 10 20:28 .ssh
-rw-rw-r-- 1 rgm rgm 1101 Jan 10 20:25 authorized_keys
so what now????
.ssh needs to be 700 authorized_keys needs to be 400
chmod 700 .ssh and chmod 400 authorized_keys
Johnny,
thank you so much! It works and I am in!
Now I will copy this to my notes and later go back so I can relearn my 'permissions' (yeah, I know all it is is an octal bit map, and I DID cut my teeth on a CDC6500 !)
Barrs Law of Recursive futility If you're smart enough to use one of these.... .....you can probably manage without one!
At 04:58 PM 1/10/2006, Keith Morse wrote:
And the cheap way I do this is either "ssh-keygen -t dsa" or "ssh-keygen -t rsa" which creates the directory structure every time, and consistenly too.
Now I really believe I have something configured wrong....
On my Astaro firewall, I had to create everything manually. As it does not have a Unix adduser or secure file upload.
So I followed my working 'instructions'.
I used:
/usr/bin/ssh-keygen -X -f ~/.ssh/identity.pub >> ~/.ssh/authorized_keys2
and that worked fine on astaro, but not here. So I changed ..._keys2 to ..._keys and no help.
Oh, identity.pub was created with:
cat > ~/.ssh/identity.pub <copy clipboard that has public key in it> CNTL+D
Of course I don't know what the -X option does. My debian friend gave me that command structure...
Robert Moskowitz wrote:
Now I really believe I have something configured wrong....
On my Astaro firewall, I had to create everything manually. As it does not have a Unix adduser or secure file upload.
So I followed my working 'instructions'.
I used:
/usr/bin/ssh-keygen -X -f ~/.ssh/identity.pub >> ~/.ssh/authorized_keys2
and that worked fine on astaro, but not here. So I changed ..._keys2 to ..._keys and no help.
Oh, identity.pub was created with:
cat > ~/.ssh/identity.pub
<copy clipboard that has public key in it> CNTL+D
Of course I don't know what the -X option does. My debian friend gave me that command structure...
The stuff from ssh.com (which I assume includes Tectia) used a different format for the key files. If you generated the keypair with Tectia (or commercial SSH) instead of OpenSSH, you'll need to convert the public key to the OpenSSH format. If you cat out an OpenSSH public keyfile, you should see a single line that starts with 'ssh-dsa' or 'ssh-rsa' (depending on the key type) followed by a long string of what appears to be MD5-encoded information.
A SSH2 (or Tectia?) public key is a multi-line file containing the literal strings "---- BEGIN SSH2 PUBLIC KEY ----" and "---- END SSH2 PUBLIC KEY ----", with the actual key information in-between.
I think the -X option on ssh-keygen from SSH2/Tectia converts OpenSSH format keys to the SSH2 format. Looks like a "right church, wrong pew" sort of issue.
If you generated your keypair with Tectia, copy the .pub file over to your Linux box and use ssh-keygen to convert it. If your public key was named "foo.pub", here's what you'd use to append it to your authorized_keys file:
ssh-keygen -i -f foo.pub >> ~/.ssh/authorized_keys
Make sure the permissions on the .ssh directory and it's contents are appropriate. Make sure the whole tree is owned by the appropriate user, too! I usually set the .ssh directory perms to 700 and the files in it to 600, but I'm a bit paranoid.
ssh-keygen provided with the commercial version of SSH will convert the OpenSSH format to their format, too, so it's relatively easy to go either way. Check the Tectia manpages... oops, never mind: Windows! There's gotta be some docs for it SOMEWHERE.
Converting the private half of the keypair is a little tougher, as a password-protected SSH2 key can't be read by either version of SSH's ssh-keygen. You'll have to remove the password protection from the private key in order to let the other SSH's version of ssh-keygen convert it.
Hope that helps!
I am using the openssh ssh-keygen. from my astaro usage, I know that whatever I did works between tectia client and openssh server.
Yes, my pub key file does start with:
---- BEGIN SSH2 PUBLIC KEY ---- Comment: "My Network [2048-bit dsa
and that gets converted to a file without any <lf>s that starts with:
ssh-dss
so there seems to be some permissions challenge here?
At 06:10 PM 1/10/2006, Jay Leafey wrote:
Robert Moskowitz wrote:
Now I really believe I have something configured wrong.... On my Astaro firewall, I had to create everything manually. As it does not have a Unix adduser or secure file upload. So I followed my working 'instructions'. I used: /usr/bin/ssh-keygen -X -f ~/.ssh/identity.pub >> ~/.ssh/authorized_keys2 and that worked fine on astaro, but not here. So I changed ..._keys2 to ..._keys and no help. Oh, identity.pub was created with: cat > ~/.ssh/identity.pub
<copy clipboard that has public key in it> CNTL+D Of course I don't know what the -X option does. My debian friend gave me that command structure...
The stuff from ssh.com (which I assume includes Tectia) used a different format for the key files. If you generated the keypair with Tectia (or commercial SSH) instead of OpenSSH, you'll need to convert the public key to the OpenSSH format. If you cat out an OpenSSH public keyfile, you should see a single line that starts with 'ssh-dsa' or 'ssh-rsa' (depending on the key type) followed by a long string of what appears to be MD5-encoded information.
A SSH2 (or Tectia?) public key is a multi-line file containing the literal strings "---- BEGIN SSH2 PUBLIC KEY ----" and "---- END SSH2 PUBLIC KEY ----", with the actual key information in-between.
I think the -X option on ssh-keygen from SSH2/Tectia converts OpenSSH format keys to the SSH2 format. Looks like a "right church, wrong pew" sort of issue.
If you generated your keypair with Tectia, copy the .pub file over to your Linux box and use ssh-keygen to convert it. If your public key was named "foo.pub", here's what you'd use to append it to your authorized_keys file:
ssh-keygen -i -f foo.pub >> ~/.ssh/authorized_keysMake sure the permissions on the .ssh directory and it's contents are appropriate. Make sure the whole tree is owned by the appropriate user, too! I usually set the .ssh directory perms to 700 and the files in it to 600, but I'm a bit paranoid.
ssh-keygen provided with the commercial version of SSH will convert the OpenSSH format to their format, too, so it's relatively easy to go either way. Check the Tectia manpages... oops, never mind: Windows! There's gotta be some docs for it SOMEWHERE.
Converting the private half of the keypair is a little tougher, as a password-protected SSH2 key can't be read by either version of SSH's ssh-keygen. You'll have to remove the password protection from the private key in order to let the other SSH's version of ssh-keygen convert it.
Hope that helps!
Jay Leafey - Memphis, TN jay.leafey@mindless.com
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Robert Moskowitz wrote:
At 04:58 PM 1/10/2006, Keith Morse wrote:
And the cheap way I do this is either "ssh-keygen -t dsa" or "ssh-keygen -t rsa" which creates the directory structure every time, and consistenly too.
Now I really believe I have something configured wrong....
On my Astaro firewall, I had to create everything manually. As it does not have a Unix adduser or secure file upload.
Astaro??? Keithy confused now. Was is loss, Astaro?. (Don't answer that, I know what it is but have never used it). My reply was based on connecting to a centos based server.
So I followed my working 'instructions'.
I used:
/usr/bin/ssh-keygen -X -f ~/.ssh/identity.pub >> ~/.ssh/authorized_keys2
and that worked fine on astaro, but not here. So I changed ..._keys2 to ..._keys and no help.
Oh, identity.pub was created with:
cat > ~/.ssh/identity.pub
<copy clipboard that has public key in it> CNTL+D
Possibility of the clipboard corrupting the copied text? Adding newlines where they didn't exist before? Personally I copy .pub with scp to the destination host
Of course I don't know what the -X option does. My debian friend gave me that command structure...
man ssh-keygen does even list -X as an option. Maybe it's particular to that Debian distribution?
At 06:42 PM 1/10/2006, Keith Morse wrote:
Robert Moskowitz wrote:
At 04:58 PM 1/10/2006, Keith Morse wrote:
And the cheap way I do this is either "ssh-keygen -t dsa" or "ssh-keygen -t rsa" which creates the directory structure every time, and consistenly too.
Now I really believe I have something configured wrong....
On my Astaro firewall, I had to create everything manually. As it does not have a Unix adduser or secure file upload.
Astaro??? Keithy confused now. Was is loss, Astaro?. (Don't answer that, I know what it is but have never used it). My reply was based on connecting to a centos based server.
Just that with my Astaro, since v 3 up to my current v6, I have done this. And since Astaro is based on Linux, and is using OpenSSH, what was my problem with Astaro.
Well it seems that permissions was a big part of it.
Of course I don't know what the -X option does. My debian friend gave me that command structure...
man ssh-keygen does even list -X as an option. Maybe it's particular to that Debian distribution?
I noticed that while digging into all of this. I will ask him when I get home, and also do some testing without it!
Actually, considering how long ago we first worked this out, it might be an SSH1 vestige that still works.
Robert Moskowitz wrote:
At 06:42 PM 1/10/2006, Keith Morse wrote:
Robert Moskowitz wrote:
At 04:58 PM 1/10/2006, Keith Morse wrote:
And the cheap way I do this is either "ssh-keygen -t dsa" or "ssh-keygen -t rsa" which creates the directory structure every time, and consistenly too.
Now I really believe I have something configured wrong....
On my Astaro firewall, I had to create everything manually. As it does not have a Unix adduser or secure file upload.
Astaro??? Keithy confused now. Was is loss, Astaro?. (Don't answer that, I know what it is but have never used it). My reply was based on connecting to a centos based server.
Just that with my Astaro, since v 3 up to my current v6, I have done this. And since Astaro is based on Linux, and is using OpenSSH, what was my problem with Astaro.
Well it seems that permissions was a big part of it.
Of course I don't know what the -X option does. My debian friend gave me that command structure...
man ssh-keygen does even list -X as an option. Maybe it's particular to that Debian distribution?
I noticed that while digging into all of this. I will ask him when I get home, and also do some testing without it!
Actually, considering how long ago we first worked this out, it might be an SSH1 vestige that still works.
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
.
I would recommend....AND it is recommended to create RSA keys instead of DSA keys for ssh key-pairs
At 09:39 PM 1/10/2006, Keith Morse wrote:
Chris Weisiger wrote
I would recommend....AND it is recommended to create RSA keys instead of DSA keys for ssh key-pairs
If I may ask, why is that ?
It has a bit to do with how DSA (and DSS) works compared to RSA.
I would have to dig out some old papers by the likes of Schneier, Demmings, Fergeson (I knwo I am mispelting all of their names! But, hey, I AM dyslectic) to put together a reasonable case.
We (the IETF) did DSA and DSS/DH more because we had to until the RSA patent expired.
At 08:46 PM 1/10/2006, Chris Weisiger wrote:
I would recommend....AND it is recommended to create RSA keys instead of DSA keys for ssh key-pairs
Considering my position in the security community, I REALLY need to get with the program and get current!
I did have to design HIP around DSA, originally, but now it has shifted to RSA.....
At 02:29 PM 1/10/2006, =?ISO-8859-2?Q?Maciej_=AFenczykowski?= wrote:
the server file /home/username/.ssh/authorized_keys must contain a line containing /home/username/.ssh/id_dsa.pub (use ssh-keygen -t dsa to generate it)
hmmm.
First the directory on my system is /home/<user>/.ssh2
There I have two files:
authorization <user>.pub
and authorization contains one line:
key <user>.pub
Furthermore /etc/ssh/sshd_config must not have PubkeyAuthentication no (yes is the default) [if you delete it remember to /etc/init.d/sshd restart]
I saw a line of #PubkeyAuthentication yes
which I uncommented and restarted. No difference, so I suspect you are right about yes being the default...
ah, I just found the following:
# The strategy used for options in the default sshd_config shipped with # OpenSSH is to specify options with their default value where # possible, but leave them commented. Uncommented options change a # default value.
:)
and what do I do with the section that says:
# For this to work you will also need host keys in /etc/ssh/ssh_known_hosts #RhostsRSAAuthentication no # similar for protocol version 2 #HostbasedAuthentication no # Change to yes if you don't trust ~/.ssh/known_hosts for # RhostsRSAAuthentication and HostbasedAuthentication #IgnoreUserKnownHosts no # Don't read the user's ~/.rhosts and ~/.shosts files #IgnoreRhosts yes
thanks
If this is a Centos4 system with standard ssh with which noone has played (mucked) around with then the directory structure should be as I said.
On Tue, 10 Jan 2006, Robert Moskowitz wrote:
At 02:29 PM 1/10/2006, =?ISO-8859-2?Q?Maciej_=AFenczykowski?= wrote:
the server file /home/username/.ssh/authorized_keys must contain a line containing /home/username/.ssh/id_dsa.pub (use ssh-keygen -t dsa to generate it)
hmmm.
First the directory on my system is /home/<user>/.ssh2
There I have two files:
authorization <user>.pub
and authorization contains one line:
key <user>.pub
Furthermore /etc/ssh/sshd_config must not have PubkeyAuthentication no (yes is the default) [if you delete it remember to /etc/init.d/sshd restart]
I saw a line of #PubkeyAuthentication yes
which I uncommented and restarted. No difference, so I suspect you are right about yes being the default...
ah, I just found the following:
# The strategy used for options in the default sshd_config shipped with # OpenSSH is to specify options with their default value where # possible, but leave them commented. Uncommented options change a # default value.
:)
and what do I do with the section that says:
# For this to work you will also need host keys in /etc/ssh/ssh_known_hosts #RhostsRSAAuthentication no # similar for protocol version 2 #HostbasedAuthentication no # Change to yes if you don't trust ~/.ssh/known_hosts for # RhostsRSAAuthentication and HostbasedAuthentication #IgnoreUserKnownHosts no # Don't read the user's ~/.rhosts and ~/.shosts files #IgnoreRhosts yes
thanks
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Tue, Jan 10, 2006 at 11:29:57PM +0100, Maciej Żenczykowski wrote:
the server file /home/username/.ssh/authorized_keys must contain a line containing /home/username/.ssh/id_dsa.pub (use ssh-keygen -t dsa to generate it)
id_dsa.pub should go to .ssh/authorized_keys2
authorized_keys is for RSA keys.
[]s
- -- Rodrigo Barbosa rodrigob@suespammers.org "Quid quid Latine dictum sit, altum viditur" "Be excellent to each other ..." - Bill & Ted (Wyld Stallyns)
Rodrigo Barbosa wrote:
On Tue, Jan 10, 2006 at 11:29:57PM +0100, Maciej {enczykowski wrote:
the server file /home/username/.ssh/authorized_keys must contain a line containing /home/username/.ssh/id_dsa.pub (use ssh-keygen -t dsa to generate it)
id_dsa.pub should go to .ssh/authorized_keys2
authorized_keys is for RSA keys.
Again, isn't this deprecated for the newer versions of openssh?
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Tue, Jan 10, 2006 at 07:00:13PM -0800, Keith Morse wrote:
Rodrigo Barbosa wrote:
On Tue, Jan 10, 2006 at 11:29:57PM +0100, Maciej {enczykowski wrote:
the server file /home/username/.ssh/authorized_keys must contain a line containing /home/username/.ssh/id_dsa.pub (use ssh-keygen -t dsa to generate it)
id_dsa.pub should go to .ssh/authorized_keys2
authorized_keys is for RSA keys.
Again, isn't this deprecated for the newer versions of openssh?
Might be, but it is still the crossimplementation standards (openssh, f-secure ssh etc).
- -- Rodrigo Barbosa rodrigob@suespammers.org "Quid quid Latine dictum sit, altum viditur" "Be excellent to each other ..." - Bill & Ted (Wyld Stallyns)
At 06:46 PM 1/10/2006, Rodrigo Barbosa wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Tue, Jan 10, 2006 at 11:29:57PM +0100, Maciej Żenczykowski wrote:
the server file /home/username/.ssh/authorized_keys must contain a line containing /home/username/.ssh/id_dsa.pub (use ssh-keygen -t dsa to generate it)
id_dsa.pub should go to .ssh/authorized_keys2
authorized_keys is for RSA keys.
Well it is working with authorized_keys with DSA. I will just change it to _keys2 and see what that does!
Robert Moskowitz wrote:
I am away from my office for the week. In Sacramento for the IEEE 802.1 interim meeting (for anyone in the neighborhood...).
And I am working on SSH with my Centos install(s).
- For right now I am using my XP drive with Tectia client. I have
SSHed into my Centos server using password method and uploaded my public key and such. I see everything there. I think. I then delete all authentication methods but public key and am told that no recognized authentication match. When I add password back into my client, I get the password authentication method.
I would generate a key "ssh-keygen -t rsa" on a linux machine, cp to the server, cat id_rsa.pub>>.ssh/authorized_keys2 and see if that gets the job done. The windows machine adds additional complexity that is hard to debug, get the linux part working first. Make sure the permissions are correct in ~/.ssh/ , that is very important. .ssh/authorized_keys2 must be 0600.
drwx------ 2 root root 4096 Jan 11 2004 . drwxr-x--- 27 root root 4096 Jan 6 12:10 .. -rw------- 1 root root 580 Jan 3 2005 authorized_keys -rw------- 1 root root 2982 Apr 25 2005 authorized_keys2 -rw------- 1 root root 672 Jan 11 2004 id_dsa -rw-r--r-- 1 root root 613 Jan 11 2004 id_dsa.pub -rw------- 1 root root 538 Jan 11 2004 identity -rw-r--r-- 1 root root 342 Jan 11 2004 identity.pub -rw-r--r-- 1 root root 6998 Dec 29 11:44 known_hosts
-
Chris Mason (Lists) -
Chris Weisiger -
Jay Leafey -
Johnny Hughes -
Keith Morse -
Maciej Żenczykowski -
Paul Heinlein -
Robert Moskowitz -
Rodrigo Barbosa -
Tony Schreiner