I have HP Mini Laptop with SUSE Enterprise Desktop 10. When I try to make a contact to my Ubuntu Server, I can read from the log of my server, that the password has been accepted and a session has been opened for the MyUserName I wrote on my SUSE terminal:
“ssh -l MyUserName MyURL”
But nothing further happens on the SUSE terminal. Only if I kill the session in my server, I get a message that the connection has been closed by the remote host.
The same thing happens with gFTP (using SSH2): I can tell from my server, that a session has been initiated, but no response comes to gFTP.
I know it is not a problem with the server, because I can make a ssh connection with a windows machine (using Putty).
I’m quite new with my SUSE laptop. Is this something to do with the firewall?
What does the client say when this happens? Add the ‘-v’ switch.
The firewall in SUSE is typically very lax on outgoing connections so
personally I really doubt it is the cause here, but who knows. You can
turn it off temporarily with the following command:
sudo /sbin/rcSuSEfirewall2 stop
Good luck.
tikitin wrote:
> I have HP Mini Laptop with SUSE Enterprise Desktop 10. When I try to
> make a contact to my Ubuntu Server, I can read from the log of my
> server, that the password has been accepted and a session has been
> opened for the MyUserName I wrote on my SUSE terminal:
> “ssh -l MyUserName MyURL”
>
> But nothing further happens on the SUSE terminal. Only if I kill the
> session in my server, I get a message that the connection has been
> closed by the remote host.
> The same thing happens with gFTP (using SSH2): I can tell from my
> server, that a session has been initiated, but no response comes to
> gFTP.
>
> I know it is not a problem with the server, because I can make a ssh
> connection with a windows machine (using Putty).
>
> I’m quite new with my SUSE laptop. Is this something to do with the
> firewall? How do I get my hands on the firewall? I’ve tried to find it
> with Yast, but to no avail.
>
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
Looks perfect to me. For comparison this is from my system (SLED 11) to a
SLES 10 system:
<quote>
ab@mybox:~/Desktop> ssh -v ab@myserver
OpenSSH_5.1p1, OpenSSL 0.9.8h 28 May 2008
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to myserver [123.45.67.89] port 22.
debug1: Connection established.
debug1: identity file /home/ab/.ssh/id_rsa type -1
debug1: identity file /home/ab/.ssh/id_dsa type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_4.2
debug1: match: OpenSSH_4.2 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.1
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-cbc hmac-md5 none
debug1: kex: client->server aes128-cbc hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host ‘myserver’ is known and matches the RSA host key.
debug1: Found key in /home/ab/.ssh/known_hosts:5
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,keyboard-interactive
debug1: Next authentication method: publickey
debug1: Trying private key: /home/ab/.ssh/id_rsa
debug1: Trying private key: /home/ab/.ssh/id_dsa
debug1: Next authentication method: keyboard-interactive
Password:
debug1: Authentication succeeded (keyboard-interactive).
debug1: channel 0: new [client-session]
debug1: Requesting no-more-sessions@openssh.com
debug1: Entering interactive session.
debug1: Sending environment.
debug1: Sending env LANG = en_US.UTF-8
</quote>
Was this attempt done with the firewall down? Have you tried taking down
the firewall on the server side just temporarily for a quick test? I’d be
skeptical of that being related on either side but nothing else makes
sense unless you just have a slow-running login script on the server. Try
creating a new user (`useradd -m ab && echo ‘somepassword’ | passwd
–stdin ab`) and then logging in with that user (ab) with the password
(‘somepassword’) and see if that works. Maybe try hitting Ctrl+C once
logged in to cancel any login scripts… if that works you’ll probably be
dropped to an ugly prompt without the user formatting.
Good luck.
tikitin wrote:
> ab@novell.com;1969499 Wrote:
>> What does the client say when this happens? Add the ‘-v’ switch.
>>
>
> OpenSSH_4.2p1, OpenSSL 0.9.8a 11 Oct 2005
> debug1: Reading configuration data /etc/ssh/ssh_config
> debug1: Applying options for *
> debug1: Connecting to renki.ath.cx [91.154.9.46] port 22.
> debug1: Connection established.
> debug1: permanently_set_uid: 0/0
> debug1: identity file /root/.ssh/identity type -1
> debug1: identity file /root/.ssh/id_rsa type -1
> debug1: identity file /root/.ssh/id_dsa type -1
> debug1: Remote protocol version 2.0, remote software version
> OpenSSH_4.7p1 Debian-8ubuntu1.2
> debug1: match: OpenSSH_4.7p1 Debian-8ubuntu1.2 pat OpenSSH*
> debug1: Enabling compatibility mode for protocol 2.0
> debug1: Local version string SSH-2.0-OpenSSH_4.2
> debug1: SSH2_MSG_KEXINIT sent
> debug1: SSH2_MSG_KEXINIT received
> debug1: kex: server->client aes128-cbc hmac-md5 none
> debug1: kex: client->server aes128-cbc hmac-md5 none
> debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
> debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
> debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
> debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
> debug1: Host ‘renki.ath.cx’ is known and matches the RSA host key.
> debug1: Found key in /root/.ssh/known_hosts:1
> debug1: ssh_rsa_verify: signature correct
> debug1: SSH2_MSG_NEWKEYS sent
> debug1: expecting SSH2_MSG_NEWKEYS
> debug1: SSH2_MSG_NEWKEYS received
> debug1: SSH2_MSG_SERVICE_REQUEST sent
> debug1: SSH2_MSG_SERVICE_ACCEPT received
> debug1: Authentications that can continue: publickey,password
> debug1: Next authentication method: publickey
> debug1: Trying private key: /root/.ssh/identity
> debug1: Trying private key: /root/.ssh/id_rsa
> debug1: Trying private key: /root/.ssh/id_dsa
> debug1: Next authentication method: password
> olli@renki.ath.cx’s password:
> debug1: Authentication succeeded (password).
> debug1: channel 0: new [client-session]
> debug1: Entering interactive session.
> debug1: Sending environment.
> debug1: Sending env LANG = fi_FI.UTF-8
>
>
>
> I turned the firewall off using Yast, but it made no difference:
> after “debug1: Sending env LANG = fi_FI.UTF-8” nothing appears.
>
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
I have tried with the firewalls in both machines down. Also tried with a different user.
Hitting Ctrl+C just produces letter “c” after the connection has been closed on the server side (by killing the process).
I still think there can be nothing wrong on the server side, since Putty connects fine from a windows machine. Too bad I don’t have username+password to any other ssh-server, so I could try it. Like I said earlier, GnomeFTP can’t make the ssh-connection to my server either, but it can make a FTP connection to a different server.
tikitin wrote:
> ab@novell.com;1969523 Wrote:
>> Was this attempt done with the firewall down? Have you tried taking
>> down the firewall on the server side just temporarily for a quick test?
>>
>> —
>> Try creating a new user
>> —
>> Maybe try hitting Ctrl+C once
>>
>
>
> I have tried with the firewalls in both machines down. Also tried with
> a different user.
> Hitting Ctrl+C just produces letter “c” after the connection has been
> closed on the server side (by killing the process).
>
> I still think there can be nothing wrong on the server side, since
> Putty connects fine from a windows machine. Too bad I don’t have
> username+password to any other ssh-server, so I could try it. Like I
> said earlier, GnomeFTP can’t make the ssh-connection to my server
> either, but it can make a FTP connection to a different server.
>
> Very strange!
>
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
I am using a ADSL-modem/router with an ethernet connection to the server and WLAN connection to the laptop. It just didn’t work. Once I took my laptop away from home and connected it to a differenet wireless network, everything functioned the way it is supposed to function!