Koozali.org: home of the SME Server
Obsolete Releases => SME Server 7.x => Topic started by: beast on June 14, 2009, 08:39:47 AM
-
Hi
Seam to have made some errors with my installation :smile:
I have tried to execute the command in this link to generate a new ssh key pair:
http://wiki.contribs.org/SSH_Public-Private_Keys
this section
It is possible to use the SME Server itself to generate the public-private key pairs. This is done by using ssh-keygen. By default the pair is written to $HOME/.ssh/id_rsa and $HOME/.ssh/id_rsa.pub
ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/home/e-smith/files/users/dummy/.ssh/id_rsa): [Enter to accept default]
Created directory '/home/e-smith/files/users/dummy/.ssh'.
Enter passphrase (empty for no passphrase): [Your passphrase]
Enter same passphrase again: [Your passphrase]
Your identification has been saved in /home/e-smith/files/users/dummy/.ssh/id_rsa.
Your public key has been saved in /home/e-smith/files/users/dummy/.ssh/id_rsa.pub.
The key fingerprint is:
aa:bb:cc:dd:ee:ff:aa:bb:cc:dd:ee:ff:aa:bb:cc:dd dummy@gatekeeper
Now I am unable to make a putty connection to my server :sad:
How do I restore the normal configuration?
Thank you in advance
Benny
-
You did follow this section (http://wiki.contribs.org/SSH_Public-Private_Keys#Installing_the_Private_Key_onto_the_Clients (http://wiki.contribs.org/SSH_Public-Private_Keys#Installing_the_Private_Key_onto_the_Clients)) as well?
-
You did follow this section (http://wiki.contribs.org/SSH_Public-Private_Keys#Installing_the_Private_Key_onto_the_Clients (http://wiki.contribs.org/SSH_Public-Private_Keys#Installing_the_Private_Key_onto_the_Clients)) as well?
I think i more ask about how to restore the normal behavior of SME :smile:
-
I think i more ask about how to restore the normal behavior of SME :smile:
Yes I know, but most of the time less SME Server wise people ask questions not knowing the full detail, I wonder why you would revert it. Besides I expect you got locked out by not following the complete instruction and would be better of completing the instructions as you have a more secure setup than reverting it.
Reverting it would mean you will need to restore your remote access settings back to default, remove your generated private key and restart your sshd daemon AFAIK, but I never had to revert as when I follow the complete instruction I did not get locked out.
To revert or complete the procedure you will at least need physical access to the machine since your remote connection is not available to you at the moment.
-
Yes I know, but most of the time less SME Server wise people ask questions not knowing the full detail, I wonder why you would revert it. Besides I expect you got locked out by not following the complete instruction and would be better of completing the instructions as you have a more secure setup than reverting it.
Reverting it would mean you will need to restore your remote access settings back to default, remove your generated private key and restart your sshd daemon AFAIK, but I never had to revert as when I follow the complete instruction I did not get locked out.
To revert or complete the procedure you will at least need physical access to the machine since your remote connection is not available to you at the moment.
I know I need physical access to the machine and this is no problem. If I really like to get back to the standard setup - how do I do it?
I am unable to find a procedure anywhere! Properly I just need to delete some files and move some templates and then reboot, but I do not like to do it in the dark :grin:
-
beast
You want an answer from "us" but at this stage "we" do not know what the problem is.
Just generating the key pair will not prevent ssh access.
Please provide more details of what you have done, ie did you follow the whole Howto, did you configure Putty to use the new key, what errors do you get and when do you get them etc etc.
Here is a possible answer.
If you have disabled ssh access using password (in server manager), and you cannot access via ssh using the key you created, then simply enable password access and login via Putty using the normal root password.
-
beast
You want an answer from "us" but at this stage "we" do not know what the problem is.
Just generating the key pair will not prevent ssh access.
Please provide more details of what you have done, ie did you follow the whole Howto, did you configure Putty to use the new key, what errors do you get and when do you get them etc etc.
Here is a possible answer.
If you have disabled ssh access using password (in server manager), and you cannot access via ssh using the key you created, then simply enable password access and login via Putty using the normal root password.
OK :smile:
I have been testing SSH key pairs some while back. Also had it up and running!
Then I wanted to revert to the standard scheme. I have another server and I compared what the diff was and tried to get it back to normal by deleting SSH files etc. (know it is dangerous). Then I ended up with a working system, the only problem was that I had a cron job starting the key generation:
/etc/cron.daily/conf-mod_ssl:
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
Then I looked into the "how to" to try and get out of this situation and it do seam to work. The only problem is that putty now comes up with the error "Server unexpectedly closed network connection". I have the option to allow normal password access enabled in the server-manager.
Thank you for any hint.
-
beast
Did you remove the "Private key file for authentication" setting under SSH Auth in Putty (& Save the config) ?
Is the port setting the same in sme server & in putty ie 22 or 2222 etc.
In server manager is
"Secure shell access" set to Allow public access...
"Allow administrative command line..." set to YES
"Allow secure shell using"... set to YES
-
/etc/cron.daily/conf-mod_ssl:
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
Then I looked into the "how to" to try and get out of this situation and it do seam to work.
That has nothing to do with your SSH private/public keys, it is the server certificate used for encryption when connecting over a SSL protected connection (like https/imaps).
The only problem is that putty now comes up with the error "Server unexpectedly closed network connection". I have the option to allow normal password access enabled in the server-manager.
Most likely because either your server is expecting a certificate and you are not providing one, or the other way around, you are providing a certificate where your server is not expecting one.
-
beast
Did you remove the "Private key file for authentication" setting under SSH Auth in Putty (& Save the config) ?
Is the port setting the same in sme server & in putty ie 22 or 2222 etc.
In server manager is
"Secure shell access" set to Allow public access...
"Allow administrative command line..." set to YES
"Allow secure shell using"... set to YES
Yes to all the settings in server manager and there is no Private key file for authentication in Putty
-
That has nothing to do with your SSH private/public keys, it is the server certificate used for encryption when connecting over a SSL protected connection (like https/imaps).
This also explain why I need to approve a certificate every time I access server manager - but how do I get it back to normal?
Most likely because either your server is expecting a certificate and you are not providing one, or the other way around, you are providing a certificate where your server is not expecting one.
Agreed - but is there some way to restore the standard behavior - as far as I can see putty have quite a standard configuration and then it must be SME
-
This also explain why I need to approve a certificate every time I access server manager - but how do I get it back to normal?
No it does not, as SME Server generates a self signed certificate that is not signed by a trusted authority, like VeriSign for instance, you will always receive a notification on the certificate. You can however explicitly say you trust the certificate, which will prevent the pop-up, by manually installing it on the OS/browser/e-mailclient.
Agreed - but is there some way to restore the standard behavior - as far as I can see putty have quite a standard configuration and then it must be SME
Are you sure you are not using a pre-configured connection in PuTTy that still has the private key part assigned to it?
-
No it does not, as SME Server generates a self signed certificate that is not signed by a trusted authority, like VeriSign for instance, you will always receive a notification on the certificate. You can however explicitly say you trust the certificate, which will prevent the pop-up, by manually installing it on the OS/browser/e-mailclient.
Normal behavior is as far that I remember that I only has to do this ones then the browser save the information (also the case for the other server I have). For this problem server I have to approve the certificate every time I access the server manager? (I do tell it to remember the approval)
Are you sure you are not using a pre-configured connection in PuTTy that still has the private key part assigned to it?
Yes I have tried to key in the IP address directly (do not press load)
-
beast
...tried to get it back to normal by deleting SSH files etc.
Perhaps your default self signed cert has not been recreated.
Did you follow the above steps with
signal-event post-upgrade
signal-event reboot
PS A little search would have found this, took me 3 seconds.
http://forums.contribs.org/index.php/topic,43960.0.html
and this
http://wiki.contribs.org/Certificates_Concepts
-
Hi.
I have had some of the same problems with Putty.
And it seems, that Putty is not able to handle OpenSSH keys to the SME server.
So instead of using Putty, we use the OpenSSH package for windows with cygwin, and that works.
Loejf.
-
http://sourceforge.net/project/downloading.php?group_id=103886&filename=setupssh381-20040709.zip&a=76605850
-
Hi.
I have had some of the same problems with Putty.
And it seems, that Putty is not able to handle OpenSSH keys to the SME server.
So instead of using Putty, we use the OpenSSH package for windows with cygwin, and that works.
Loejf.
Correct, and that is why the wiki article, which all started this, tells you to convert your OpenSSH key to be used with PuTTy: http://wiki.contribs.org/SSH_Public-Private_Keys#Converting_the_OpenSSH_Private_Key_to_work_with_PuTTY
-
OK - for the mean time I have been using the keyboard directly connected to the server so this thread was not acted upon until now.
Now I really need to get this up and running - I have read everything in this thread carefully again (somebody will properly tell me in the next couple of post that it was not good enough).
I need to get back to default behavior (SSH/Certificate etc.)
I have tried
rm /home/e-smith/ssl.crt/servername.domain.com.crt
rm /home/e-smith/ssl.key/servername.domain.com.key
rm /home/e-smith/ssl.pem/servername.domain.com.pem
signal-event post-upgrade
signal-event reboot
With no luck! I have tried to connect from an Ubuntu box
benny@benny-desktop:~$ ssh admin@192.168.1.11 -v
OpenSSH_5.1p1 Debian-5ubuntu1, OpenSSL 0.9.8g 19 Oct 2007
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to 192.168.1.11 [192.168.1.11] port 22.
debug1: Connection established.
debug1: identity file /home/benny/.ssh/identity type -1
debug1: identity file /home/benny/.ssh/id_rsa type -1
debug1: identity file /home/benny/.ssh/id_dsa type -1
ssh_exchange_identification: Connection closed by remote host
But it do seam as if the server just reject all identity types!
Any help is really appreciated :smile:
Thank you!
-
It must be related to the daily cron job that seam to make an error - E.g.
/etc/cron.daily/conf-mod_ssl:
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [GB]:State or Province Name (full name) [Berkshire]:Locality Name (eg, city) [Newbury]:Organization Name (eg, company) [My Company Ltd]:Organizational Unit Name (eg, section) []:Common Name (eg, your name or your server's hostname) []:Email Address []:
What this script does is to exec expand-template /home/e-smith/ssl.pem/pem
when I try to execute "sh conf-mod_ssl" it shows the same text and return me right to the prompt. When I write "expand-template /home/e-smith/ssl.pem/pem" directly at the command line is terminate the current session or start another - I am back to the login screen again!
This may help in debugging the situation!
-
I have tried
rm /home/e-smith/ssl.crt/servername.domain.com.crt
rm /home/e-smith/ssl.key/servername.domain.com.key
rm /home/e-smith/ssl.pem/servername.domain.com.pem
signal-event post-upgrade
signal-event reboot
With no luck!
Those certificates have absolutely nothing to do with SSH. Those are SSL certiificates, used for https, imaps and smtps access.
It is unsurprising that your actions here haven't helped with ssh access.
-
Those certificates have absolutely nothing to do with SSH. Those are SSL certiificates, used for https, imaps and smtps access.
It is unsurprising that your actions here haven't helped with ssh access.
Yes I know - but I am beginning to try almost anything :smile:
-
When I try to make a SSH connection from another computer I get this in the log:
Aug 2 21:02:04 beastserver sshd: refused connect from benny.beast.dk (192.168.1.200)
but there is nothing in /var/log/sshd/current ???
-
is your SME's lan address 192.168.1.X?
Stefano
-
is your SME's lan address 192.168.1.X?
Yes the server is 192.168.1.11 and the client is 192.168.1.200
-
This is really strange!
Some times I am able to access the server with putty and sometimes not (many days between the shifts).
This really makes me wonder what is the cause of this ?????
I can not see that I do anything that may trigger the shift!
It is just a private server with no big activity but I also have company servers that have SME server installed and because of this I like to find out about this!
In hope for a solution?
-
Think I have found out why I get this random access with Putty !!
It is because the contrib "SSH denyhosts" is blocking my computer that are on the internal network?????
How is this possible? Has it something to do with the SSH Public-Private Keys that I did not finish?
Regards
Benny
-
beast
> It is because the contrib "SSH denyhosts" is blocking my computer that are on the internal network?????
According to the Wiki article:
Denyhosts bans hosts which failed too many login attempts to your ssh deamon.
It contains also a panel in the server manager to see who is blocked, add some allowed hosts not to block and enable or disable the service.
I suggest you totally remove that contrib (and any configuration).
-
I suggest you totally remove that contrib (and any configuration).
or, at least, to read the wiki and the infos in the panel :-)
-
The funny thing is that I have not have made error attemps to log in. Eg. do not supply the wrong password and still I end up on the blocked list - this make me wonder ??? Hacker or.....
I have other servers where this problem do not occur!
Now I have stated that my IP shall never be blocked.
Would be nice if the contrib made a more descriptive message in the log
Regards
Benny
-
Would be nice if the contrib made a more descriptive message in the log
if this contrib is in smecontribs repo then open a nfr in bugzilla, otherwise send a mail to the rpm's mantainer