Discussion:
[VM] imap-ssh and passwords
Matthew Vernon
2011-10-11 09:34:51 UTC
Permalink
Hi,

TFM notes that SSH must be able to authenticate without a password for
imap-ssh to work. This is a bit of a deficiency, really - I might want
to read email from a host which I'd rather not allow password-less
access to my mail server from, for example. Is there any chance of this
being fixed, please? :-)

Thanks,

Matthew
--
`O'-----0 `O'---. `O'---. `O'---.
\___| | \___|0-/ \___|/ \___|
| | /\ | | \ | |\ | |
The Dangers of modern veterinary life
Uday Reddy
2011-10-11 13:13:41 UTC
Permalink
Post by Matthew Vernon
Hi,
TFM notes that SSH must be able to authenticate without a password for
imap-ssh to work. This is a bit of a deficiency, really - I might want
to read email from a host which I'd rather not allow password-less
access to my mail server from, for example. Is there any chance of this
being fixed, please? :-)
This was done by Kyle Jones a long time ago, and I don't know why the
restriction is present.

But, from what I have heard, using public key encryption is better for
security than sending passwords. Some of my SSH servers enforce it. Does
your SSH server not allow encryption-based authentication?

Cheers,
Uday
Matthew Vernon
2011-10-11 16:50:53 UTC
Permalink
Hi,
Post by Uday Reddy
But, from what I have heard, using public key encryption is better for
security than sending passwords. Some of my SSH servers enforce it. Does
your SSH server not allow encryption-based authentication?
It does, but I'd rather not allow password-less access to my mail server
from some of the places I run VM from, and I don't think this is
entirely unreasonable.

Thanks,

Matthew
Uday Reddy
2011-10-11 17:36:01 UTC
Permalink
Post by Matthew Vernon
It does, but I'd rather not allow password-less access to my mail server
from some of the places I run VM from, and I don't think this is
entirely unreasonable.
I have no idea what you mean by password-less access. Normally, you have to
type in a password to release the private key.

I don't have access to an IMAP server that I can ssh into. So, I don't even
know how it works or doesn't work. So, I can't help here.

On the other hand, a simpler way for you to access the server might be to
ssh into your IMAP server separately and set up an ssh tunnel for port 143.
Then, within VM, you can use 'localhost' as the IMAP server and VM will be
quite satisfied with that. (I use this technique all the time to get inside
our firewall so that I can use normal IMAP instead of IMAP-SSL. For some
reason, it is a lot faster than IMAP-SSL.)

Cheers,
Uday
Tim Cross
2011-10-12 01:39:58 UTC
Permalink
Post by Matthew Vernon
Hi,
Post by Uday Reddy
But, from what I have heard, using public key encryption is better for
security than sending passwords.  Some of my SSH servers enforce it.  Does
your SSH server not allow encryption-based authentication?
It does, but I'd rather not allow password-less access to my mail server
from some of the places I run VM from, and I don't think this is entirely
unreasonable.
Thanks,
Matthew
I think there is a bit of confusion here.

The idea isn't to allow a password-less (or more accurately under ssh
jargon, passphrase-less) access.

With ssh, you have a number of different authentication types. The
most basic is just normal password based. This is also the less secure
method.

The preferred method is to create a public/private key pair. You place
the public key in the authorized_keys file on the remote host.
Associated with the private key is a passphrase, which ssh will prompt
for before it uses the key in authenticating connections.

To make this process a better user experience, it is common to also
setup an ssh-agent on the local host. This agent works as a key
manager. The first time you try to access the remote host, it pops up
a dialogue box and asks you for your passphrase. It then caches that
information and will allow all future connections wihtin that local
login session without again asking for the passphrase. The keys are
still used, it just doesn't ask you again to verify who you are.

However, imap over ssh is rather an older solution. Most sites now
support encrypted connections using TLS/SSL. This tends to be a more
robust and easier to setup approach. Maybe you could look into that
rather than using imap over ssh?

Tim
--
Tim Cross
Phone: 0428 212 217
Matthew Vernon
2011-10-12 07:14:01 UTC
Permalink
Post by Tim Cross
With ssh, you have a number of different authentication types. The
most basic is just normal password based. This is also the less secure
method.
I'm not sure I agree that password-based authentication is inherently
less secure than public-key-based authentication, but that's getting
rather off-topic, isn't it? I don't think password-based ssh logins are
so dreadful an idea that VM should not support them as a policy issue or
anything like that.
Post by Tim Cross
However, imap over ssh is rather an older solution. Most sites now
support encrypted connections using TLS/SSL. This tends to be a more
robust and easier to setup approach. Maybe you could look into that
rather than using imap over ssh?
The host concerned does not support imap/ssl, and has no plans to do so.

Regards,

Matthew
Uday Reddy
2011-10-12 10:38:25 UTC
Permalink
Post by Matthew Vernon
I'm not sure I agree that password-based authentication is inherently
less secure than public-key-based authentication, but that's getting
rather off-topic, isn't it? I don't think password-based ssh logins are
so dreadful an idea that VM should not support them as a policy issue or
anything like that.
No, we don't have any policy that VM should not support it. That is the way
Kyle Jones designed it. I don't know how easy or hard it might be to add
password-based SSH authentication. If anybody is able to work on it and
contribute a patch, I will be happy to incorporate it.
Post by Matthew Vernon
The host concerned does not support imap/ssl, and has no plans to do so.
That is ok. But I have mentioned the solution of ssh tunneling. Can you
try that and see if that does the job for you?

Cheers,
Uday
Matthew Vernon
2011-10-12 14:15:51 UTC
Permalink
Post by Uday Reddy
Post by Matthew Vernon
I'm not sure I agree that password-based authentication is inherently
less secure than public-key-based authentication, but that's getting
rather off-topic, isn't it? I don't think password-based ssh logins are
so dreadful an idea that VM should not support them as a policy issue or
anything like that.
No, we don't have any policy that VM should not support it. That is the way
Kyle Jones designed it. I don't know how easy or hard it might be to add
password-based SSH authentication. If anybody is able to work on it and
contribute a patch, I will be happy to incorporate it.
Further investigation suggests I was (somewhat) mistaken, but that the
ssh invocation is a bit buggy, I think.

Suppose my username on my machine running vm is alice, and my username
on my mailserver is bob. If I have:
("imap-ssh:login.mailserver.example.com:143:inbox:login:bob:*" "foo")

as my mailbox specification. If I then visit foo:inbox, then VM calls
ssh -L xxxx:login.mailserver.example.com:143 login.mailserver.example.com
...and this will try to log in as ***@login.mailserver.example.com,
which will fail.

In fact, if I am running emacs under X, then openssh can pop up a window
to ask for a password, and so password entry isn't an issue under
X11. It cannot do this in a terminal window, however[0].

I can work around this username problem by doing something like:
(setq vm-ssh-program-switches
'("-l" "bob")
)

...but that only works if my username is bob on /every/ mailhost I want
to imap/ssh to. I wonder if it would be better to add a username
argument to vm-setup-ssh-tunnel, and pass the username bit of the
maildrop specification to that?
Post by Uday Reddy
Post by Matthew Vernon
The host concerned does not support imap/ssl, and has no plans to do so.
That is ok. But I have mentioned the solution of ssh tunneling. Can you
try that and see if that does the job for you?
Yes, it does.

Regards,

Matthew
[0] I'm not good enough an elisp hacker to fix this, I don't think.
--
`O'-----0 `O'---. `O'---. `O'---.
\___| | \___|0-/ \___|/ \___|
| | /\ | | \ | |\ | |
The Dangers of modern veterinary life
Tim Cross
2011-10-12 23:44:32 UTC
Permalink
On Thu, Oct 13, 2011 at 1:15 AM, Matthew Vernon

