RE: Need some education: Man-in-the-Middle Attacks

2006-08-31 Thread Nathan Jackson-Eeles

Bryan,

The way to stop the mitm attack is to pre-install the server's host
key in the clients known_hosts file and set up the client so it won't
connect to a host that doesn't match the pre-installed key.
This key is the public key of the host and is used in a
challange-response authentication to make sure that the host you are
contacting actually holds the matching private key (server
authentication).

HTH,

Nathan

On 8/29/06, Christ, Bryan [EMAIL PROTECTED] wrote:

All,

Please pardon my naivete.

I was looking at the diagram on the URL listed below and contemplating
how host fingerprinting prevents MITM attacks.

http://www.vandyke.com/solutions/ssh_overview/ssh_overview_threats.html

So my question is this... Given the illustration in the URL above, what
prevents Eve from *first* contacting Alice to obtain a fingerprint which
then gets passed to Bob on the first connection attempt?





Re: SFTP Error

2006-08-21 Thread Nathan Jackson-Eeles

Normally it's exactly what the error says:

Most likely the sftp-server is not in the path of the user on the server-side.

The F-Secure SSH Client first makes a standard SSH connection to the
server and then attempts to start the sftp-server with the user
credentials you entered in the sftp client app.
The easiest way to test this is to make a normal ssh terminal
connection, then as the same user run the following command:

type sftp-server

If your SSH Server is on a windows box then run the path command
from the command prompt and check that the F-Secure path is there.

HTH,

Nathan


On 8/15/06, [EMAIL PROTECTED]
[EMAIL PROTECTED] wrote:





I'm using :


   F-Secure SSH Client 5.3 build 23 and F-Secure SSH File Transfer
   It works fine when I use the SSH Client. But, when I'm using sftp,
   it
   displays :


   File transfer server could not be started or it exited unexpectedly.

   Exit value 0 was returned. Most likely the sftp-server is not in the
   path of
   the user on the server-side.


   What can be happening ?






   TMDSM - Distributed Software Migration
   First Data Resources
   Office: 402-777-5979
   Primary TMDSM pager # 221-1020
   Back-up TMDSM pager # 221-1509
   [EMAIL PROTECTED]


-
The information in this message may be proprietary and/or
confidential, and protected from disclosure.  If the reader of this
message is not the intended recipient, or an employee or agent
responsible for delivering this message to the intended recipient,
you are hereby notified that any dissemination, distribution or
copying of this communication is strictly prohibited. If you have
received this communication in error, please notify First Data
immediately by replying to this message and deleting it from your
computer.




Re: ssh as non-root user

2006-07-24 Thread Nathan Jackson-Eeles

Jonathan,

Don't know whether you fixed this or not, but I've just got round to
reading this post.

The server is reporting the following to the client:
debug: server offers auth methods ''.

I would check the syntax of your AllowedAuthentications in your sshd2_config.

I'm not sure whether it's just a typo in your mail, but it should
begin with a capital A:

AllowedAuthentications publickey

HTH,

Nathan



On 5/30/06, Jonathan Burelbach [EMAIL PROTECTED] wrote:

I am trying to setup sshd to run as a non-root user to limit connections
to and from certain hosts.  I'm running ssh.com v3.2.9 on Solaris 9
on an e25k and I am able to start sshd as myself, but login using keys
doesn't work.  I've got allowedAuthentications set to just publickey
since passwd won't work and authorization and identification files are
correct since I can login remotely using keys.  Any one have any clues?

TIA.

The daemon tells me:

  [EMAIL PROTECTED]: ~  323 - /usr/local/sbin/sshd -v
  debug[23292]: SshConfig/sshconfig.c:2838: Metaconfig parsing stopped at line 
3.
  debug[23292]: SshConfig/sshconfig.c:3130: Read 10 params from config file.
  sshd: SSH Secure Shell 3.2.9 on sparc-sun-solaris2.9
  debug[23292]: SshHostKeyIO/sshhostkeyio.c:194: Reading public host key from 
