Hi everyone!
I’ve got a big problem .
I tried to login into linux via ssh protocol using RSA keys.
So I made in putty on windows pairs of keys: public and private, then i copy ( ctrl +a) text and copy that to /home/myuser/.ssh/authorized_keys.
What about chmod: .ssh - 700 / authorized_keys - 600.
I generated keys in puttygen, but when was trying to log into my serwer( with linux) putty showed up with an error message : server refuse our key.
Its anyone here with idea what am i doing wrong?
P.S I was trying to copy public key via WinSCP from windows to linux but it still isnt working. Maybe i have to change authorized_keys file ?
Pls help meeee i dont have any more idea how to make it works…
Haven’t tried exactly what you’re doing but here are some personal observations
Although generating client keys and then importing into a Server might work, but I typically do it the other way around… Export the public key from the server, then import into the client
I don’t know what might happen as you’ve described, some issues that come to mind are what security context you’d expect simply copying a public key to the server… If you had successfully logged in, what User account did you expect to be assigned? What keyrings (cert repos) are being used? And so on…
Is there some reason why you’re configuring PKI? Generally, encrypted connections support a number of different architectures, you might find configuring a “shared secret” or for that matter simply logging in with an openSUSE account easier.
> - Although generating client keys and then importing into a Server
> might work, but I typically do it the other way around… Export the
> public key from the server, then import into the client
I know this is kinda off-topic, but this (generating keys on the client
and setting them on the server) is the ONLY way to do this correctly.
You referred to exporting the public key from the server and then
importing it into the client, and while this likely works it is
backwards. The public key goes out there on every box to which you want
to have access, and the private key is kept privately on systems that
will be getting access to the systems with the public key. The public
key you can put in your e-mail footer for everybody to conveniently add
to their system, but the private key must never leave your control as it
is your password. Generating keys on a server means your private key is
probably somewhere it does not belong since anybody with ‘root’ access
to the server will be able to take your private key (in your case what
you referred to as the public key) and now have access to every system
where you have access, and they’ll have that access as you. You are
basically setting your password on the server and leaving it there for
others to grab.
Going back to the topic of this thread, if this were Linux on the client
side I’d say to enable verbose mode, and maybe Putty has something
similar. Maybe check the server’s /var/log/messages just for fun,
though I doubt you’ll find what you’re after. Another fun test,
generate a key on a Linux workstation and copy over the public key
(ssh-copy-id command) and see if Linux to Linux works.
Good luck.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
No, you should generate keys on the client side and copy them to the server.
As a special note for Putty: I’ve never been able to get it working with
a key from a Linux box… probably just a different format, but it’s
annoying and I don’t use windows so I haven’t pursued it. If Putty is
on Linux then maybe it uses the same format as everything else that can
handle SSH, but it may use the other format and in that case the Linux
keys still need to come from Putty’s key-generation thingy, or they need
to be converted somehow for Putty to like them.
If I were doing this I would test from a Linux workstation to the Linux
server first with keys generated on the Linux workstation; just be sure
that the server side is working. After that, fight with Putty.
Good luck.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
I’m sure what ab recommends is correct, you should generate keys on the client. It’s true that I’ve generally allowed access only to trusted users with root permissions, IMO “regular” User permissions are unsatisfactory since they generally only restrict write and execute… Regular Users can normally read only practically anything on the box they don’t have rights. For non-admin level users I usually only grant access controlled by application level security, eg websites and FTP.
Still, I’ll certainly personally investigate the “recommended” way which is to generate keys client-side.
if you haven’t already fixed this, take a look at the key generated by puttykeygen.exe on your Windows client - if you saved the public key (instead of copy/pasting it from within the PuttyGen window) it will contain extra stuff in there, like this:
---- BEGIN SSH2 PUBLIC KEY ----
Comment: "rsa-key-20120601"
<public key here>
---- END SSH2 PUBLIC KEY ----
remove all this stuff, and remove the LF indicators at the end of each line - in Windows, it will look like one big continuous line if you turn word-wrap off in your text editor. Save this file, SCP it to your Linux host and cat in to the end of your authorized_keys file.
>
>I’m sure what ab recommends is correct, you should generate keys on the
>client. It’s true that I’ve generally allowed access only to trusted
>users with root permissions, IMO “regular” User permissions are
>unsatisfactory since they generally only restrict write and execute…
>Regular Users can normally read only practically anything on the box
>they don’t have rights. For non-admin level users I usually only grant
>access controlled by application level security, eg websites and FTP.
>
>Still, I’ll certainly personally investigate the “recommended” way
>which is to generate keys client-side.
>
>To the op:
>This guide ‘How to Use RSA Key for SSH Authentication - Softpedia’
>(http://tinyurl.com/4k4xaj)
>suggests you’re missing a step, you not only have to upload your key to
>".ssh/id_rsa.pub"
>
>TS
Oh golly. Please study up on the uses and functions of umask and groups.
It is quite capable of decently fine grained access control used
correctly.
Of course ACL is much more thorough.
I have just modified authorized_keys in this way: ( ofc in 1 line) (ssh-rsa [key content]== rsa-key-20120605) and it works, what about chmods: .ssh -700 / authorized_keys -600 . Maybe this will help someone.
8.2.1 Generating a new key 8.2.5 The Key fingerprint' box 8.2.10 Public key for pasting into authorized_keys file’
8.3 Getting ready for public key authentication
We suppose that user “Fred” on “box A” want to connect to his account “chief” on “box B”
A) On Box A - Fred have allready a PUTTY key-pair.
Fred start puttygen on “box A”
load his private key (say fred_id_rsa.ppk)
copy the pub_key content from the `Public key for pasting into authorized_keys file’ field on puttygen window (select + CTRL-C ).
save it to file in your favorite editor ( CTRL-V) (say fred_id_rsa.pub)
append by any mean ( it depends how ssh is configured on “box B” ) the content of fred_id_rsa.pub from “box A” to /home/chief/.ssh/authorized_keys on “box_B”
B) On Box A - Fred have no PUTTY key.
Fred start puttygen on “box A”
Fred generate his key-pair by clicking on the generate button
Execute task from A3 to A5 above.
So there is no need to edit the public key itself.
That ought to work. I assume that the “.ssh/authorized_keys” file is on the server.
You have not indicated how you added your key to authorized_keys. It is important that it be added as one long line. Using a GUI editor that does automatic linewrap is a common way of messing this up.
The permission need not be that restrictive. It is important that only you (and root) can write to authorized keys.
You might also want to check your home directory:
chmod og-w $HOME ## make sure nobody else can write to the home directory.
Also check “/home” and “/” to make sure that they are not group-writable.
If all else is correct - if everything on your path to authorized_keys is not group-writable, and if you added the key as a single line in the authorized_keys file, then the likely explanation is that the server is using a non-standard configuration for its sshd daemon.
i dont have any more idea how to make it works…