SSH and FTP login very slow

mwesterl

Registered
I have a problem with SSH and FTP. Both login procedures are slow. When I want to login with SSH, the question for my login name is there immediately. I give my name, and I must wait for 15 seconds for the password question.

When I logged in, there are no problems. It runs super fast, but the login procedure is slow.


The same problem with FTP. Have anybody a idea, what the problem is?

The mac runs in my local network, 10 Mbit. I use putty (windows) for ssh and ws_ftp le (windows) for FTP.


Kind Regards,
Martijn van Westerlaak
 
I'm not seeing this, but connecting with Appletalk over TCP/IP is really slow. It takes about 30 seconds to pop up the authentication dialog, then 30 seconds more to pop up the list of shareable drives. And the server machine is set to only sleep the display, not the CPU or the hard drive.

And it's on a LAN.

Sucky.
 
when I check mine it tells me that it is a problem with reverse lookup, I am not sure how to fix this but here is my output.

sshd[424]: lastlog_openseek: /var/log/lastlog is not a file or directory!
Mar 14 08:15:07 BlueTuna sshd[424]: Could not reverse map address 192.168.123.177.
Mar 14 08:15:07 BlueTuna sshd[424]: lastlog_perform_login: Couldn't stat /var/log/lastlog: No such file or directory

It would be great if someone could point me in the right direction to fix the reverse lookup problem

Edward
 
Hmmm, I'm not getting anything relating to lastlog when I grep /var/log and /Library/Logs - maybe there are multiple causes.

It would make sense that it's a reverse DNS problem, though. I always connect using a numeric IP.
 
I connect to using numerical IP and still get the reverse lookup error... I do think that it is the problem, maybe one should desable the reverse lookup in ssh (not sure how to do that), or is there a better way?

edward
 
OpenSSH_3.1p1, SSH protocols 1.5/2.0, OpenSSL 0x0090602f
debug1: Reading configuration data /private/etc/ssh_config
debug1: Rhosts Authentication disabled, originating port will not be trusted.
debug1: restore_uid
debug1: ssh_connect: getuid 0 geteuid 0 anon 1
debug1: Connecting to 192.168.123.177 [192.168.123.177] port 22.
debug1: restore_uid
debug1: restore_uid
debug1: Connection established.
debug1: read PEM private key done: type DSA
debug1: read PEM private key done: type RSA
debug1: identity file /Users/edward/.ssh/identity type -1
debug1: identity file /Users/edward/.ssh/id_rsa type -1
debug1: identity file /Users/edward/.ssh/id_dsa type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_3.1p1
debug1: match: OpenSSH_3.1p1 pat OpenSSH*
Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_3.1p1
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 sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: dh_gen_key: priv key bits set: 133/256
debug1: bits set: 1013/2049
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host '192.168.123.177' is known and matches the RSA host key.
debug1: Found key in /Users/edward/.ssh/known_hosts:1
debug1: bits set: 1040/2049
debug1: ssh_rsa_verify: signature correct
debug1: kex_derive_keys
debug1: newkeys: mode 1
debug1: SSH2_MSG_NEWKEYS sent
debug1: waiting for SSH2_MSG_NEWKEYS
debug1: newkeys: mode 0
debug1: SSH2_MSG_NEWKEYS received
debug1: done: ssh_kex2.
debug1: send SSH2_MSG_SERVICE_REQUEST
debug1: service_accept: ssh-userauth
debug1: got SSH2_MSG_SERVICE_ACCEPT
debug1: authentications that can continue: publickey,password,keyboard-interactive
debug1: next auth method to try is publickey
debug1: try privkey: /Users/edward/.ssh/identity
debug1: try privkey: /Users/edward/.ssh/id_rsa
debug1: try privkey: /Users/edward/.ssh/id_dsa
debug1: next auth method to try is keyboard-interactive
debug1: authentications that can continue: publickey,password,keyboard-interactive
debug1: next auth method to try is password
edward@192.168.123.177's password:


thanks for the help
 
Okay, now try this...

ssh -v -v -lusername 192.168.123.177

... and check the output from the point after you enter your password.
 
debug1: packet_send2: adding 64 (len 53 padlen 11 extra_pad 64)
debug2: we sent a password packet, wait for reply
debug1: authentications that can continue: publickey,password,keyboard-interactive
Permission denied, please try again.


I can not log in since losername it is not a registered name on my system but I entered it exactly as you ask for debuging
 
it si strang I now can not login to the machine and here is what I get:

ssh -v -v ledward 192.168.123.177
OpenSSH_3.1p1, SSH protocols 1.5/2.0, OpenSSL 0x0090602f
debug1: Reading configuration data /private/etc/ssh_config
debug1: Rhosts Authentication disabled, originating port will not be trusted.
debug1: restore_uid
debug1: ssh_connect: getuid 0 geteuid 0 anon 1

ssh: ledward: no address associated with hostname.
 
debug2: we sent a password packet, wait for reply
debug1: ssh-userauth2 successful: method password
debug1: channel 0: new [client-session]
debug1: send channel open 0
debug1: Entering interactive session.
debug2: callback start
debug1: ssh_session2_setup: id 0
debug1: channel request 0: pty-req
debug1: channel request 0: shell
debug1: fd 3 setting TCP_NODELAY
debug2: callback done
debug1: channel 0: open confirm rwindow 0 rmax 32768
debug2: channel 0: rcvd adjust 131072
debug2: client_check_window_change: changed
debug1: channel request 0: window-change
Welcome to Darwin!
 
no it is now working I am not sure why but it seem a lot faster, I am not sure why it is.

thanks so much for your help

edward
 
Make host entries in NetInfo.

If you make host entries, ssh will not sit there trying to resolve ip's it never will be able to.

There's an exelent HOW TO on this by your's truely.

Basically, on both computers, make them aware of each other.

http://www.macosx.com/forums/showthread.php?s=&threadid=10694


Oh, and btw, if you make the host entries wrong, so that ip --> hostname isn't correct, it will be *really* slow
:) yes I found that out the hard way... :p
 
Slur had it right in post #3--don't let anything but the display go to sleep at any time and your FTP/SSH connections, as well as those for any other TLA (three-letter acronym) will be snap, snap, snappy.
 
Back
Top