/export/home/jburelba/.ssh2/hostkey.pub
  debug[23292]: SshHostKeyIO/sshhostkeyio.c:279: Host key algorithms (from 
disk): ssh-dss
  debug[23292]: Becoming server.
  debug[23292]: Creating listener
  debug[23292]: Listener created
  debug[23292]: no udp listener created.
  debug[23292]: Running event loop
  debug[23292]: Sshd2/sshd2.c:2007: new_connection_callback
  debug[23292]: Sshd2/sshd2.c:1934: Wrapping stream with ssh_server_wrap...
  debug[23292]: ssh_server_wrap: creating transport protocol
  debug[23292]: Ssh2Transport/trcommon.c:3676: My version: SSH-2.0-3.2.9 SSH 
Secure Shell
  debug[23292]: ssh_server_wrap: creating userauth protocol
  debug[23292]: Ssh2Common/sshcommon.c:537: local ip = 127.0.0.1, local port = 
2022
  debug[23292]: Ssh2Common/sshcommon.c:539: remote ip = 127.0.0.1, remote port 
= 58829
  debug[23292]: SshConnection/sshconn.c:1945: Wrapping...
  debug[23292]: Sshd2/sshd2.c:1972: done.
  debug[23292]: new_connection_callback returning
  debug[23292]: Remote version: SSH-1.99-3.2.9 SSH Secure Shell
  debug[23292]: Major: 3 Minor: 2 Revision: 9
  debug[23292]: Ssh2Transport/trcommon.c:1367: lang s to c: `', lang c to s: `'
  debug[23292]: Ssh2Transport/trcommon.c:1433: c_to_s: cipher aes128-cbc, mac 
hmac-sha1, compression none
  debug[23292]: Ssh2Transport/trcommon.c:1436: s_to_c: cipher aes128-cbc, mac 
hmac-sha1, compression none
  debug[23292]: SshUnixUser/sshunixuser.c:408: Can't find jburelba's shadow - 
access denied.
  debug[23292]: Sshd2/sshd2.c:1142: user 'jburelba' service 'ssh-connection' 
client_ip '127.0.0.1' client_port '58829' completed ''
  debug[23292]: Sshd2/sshd2.c:1195: Number of groups: 2.
  debug[23292]: Sshd2/sshd2.c:1200: Adding group: eos, 100.
  debug[23292]: Sshd2/sshd2.c:1200: Adding group: sysadmin, 14.
  debug[23292]: Sshd2/sshd2.c:1572: output: publickey
  debug[23292]: Ssh2AuthCommonServer/auths-common.c:414: User jburelba's login 
is not allowed due to system policy
  debug[23292]: Ssh2AuthCommonServer/auths-common.c:41: publickey 
authentication failed. Login to account jburelba not allowed or account 
non-existent.
  debug[23292]: Sshd2/sshd2.c:1142: user 'jburelba' service 'ssh-connection' 
client_ip '127.0.0.1' client_port '58829' completed ''
  debug[23292]: Sshd2/sshd2.c:1572: output:
  debug[23292]: Ssh2Common/sshcommon.c:169: DISCONNECT received: No further 
authentication methods available.
  debug[23292]: Sshd2/sshd2.c:366: locally_generated = FALSE
  debug[23292]: Ssh2Common/sshcommon.c:662: Destroying SshCommon object.
  debug[23292]: SshConnection/sshconn.c:1997: Destroying SshConn object.


And the client says:

  [EMAIL PROTECTED]: ~  341 - /usr/local/bin/ssh -v localhost -p 2022
  debug: SshConfig/sshconfig.c:2838: Metaconfig parsing stopped at line 3.
  debug: SshConfig/sshconfig.c:3130: Read 0 params from config file.
  debug: Ssh2/ssh2.c:1707: User config file not found, using defaults. (Looked 
for '/export/home/jburelba/.ssh2/ssh2_config')
  debug: Connecting to localhost, port 2022... (SOCKS not used)
  debug: Ssh2Transport/trcommon.c:3676: My version: SSH-1.99-3.2.9 SSH Secure 