[snip]
Post by Matthew Vernon
(setq vm-ssh-program-switches
     '("-l" "bob")
)
A way to work around this limitation would be to use the ~/.ssh/config
file, which will allow you to set the login name on a per host basis.
Remember that ssh is quite picky regarding the permissions of .ssh and
the files it contains.

Tim
--
Tim Cross
Phone: 0428 212 217
Matthew Vernon
2011-10-13 11:33:07 UTC
Permalink
Post by Tim Cross
On Thu, Oct 13, 2011 at 1:15 AM, Matthew Vernon
[snip]
Post by Matthew Vernon
(setq vm-ssh-program-switches
     '("-l" "bob")
)
A way to work around this limitation would be to use the ~/.ssh/config
file, which will allow you to set the login name on a per host basis.
Remember that ssh is quite picky regarding the permissions of .ssh and
the files it contains.
I know I could use .ssh/config (though in fact I regularly log in to the
target with two different usernames), but it still seems to me that this
is something VM should support?

Thanks,

Matthew
--
`O'-----0 `O'---. `O'---. `O'---.
\___| | \___|0-/ \___|/ \___|
| | /\ | | \ | |\ | |
The Dangers of modern veterinary life
Tim Cross
2011-10-13 11:56:50 UTC
Permalink
Post by Matthew Vernon
Post by Tim Cross
On Thu, Oct 13, 2011 at 1:15 AM, Matthew Vernon
[snip]
Post by Matthew Vernon
(setq vm-ssh-program-switches
     '("-l" "bob")
)
A way to work around this limitation would be to use the ~/.ssh/config
file, which will allow you to set the login name on a per host basis.
Remember that ssh is quite picky regarding the permissions of .ssh and
the files it contains.
I know I could use .ssh/config (though in fact I regularly log in to the
target with two different usernames), but it still seems to me that this
is something VM should support?
There is no argument about that, which is why I referred to it as a
work around rather than a fix. In fact, I would expect that Uday would
certainly welcome any code contribution that removed such limitations.

Tim
--
Tim Cross
Phone: 0428 212 217
Loading...