NettleSSH
Ron
my time or not.
I'm getting an initial connection but with a Rectangle prompt.
NettleSSH: Looking up host 192.168.0.42...
NettleSSH: Connecting to 192.168.0.42...
NettleSSH: Connected to 192.168.0.42
SSH-2.0-OpenSSH_5.1p1 Debian-5ubuntu1
any attempt to do anything at this stage results in
Protocol mismatch.
NettleSSH: Remote has closed the connection
NettleSSH: Disconnected
I realise that NettlSSH is Protocol 1, but when I set this setting in
sshd_config, on restarting it exits with "no host keys available".
ssh-server made keys when it installed, obviously not for protocol 1, I
think I'll find a way to do this, but was hoping for a root password as
a means of getting in.
I'll read on.
Thanks for any help
Ron
Rob Kendrick
Ron <be...@woosh.co.nz> wrote:
> I realise that NettlSSH is Protocol 1, but when I set this setting in
> sshd_config, on restarting it exits with "no host keys available".
> ssh-server made keys when it installed, obviously not for protocol 1,
> I think I'll find a way to do this, but was hoping for a root
> password as a means of getting in.
You'll need to create an SSH1 host key, most likely using the
ssh-keygen tool. It's been so long since I've done this, I've
forgotten how to, but hopefully knowing the area to look in will help
you find it.
Host keys/certificates are for the computers to trust that they are
talking to the right computers; passwords (or user keys/certificates)
are for authenticating yourself to the computer. They are different
things.
B.
Ron
Rob Kendrick <nn...@rjek.com> wrote:
So far I've found that the keygen with -t rsa1 should do the job, I
presume I will be prompted for the key passphrase that I make when I
connect?
Ron
Ron
Ron <be...@woosh.co.nz> wrote:
OK, I generated the pair of keys correctly, I think. In the process it
verbosely gave me a number of the form c9:55:6e......... etc, which I
guessed might be of some importance for the connection.
After putting the keys in the correct place and naming them to what sshd
was looking for sshd then started OK.
I tried the code in a few different places in the connection
field/terminal, but still get a protocol mismatch.
NettleSSH: Looking up host 192.168.0.42...
NettleSSH: Connecting to 192.168.0.42...
NettleSSH: Connected to 192.168.0.42
SSH-1.5-OpenSSH_5.1p1 Debian-5ubuntu1
and after trying at the (now centre of terminal) Rectangle prompt,
Protocol mismatch.
NettleSSH: Remote has closed the connection
NettleSSH: Disconnected
Although I followed the instructions for Protocol 1, the above makes it
look like it has got 1.5, if there is such a thing.
Ron
Ron
Ron <be...@woosh.co.nz> wrote:
<snip>
> NettleSSH: Looking up host 192.168.0.42...
> NettleSSH: Connecting to 192.168.0.42...
> NettleSSH: Connected to 192.168.0.42
> SSH-1.5-OpenSSH_5.1p1 Debian-5ubuntu1
>
> and after trying at the (now centre of terminal) Rectangle prompt,
>
> Protocol mismatch.
> NettleSSH: Remote has closed the connection
> NettleSSH: Disconnected
>
> Although I followed the instructions for Protocol 1, the above makes it
> look like it has got 1.5, if there is such a thing.
>
> Ron
window in NettleSSH. :-(
Now things are happening, though through the use of my Ubuntu machine
username and password. I thought the big code would come into play,
maybe it's back to the sshd_config for changes like that.
NettleSSH: Looking up host 192.168.0.42...
NettleSSH: Connecting to 192.168.0.42...
NettleSSH: Connected to 192.168.0.42
Remote host are who they claim to be... good!
Sent username "ron".
password:
Linux ubuntu9 2.6.28-15-generic #49-Ubuntu SMP Tue Aug 18 18:40:08
UTC 2009 i686
The programs included with the Ubuntu system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.
Ubuntu comes with ABSOLUTELY NO WARRANTY, to the extent permitted by
applicable law.
To access official Ubuntu documentation,please visit:
http://help.ubuntu.com/
ron@ubuntu9:~$
Looks like I've got my foot in the door now :-)
Ron
Brian Howlett
> Looks like I've got my foot in the door now :-)
I thought I'd have a go at this myself, but can't seem to find
NettleSSH anywhere.
http://nettlessh.mine.nu/ appears to be down. Does anyone know if it's been moved to another location?
--
Brian Howlett - Email to From: address deleted unseen
------------------------------------------------------------------
Last year I went fishing with Salvador Dali. He was using a dotted
line. He caught every other fish.
Theo Markettos
> I thought I'd have a go at this myself, but can't seem to find
> NettleSSH anywhere.
>
> http://nettlessh.mine.nu/ appears to be down. Does anyone know if it's
> been moved to another location?
http://www.markettos.org.uk/riscos/crypto/
has my 32 bit build.
Disclaimer: I did SSHProxy, the original port of PuTTY on which NettleSSH is
built. This is seriously crusty (~10 years old) and probably has a slew of
security holes (as well as those inherent in SSH v1). So in principle only
use it to connect to servers you trust over networks you trust. It's still
more secure than telnet though (especially for the server end).
Also, while you may need to set up SSH 1 host keys, you shouldn't set up
user keys. IIRC these aren't supported in that ancient PuTTY, so you'll
just get 'no authentication methods' or something if you try (and there's
nowhere to tell NettleSSH about them anyway). You need to enable password
authentication on the server for it to work.
Theo
Brian Howlett
> http://www.markettos.org.uk/riscos/crypto/
> has my 32 bit build.
Right - thanks - I actually got your page fairly high up in my Google
search, but missed the link to your own build. You have a link at the
bottom of your page to the one that I can't find...
--
Brian Howlett - Email to From: address deleted unseen
-----------------------------------------------------
"Fish - visionary genius, or just a big haddie?"
Ron
Theo Markettos <theom...@chiark.greenend.org.uk> wrote:
>
> http://www.markettos.org.uk/riscos/crypto/
>
> has my 32 bit build.
>
> Disclaimer: I did SSHProxy, the original port of PuTTY on which NettleSSH is
> built. This is seriously crusty (~10 years old) and probably has a slew of
> security holes (as well as those inherent in SSH v1). So in principle only
> use it to connect to servers you trust over networks you trust. It's still
> more secure than telnet though (especially for the server end).
>
> Also, while you may need to set up SSH 1 host keys, you shouldn't set up
> user keys. IIRC these aren't supported in that ancient PuTTY, so you'll
> just get 'no authentication methods' or something if you try (and there's
> nowhere to tell NettleSSH about them anyway). You need to enable password
> authentication on the server for it to work.
>
> Theo
Hi Theo,
thank you for your input and for the NettleSSH effort.
I have made connections to Slackware 12 and Fedora 10 as well now.
It appears that if the host keys aren't made, you can still connect,
but you get a security warning about it.
Slackware made the Protocol 1 keys automatically for the user that
started sshd, so for that user there was no security warning.
On Fedora 10, I did nothing except comment out 'Protocol 2' from
/etc/ssh/sshd.conf. It is there to stop sshd from using anything lower.
But got the security warnings.
All flavours use port 22, and it must be specified in 'Open new session'
Host field. ie:
<user>:<pword>@<serverIPadd>:22
Ron M
Theo Markettos
> Hi Theo,
> thank you for your input and for the NettleSSH effort.
> I have made connections to Slackware 12 and Fedora 10 as well now.
> It appears that if the host keys aren't made, you can still connect,
> but you get a security warning about it.
One thing you might be confusing is the use of the host key fingerprint when
you first login.
SSH is designed to prevent you logging in to an evil machine because someone
has changed the DNS so the hostname you thought you were logging in to has
been updated to point elsewhere.
To do this, the first time you login to a machine the client presents you
with the host key fingerprint of the machine. You're supposed to check this
matches with the host key fingerprint of the machine that you received in
another way (for example, when told your username and password the sysadmin
also tells you the fingerprint).
If it's the same then you can be confident you're logging in to the right
machine. When you've done this once the fingerprint is stored on your
machine, and SSH will alert you if, at any time in future, you ever login to
that machine and get a different fingerprint - since that'll mean something
fishy is going on (or the sysadmin has broken something, but you should
check).
NettleSSH is far too lax about this and just warns you that a new machine
has been seen and the host key has been saved, but never gives you an
opportunity to check if the host key is the right one. This is maybe the
message you saw from NettleSSH first time around.
> All flavours use port 22, and it must be specified in 'Open new session'
> Host field. ie:
> <user>:<pword>@<serverIPadd>:22
I didn't know that notation was available... I always choose 'SSH' from the
menu and enter/save a hostname without port. It should then open a terminal
and give you username/password prompts. Clever Justin :-)
Theo
Ron
Theo Markettos <theom...@chiark.greenend.org.uk> wrote:
> Ron <be...@woosh.co.nz> wrote:
> > Hi Theo,
> > thank you for your input and for the NettleSSH effort.
> > I have made connections to Slackware 12 and Fedora 10 as well now.
> > It appears that if the host keys aren't made, you can still connect,
> > but you get a security warning about it.
>
> One thing you might be confusing is the use of the host key fingerprint when
> you first login.
>
> SSH is designed to prevent you logging in to an evil machine because someone
> has changed the DNS so the hostname you thought you were logging in to has
> been updated to point elsewhere.
>
> To do this, the first time you login to a machine the client presents you
> with the host key fingerprint of the machine. You're supposed to check this
> matches with the host key fingerprint of the machine that you received in
> another way (for example, when told your username and password the sysadmin
> also tells you the fingerprint).
>
> If it's the same then you can be confident you're logging in to the right
> machine. When you've done this once the fingerprint is stored on your
> machine, and SSH will alert you if, at any time in future, you ever login to
> that machine and get a different fingerprint - since that'll mean something
> fishy is going on (or the sysadmin has broken something, but you should
> check).
I see, so it's for the client's security also. Obviously a full ssh
client would have a copy of the fingerprint key in place.
The 'wrong' machine would have to allow 'all' logins/passwords though
before you would connect.
> NettleSSH is far too lax about this and just warns you that a new machine
> has been seen and the host key has been saved, but never gives you an
> opportunity to check if the host key is the right one. This is maybe the
> message you saw from NettleSSH first time around.
*** SECURITY ALERT: Remote host's key differs from that stored locally.
***This may be a result of a security attack, or sloppy system administration
*** Be careful when continuing!
wait a minute, does NettleSSH store a key somewhere or not?
Ron M
Theo Markettos
> I see, so it's for the client's security also. Obviously a full ssh
> client would have a copy of the fingerprint key in place.
> The 'wrong' machine would have to allow 'all' logins/passwords though
> before you would connect.
Not necessarily - it can just forward them on to the real machine, making a
note of all the traffic in between (including your username and password,
and any passwords you used on other machines through that session). And you
would never tell.
> *** SECURITY ALERT: Remote host's key differs from that stored locally.
> ***This may be a result of a security attack, or sloppy system administration
> *** Be careful when continuing!
>
> wait a minute, does NettleSSH store a key somewhere or not?
It does, in (IIRC) Choices:Crypto.SSH.known_hosts
Apart from the case of something fishy, you shouldn't get that warning
unless you're logging in to a machine where someone /has/ changed the host
key, or a cluster where each machine on the cluster has its own key (OpenSSH
can deal with that if you fiddle with it, NettleSSH can't). How did you
manage to produce it?
Theo
Ron
Theo Markettos <theom...@chiark.greenend.org.uk> wrote:
>
> > *** SECURITY ALERT: Remote host's key differs from that stored locally.
> > ***This may be a result of a security attack, or sloppy system
> > administration *** Be careful when continuing!
> >
> > wait a minute, does NettleSSH store a key somewhere or not?
>
> It does, in (IIRC) Choices:Crypto.SSH.known_hosts
>
That explains a lot. The Linux blurb didn't mention that it would be
retrieved by the client.
Also, after creating a key pair (ssh-keygen -t rsa1), I had to move them
from keygens default to /etc/ssh/ and also rename them to what sshd was
looking for.
> Apart from the case of something fishy, you shouldn't get that warning
> unless you're logging in to a machine where someone /has/ changed the host
> key, or a cluster where each machine on the cluster has its own key (OpenSSH
> can deal with that if you fiddle with it, NettleSSH can't). How did you
> manage to produce it?
>
This Security Alert message is from not making the key pair on the host
at all.
In the light of your information, Slackware did the oddest thing where
it made a rsa1 key pair for the user that started the sshd, and then a
client logging in with that same user name got no Security alert.
I will have to monitor the Choices:Crypto.SSH.KnownHosts file.
To throw a bit of confusion into it, I have been using the same hostIP
on all three linux flavours, and Linux is increasingly demanding on
keeping its users privilages separate.
For example, I connected to Fedora NFS and sent a file to it. But it
wasn't of any use there because it belonged to nfsnobody. There is
usually a way to get there, but generally time consuming.
I think using Moonfish may be the quick way nowadays.
A proper study of users/groups usage would probably help avoiding the
pitfalls.
It appears you can install sudo on other flavours, but Ubuntu
really championed it, and made a desktop pretty close to single user
operation ideal(easy) for the home user.
Ron M
Erik G
> Ron <be...@woosh.co.nz> wrote:
> > wait a minute, does NettleSSH store a key somewhere or not?
>
> It does, in (IIRC) Choices:Crypto.SSH.known_hosts
Just for the record, it's Choices:Crypto.SSH.KnownHosts
--
Erik G http://www.xs4all.nl/~erikgrnh
== 'From:' address is a spam trap. Do not use
== See web site for email address
Theo Markettos
> This Security Alert message is from not making the key pair on the host
> at all.
> In the light of your information, Slackware did the oddest thing where
> it made a rsa1 key pair for the user that started the sshd, and then a
> client logging in with that same user name got no Security alert.
> I will have to monitor the Choices:Crypto.SSH.KnownHosts file.
>
> To throw a bit of confusion into it, I have been using the same hostIP
> on all three linux flavours, and Linux is increasingly demanding on
> keeping its users privilages separate.
You can always keep the same host keys for the different OSs - in fact it's
a good idea to do so. Just copy the keys from one /etc/ssh/ to the others
(and if you have SSH on Windows you can convert them for that too). That
will prevent warnings, and shouldn't have any other repercussions.
Theo
Ron
Theo Markettos <theom...@chiark.greenend.org.uk> wrote:
Yes, I realised that after a while.
When I run Slackware it seemed to do the job itself and run without any
warnings. It has put correctly named keys in the /etc/ssh/. It didn't
overwrite or add to :Choices though, and on the second time round it
does the Security Warning thing. At the time it looked like it was doing
special keys per user.
I have had to just treat this as an oddity, and hopefully one key pair
per /etc/ssh will suffice for all of it's users.
And yes, I will place the key pair I made myself in Ubuntu, in the other
distributions' /etc/ssh.
I imagine if I SSH into a different hostIP one day it will append to
!Boot.Choices.Crypto.SSH.KnownHosts file?
I found later that I didn't have to append :22 in the host field, and
after reading a bit it does seem to be the standard port for SSH.
From what I can see I can't use NettleSSH with standard ssh commands,
and ssh doesn't show up in a Task window.
The NettleSSh commands field is just the equivalent of using the
terminal once connected.
It would be handy to be able to send commands to NettleSSH from a
Frontend. I have used !Formfiller with it so far.
TIA for any corrections/info
Ron M
Ron
Ron <be...@woosh.co.nz> wrote:
> In message <Wsi*ui...@news.chiark.greenend.org.uk>
> Theo Markettos <theom...@chiark.greenend.org.uk> wrote:
>
> > Ron <be...@woosh.co.nz> wrote:
> >
> > You can always keep the same host keys for the different OSs - in fact it's
> > a good idea to do so. Just copy the keys from one /etc/ssh/ to the others
> > (and if you have SSH on Windows you can convert them for that too). That
> > will prevent warnings, and shouldn't have any other repercussions.
> >
> > Theo
> Yes, I realised that after a while.
> When I run Slackware it seemed to do the job itself and run without any
> warnings. It has put correctly named keys in the /etc/ssh/. It didn't
> overwrite or add to :Choices though, and on the second time round it
> does the Security Warning thing. At the time it looked like it was doing
> special keys per user.
> I have had to just treat this as an oddity, and hopefully one key pair
> per /etc/ssh will suffice for all of it's users.
> And yes, I will place the key pair I made myself in Ubuntu, in the other
> distributions' /etc/ssh.
Yes, I copied the key pairs to the other /etc/ssh but the one that gets
written to :Choices is only good for the user/distro combination that
makes it on the first connection.
The KnownHosts file has to be removed and then it will be made correctly
for the next connection.
So to avoid the Security Warning dialog, I can move the appropriate
user/distro influenced KnownHosts file in and out of place.
Another way would be just to delete it, and a new one would be made on
the next connection.
Fedora and Slackware both already had rsa keys in place and probably
would have worked had I removed the KnownHosts file before connecting.
I dont know what the effect of connecting to a different HostIPaddress
would have on KnownHosts yet, and this would be the more likely/normal
scenario.
But, once again, as long as rsa1 keys are in place and protocol 2 is
remmed out on the Linux, you could simply delete the KnownHosts file and
it will get remade for the current combination.
Ron M