Shell
  debug: client supports 3 auth methods: 
'publickey,keyboard-interactive,password'
  debug: Ssh2Common/sshcommon.c:537: local ip = 127.0.0.1, local port = 58829
  debug: Ssh2Common/sshcommon.c:539: remote ip = 127.0.0.1, remote port = 2022
  debug: SshConnection/sshconn.c:1945: Wrapping...
  debug: SshReadLine/sshreadline.c:2427: Initializing ReadLine...
  debug: Remote version: SSH-2.0-3.2.9 SSH Secure Shell
  debug: Major: 3 Minor: 2 Revision: 9
  debug: Ssh2Transport/trcommon.c:1367: lang s to c: `', lang c to s: `'
  debug: Ssh2Transport/trcommon.c:1433: c_to_s: cipher aes128-cbc, mac 

Re: SSH just works in internal network, not over the internet

2006-07-11 Thread Nathan Jackson-Eeles

Hi Manu,

Any chance you can get a look at the server log, there's 138 bytes
sent to stderr and it would be useful to see what that was.

It would also be handy to see the entire client side log (minus ip's
of course) then we can see the server/client versions and the
handshake process.

Regards,

Nathan

On 7/9/06, Manu [EMAIL PROTECTED] wrote:

Hi all,

I'm having a very strange problem and - surely - I think I've tried anything
possible to solve it.

Situation:
I can't connect to an ssh server on the internet. I've tried with multiple
ones (university, my server, a friends one...), but it always fails. Commands
are right, this isn't the thing.
Anyway, connecting to my server within in my personal network (e.g. ssh
[EMAIL PROTECTED]) works like a charm.

Done work:
I've tried this thing with two routers, a U.S. Robotics and currently I'm
using a Linksys WRT54GS. Nothing different. I've also tried with a live-cd
Knoppix. Nothing different.
Strange thing: I'm using Ubuntu Dapper (ssh -V: OpenSSH_4.2p1 Debian-7ubuntu3,
OpenSSL 0.9.8a 11 Oct 2005). When I try to connect with PuTTY (aptitude
install putty) everything is fine and I *can* connect. Also no problem when
connecting from Windows through PuTTY.

Log:
Everything seems fine, I'm entering my password and here it goes:
~~~
 [EMAIL PROTECTED]'s password:
 debug2: we sent a password packet, wait for reply
 debug1: Authentication succeeded (password).
 debug1: channel 0: new [client-session]
 debug2: channel 0: send open
 debug1: Entering interactive session.
 debug2: callback start
 debug2: client_session2_setup: id 0
 debug2: channel 0: request pty-req confirm 0
 debug1: Sending environment.
 debug1: Sending env LANG = de_DE.UTF-8
 debug2: channel 0: request env confirm 0
 debug2: channel 0: request shell confirm 0
 debug2: fd 3 setting TCP_NODELAY
 debug2: callback done
 debug2: channel 0: open confirm rwindow 0 rmax 32768
~~~

Then nothing happens for about 10 to 15 minutes until this information shows
up.
~~~
 debug1: channel 0: free: client-session, nchannels 1
 Read from remote host xxx.de: Connection timed out
 Connection to xxx.de closed.
 debug1: Transferred: stdin 0, stdout 0, stderr 138 bytes in 1215.0 seconds
 debug1: Bytes per second: stdin 0.0, stdout 0.0, stderr 0.1
 debug1: Exit status -1
~~~

Is there anyone who can provide some tips and is willing to help me? :-)

--
Kind regards,
Manu



Re: key login

2006-07-11 Thread Nathan Jackson-Eeles

Hi Aaron,

The client offers the key to the server, so the server is failing to accept it.

Did you check the permissions for the ~/.ssh directory on the server?
If set too loose, this could cause problems.

