I have upgraded 3 servers from SSH Tectia 4.0.3 to SSH Tectia 6.0.2. 2 of them are working fine but one server suddenly began to have troubles after about 2 hours. Now it is impossible to login to this server using SSH and even telnet. When SSH is running on this particular server, the CPU of the server is at it's maximum because of the SSH processes, which is not the case on the other 2 servers. Currently I have shut down the SSH processes on the server.
Then, when I try to make a connection using telnet it immediatly replies: 'Connection closed'. The strange fact however is that telnet refuses a connection done by the root user, but if I try it using another user, telnet works fine. (SSH doen't work in either case though) Restarting and even reinstalling SSH also didn't work. After SSH was uninstalled I tried another telnet connection but still it didn't work.
I've checked /etc/security/user, because of the telnet/root problem, but everything looks identical to the configuration of the other 2 servers. Can anyone help me with this problem?
I have removed the new SSH version and replaced it again with the old version. Some of the problems are fixed. SSH is possible again, but not for the root user. Telnet also works but again, not for the root user.
When trying a SSH connection as root the following error occures:
Authentication successful.
Received signal 11. (no core)
After this error the connection failes again. Does anyone has an idea of what this problem might be?
From inside the server I can connect to the outside with ssh as root. Strangely enough from the outside it is impossible to enter that server with both ssh or telnet as root. It's like root has no permission to enter that particular server.
Everytime I try to connect the following error occures: Received signal 11. (no core). The authentication however does succeed.
Here's the output of using ssh -v:
warning: Development-time debugging not compiled in.
warning: To enable, configure with --enable-debug and recompile.
debug: Ssh2/ssh2.c:1848: User config file not found, using defaults. (Looked for '//.ssh2/ssh2_config')
debug: Connecting to server1, port 22... (SOCKS not used)
debug: client supports 3 auth methods: 'publickey,keyboard-interactive,password'
debug: Remote version: SSH-2.0-4.0.5.5 SSH Secure Shell
debug: Major: 4 Minor: 0 Revision: 5
debug: SshProtoTransport/trcommon.c:1464: lang s to c: `', lang c to s: `'
debug: SshProtoTransport/trcommon.c:1530: c_to_s: cipher aes128-cbc, mac hmac-sha1, compression none
debug: SshProtoTransport/trcommon.c:1533: s_to_c: cipher aes128-cbc, mac hmac-sha1, compression none
debug: Remote host key found from database.
debug: server offers auth methods 'publickey,password'.
debug: Ssh2AuthPubKeyClient/authc-pubkey.c:1733: Starting pubkey auth...
debug: SshUnixUserFiles/sshunixuserfiles.c:354: Using '//.ssh2/identification' as identity file.
debug: Constructing and sending signature in publickey authentication.
debug: Ssh2AuthPubKeyClient/authc-pubkey.c:725: reading private key //.ssh2/id_server1
debug: Ssh2AuthPubKeyClient/authc-pubkey.c:1822: Public key authentication was successful.
Authentication successful.
Received signal 11. (no core)
debug: Got session close with exit_status=255
Connection to server1 closed.
And yes it's fine if you export it to the AIX group.
Another fact I forgot to mention:
If I try "ssh server1" it fails.
If i try "ssh server1 ls", strangely enough it works...
So root can in fact connect to that server, but just can't logon to it.
Never heared from SSH Tectia. Just was at their site...
Maybe it is no big help, but why not use the ssh/sshd that comes with AIX 5.3 for free???
Else you might check if the sshd_config or if something similar exists with that kind of sshd contains something awkward compared to those of the boxes that work.
Does this Tectia sshd write some log? Something in your errpt?
Well Tectia SSH was allready in use when I arrived but I believe it offers a higher security level. I've also checked a couple of config files such as sshd2_config and compared them with other boxes, however everything seems to be correct, including the permissions.
I've also checked the /dev/random and also there the permissions are correct. I've also checked the .profile of the root user on the problemserver and nothing seems wrong with it, but still root cannot logon to that server. It's like he doesn't have a shell to work on it. The strange thing is that if I try the ssh command followed by another command such as 'ls', it works... But login into the server is impossible.
I can however use the root user on the server, but first I have to logon to the server with another user and afterwards login in as root.
When I do ssh -d 5 server1 (server1 is the problemserver) this is a part of the output:
16/10/2008 09:07:22:744 SecShBrokerCom/secshbrokercom.c:608: Failed to connect to broker socket `/tmp/ssh-root/ssh-broker'.
16/10/2008 09:07:22:744 SecShBrokerCom/secshbrokercom.c:710: Error in creating connection to broker.
16/10/2008 09:07:22:744 SecShBrokerCom/secshbrokercom.c:1065: Shutting down, status 5.
16/10/2008 09:07:22:744 SshSecShBroker/secsh_broker.c:1927: com_create status: error: 2, com err: 2.
16/10/2008 09:07:22:744 SshSecShBroker/secsh_broker.c:1933: Broker is not running.
16/10/2008 09:07:22:745 SecShBrokerCom/secshbrokercom.c:608: Failed to connect to broker socket `/tmp/ssh-root/ssh-broker'.
16/10/2008 09:07:22:745 SecShBrokerCom/secshbrokercom.c:710: Error in creating connection to broker.
16/10/2008 09:07:22:745 SecShBrokerCom/secshbrokercom.c:1065: Shutting down, status 5.
16/10/2008 09:07:22:745 SshSecShBroker/secsh_broker.c:1843: com_create status: error: 2, com err: 2.
16/10/2008 09:07:22:745 SshSecShBroker/secsh_broker.c:1693: Starting broker.
16/10/2008 09:07:22:745 SecShUserProcess/secsh_user_process_unix.c:1026: Executing command `/opt/tectia/libexec/ssh-broker-cli -D "5" --slave --run-on-demand --check-accession --no-gui': process 20125288 (params: allocate-pty: FALSE, support-handle-passing: TRUE, dont-inherit-handles: FALSE, force-hide-application: FALSE, chroot=(null), ulimit=(null), umask=(null), no-path-expand=TRUE, use-sigterm-instead-of-sigint=TRUE, let-live=TRUE, new-pgrp=TRUE, exec-directly=TRUE,use-shell-shell-exe=FALSE).
16/10/2008 09:07:22:745 SecShUserProcess/secsh_user_process_unix.c:1049: No environment given -> passing parent process environment.
16/10/2008 09:07:22:745 SecShUserProcess/secsh_user_process_unix.c:433: argv[0] = /opt/tectia/libexec/ssh-broker-cli.
16/10/2008 09:07:22:745 SecShUserProcess/secsh_user_process_unix.c:433: argv[1] = -D.
16/10/2008 09:07:22:746 SecShUserProcess/secsh_user_process_unix.c:433: argv[2] = 5.
16/10/2008 09:07:22:746 SecShUserProcess/secsh_user_process_unix.c:433: argv[3] = --slave.
16/10/2008 09:07:22:746 SecShUserProcess/secsh_user_process_unix.c:433: argv[4] = --run-on-demand.
16/10/2008 09:07:22:746 SecShUserProcess/secsh_user_process_unix.c:433: argv[5] = --check-accession.
16/10/2008 09:07:22:746 SecShUserProcess/secsh_user_process_unix.c:433: argv[6] = --no-gui.
debug: 16/10/2008 09:07:22:764 SshNioDispatcher/sshnio_dispatcher_unix.c:1363: Creating 4 threads.
16/10/2008 09:07:22:765 SecShBrokerCom/secshbrokercom.c:661: Verifying broker saneness.debug: 16/10/2008 09:07:22:766 Broker/broker.c:3501: Broker address: /tmp/ssh-root/ssh-broker
debug: 16/10/2008 09:07:22:766 SecshUserFiles/secsh_user_files.c:227: real path: root
debug: LOG EVENT (discard,notice): 6100 Broker_starting, Local username: root
debug: 16/10/2008 09:07:22:810 SshEKSoft/softprovider.c:4269: softkey; init-string use_proxy(), directory(path(//.ssh2/)) passphrase_timeout(0) passphrase_idle_timeout(0)
debug: 16/10/2008 09:07:22:811 SshEKSoft/softprovider.c:2850: Hard passphrase timeout 0 seconds.
debug: 16/10/2008 09:07:22:811 SshEKSoft/softprovider.c:2868: Idle passphrase timeout 0 seconds.
debug: 16/10/2008 09:07:22:811 SecShKeyStore/secsh_keystore.c:1619: Provider software://0/ added.
debug: 16/10/2008 09:07:22:815 SshUserFiles/sshkeyblob2.c:391: Failed to match header.
debug: 16/10/2008 09:07:22:815 SshUserFiles/sshkeyblob2.c:391: Failed to match header.
debug: 16/10/2008 09:07:22:815 SshPKB/openssh2pubkey.c:135: SSH1 public key decode failed: Key format was corrupted.
debug: 16/10/2008 09:07:22:815 SecShKeyStore/secsh_keystore.c:574: Waiting for provider software://0/ to scan all keys..
debug: 16/10/2008 09:07:22:815 SshUserFiles/sshkeyblob2.c:391: Failed to match header.
debug: 16/10/2008 09:07:22:815 SshPKB/openssh2pubkey.c:135: SSH1 public key decode failed: Key format was corrupted.
The 'host_last_login' is kind of strange though because every server is listed, normally there is only 1 or so? It's like every server tried to connect at the same time, not certain though if it has anything to do with the problem.
To cut a long story short: if you did not change anything with root environment settings after Tue Oct 14 09:58:41 2008 (your localtime) there is nothing wrong with this user or the operating system. I'd suggest you uninstall that ssh software completely and install from scratch.
Somewhere up in the thread you mention that that Tectia ssh software is being used because it was somewhat more secure than OpenSSH. If nobody at your datacenter can name exactly where this additional security compared to the current version of OpenSSH is you might consider using OpenSSH instead. Reason is that you will get faster and better response to questions related to a product that is widely used compared to some niche product.
I checked with a colleague who happened to know the Tectia product: the difference is that normal ftp can provide a chrooted environment for every user, but the sftp can't do that, at least not out of the box, while Tectias sftp does have this functionality.
This might be perceived as being "more secure" to people who have no idea at all how ftp really works, which is, sad to say, quite often the case in auditing teams who in turn come up with some some "security-enhancement" which in fact is just plain silliness. I have once heard a default umask of 777 mentioned as desirable from such folk. Its usually the administrators who have to suffer from these, ahem, ideas.
Sorry, this won't help you with your problem but now i feel some relief. ;-))
bakunin
PS: I strongly suggest that you find out if this functionality is really needed at all in your case and if it isn't (which is most likely the case) you switch to openSSL products as suggested by Neo and shockneck. And i hop this helps.
Thanks for the replies. I think that the root user doesn't use his .profile and /etc/profiles files and therefore can't login to the server. All of the permissions however are correct (just like in other boxes). I've checked many things together with my collegue but nothing came out of it. It's a very strange error in the system..
I'm not sure of this particular version/type of ssh.. I use open ssh on AIX.. have u tried checking the entries in /etc/ssh/sshd_config?
in a fully implemented ssh environment, there should be a user@server entry under the AllowUsers key?. If you make a change to this file, the ssh demon needs a restart too.
Have you tried setting the permission of your /home to 700.? I have strange encounters with ssh that user root can't login. Tried setting world writeable to 777 but it doesnt work. Tried 700 and the systems works.