Regards,

Nathan


On 6/30/06, Aaron Peterson [EMAIL PROTECTED] wrote:

I use 6 rhel boxes that should all be configured identically, but
apparently are not.  I was setting up logins with keys to use ssh from
one to the other, and they all work but one.  I need some help
figuring out why this might be.

I generated a dsa key for clienthost and brokenhost with ssh-keygen
-t dsa -b 2048 and just hit enter to use the default file name and no
passphrase.  I added the id_dsa.pub contents to authorized_keys in
~/.ssh on the brokenhost.  This procedure worked for connecting to all
of the 6 servers except brokenhost.  Perhaps someone can tell me why.
Unfortunately I don't have root on these servers, and cannot look at
the sshd_config.

the ssh -vv brokenhost follows:

[EMAIL PROTECTED] user]$ ssh -vv brokenhost
OpenSSH_3.6.1p2, SSH protocols 1.5/2.0, OpenSSL 0x0090701f
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Rhosts Authentication disabled, originating port will not be trusted.
debug2: ssh_connect: needpriv 0
debug1: Connecting to brokenhost [192.168.1.30] port 22.
debug1: Connection established.
debug1: identity file /home/user/.ssh/identity type -1
debug1: identity file /home/user/.ssh/id_rsa type -1
debug2: key_type_from_name: unknown key type '-BEGIN'
debug2: key_type_from_name: unknown key type '-END'
debug1: identity file /home/user/.ssh/id_dsa type 2
debug1: Remote protocol version 1.99, remote software version OpenSSH_3.6.1p2
debug1: match: OpenSSH_3.6.1p2 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_3.6.1p2
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug2: kex_parse_kexinit:
diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
debug2: kex_parse_kexinit:
aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,[EMAIL
 PROTECTED]
debug2: kex_parse_kexinit:
aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,[EMAIL
 PROTECTED]
debug2: kex_parse_kexinit:
hmac-md5,hmac-sha1,hmac-ripemd160,[EMAIL PROTECTED],hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit:
hmac-md5,hmac-sha1,hmac-ripemd160,[EMAIL PROTECTED],hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,zlib
debug2: kex_parse_kexinit: none,zlib
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit: first_kex_follows 0
debug2: kex_parse_kexinit: reserved 0
debug2: kex_parse_kexinit:
diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
debug2: kex_parse_kexinit:
aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,[EMAIL
 PROTECTED]
debug2: kex_parse_kexinit:
aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,[EMAIL
 PROTECTED]
debug2: kex_parse_kexinit:
hmac-md5,hmac-sha1,hmac-ripemd160,[EMAIL PROTECTED],hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit:
hmac-md5,hmac-sha1,hmac-ripemd160,[EMAIL PROTECTED],hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,zlib
debug2: kex_parse_kexinit: none,zlib
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit: first_kex_follows 0
debug2: kex_parse_kexinit: reserved 0
debug2: mac_init: found hmac-md5
debug1: kex: server-client aes128-cbc hmac-md5 none
debug2: mac_init: found hmac-md5
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
debug2: dh_gen_key: priv key bits set: 131/256
debug2: bits set: 1525/3191
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host 'brokenhost' is known and matches the RSA host key.
debug1: Found key in /home/user/.ssh/known_hosts:12
debug2: bits set: 1617/3191
debug1: ssh_rsa_verify: signature correct
debug2: kex_derive_keys
debug2: set_newkeys: mode 1
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug2: set_newkeys: mode 0
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue:
publickey,password,keyboard-interactive
debug1: Next authentication method: publickey
debug1: Trying private key: /home/user/.ssh/identity
debug1: Trying private key: /home/user/.ssh/id_rsa
debug1: Offering public key: /home/user/.ssh/id_dsa
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue:
publickey,password,keyboard-interactive
debug2: we did not send a packet, disable method
debug1: Next authentication method: keyboard-interactive
debug2: userauth_kbdint
debug2: we sent a