I know we have a couple of people who know a bit about all things embedded, can any advise on what chips successfully run the ARM linux? is it something that runs only on the Strong arm processor such as the intel SA1100 (used in the IPaq) or will the ARM Thumb processors run it as well?
Also how many people do we have on the list who are experienced in Electrical engineering?
Thanks
D
David Freeman wrote:
I know we have a couple of people who know a bit about all things embedded, can any advise on what chips successfully run the ARM linux? is it something that runs only on the Strong arm processor such as the intel SA1100 (used in the IPaq) or will the ARM Thumb processors run it as well?
if the internal core is ARM based, then it will most likely run. I suspect the ARM thumb is a normal ARM with a few things removed, a bit like the mobile pentium ;) We /may/ be porting Linux to the ARC (similar to ARM) processor soon (for a customer), this should be fun!!
Also how many people do we have on the list who are experienced in Electrical engineering?
well, I have just finished my Phd in EE, and I used to be a TV engineer, so I guess that makes me experienced ;) why do you want to know ?
Sz
Anyone ever got this to work? Not sat down and tried yet but a guy I was talking to yesterday said its harder then it looks, surely you just need the host keys etc.. and your away.
D
On Sun, Aug 19, 2001 at 12:19:20PM +0100, D wrote:
Anyone ever got this to work? Not sat down and tried yet but a guy I was talking to yesterday said its harder then it looks, surely you just need the host keys etc.. and your away.
I have it working.
Both hosts should be known to each other, i.e. each host has the other host's public key (ssh_host_key.pub) in its ssh_known_hosts file. The user account on the desination end needs to have the public key of the account on the originating end (.ssh/identity.pub) in its .ssh/authorized_keys file.
In addition to that the file permissions all need to be correct:
For the host specific files (/etc/ssh/* or /etc/ssh_*) all should be writable only by root and the host private key should not be readable by anyone else either. All the others files should be world readable.
For the user specific files, all should be owned by the user concerned and writable only by that user, with the private key (identity) and the authorized_keys files being readable only by that user and the others world readable.
If it doesn't work when you set it up, try the -d option on the server end to get a debug log from it which will tell what types of authenciation it is trying and why they fail. To use -d you need to run sshd from the command line as it doesn't go into the background and only goes round once (one connection attempt).
HTH, Steve.
Chears I will try this out later, it wasn't I can't do it just never done it and wanted to find at least one other person tha thad got it working.
Ta
D
-----Original Message----- From: alug-admin@stu.uea.ac.uk [mailto:alug-admin@stu.uea.ac.uk]On Behalf Of Steve Fosdick Sent: 19 August 2001 13:14 To: alug@stu.uea.ac.uk Subject: Re: [Alug] SSH/SCP No Password
On Sun, Aug 19, 2001 at 12:19:20PM +0100, D wrote:
Anyone ever got this to work? Not sat down and tried yet but a guy I was talking to yesterday said its harder then it looks, surely you
just need the
host keys etc.. and your away.
I have it working.
Both hosts should be known to each other, i.e. each host has the other host's public key (ssh_host_key.pub) in its ssh_known_hosts file. The user account on the desination end needs to have the public key of the account on the originating end (.ssh/identity.pub) in its .ssh/authorized_keys file.
In addition to that the file permissions all need to be correct:
For the host specific files (/etc/ssh/* or /etc/ssh_*) all should be writable only by root and the host private key should not be readable by anyone else either. All the others files should be world readable.
For the user specific files, all should be owned by the user concerned and writable only by that user, with the private key (identity) and the authorized_keys files being readable only by that user and the others world readable.
If it doesn't work when you set it up, try the -d option on the server end to get a debug log from it which will tell what types of authenciation it is trying and why they fail. To use -d you need to run sshd from the command line as it doesn't go into the background and only goes round once (one connection attempt).
HTH, Steve.
alug, the Anglian Linux User Group list Send list replies to alug@stu.uea.ac.uk http://www.anglian.lug.org.uk/ http://rabbit.stu.uea.ac.uk/cgi-bin/listinfo/alug See the website for instructions on digest or unsub!
Well that was easy, dunno what he was going on about, thanks for the help saved looking at the man pages :)
Ta
Darren
-----Original Message----- From: alug-admin@stu.uea.ac.uk [mailto:alug-admin@stu.uea.ac.uk]On Behalf Of Steve Fosdick Sent: 19 August 2001 13:14 To: alug@stu.uea.ac.uk Subject: Re: [Alug] SSH/SCP No Password
On Sun, Aug 19, 2001 at 12:19:20PM +0100, D wrote:
Anyone ever got this to work? Not sat down and tried yet but a guy I was talking to yesterday said its harder then it looks, surely you
just need the
host keys etc.. and your away.
I have it working.
Both hosts should be known to each other, i.e. each host has the other host's public key (ssh_host_key.pub) in its ssh_known_hosts file. The user account on the desination end needs to have the public key of the account on the originating end (.ssh/identity.pub) in its .ssh/authorized_keys file.
In addition to that the file permissions all need to be correct:
For the host specific files (/etc/ssh/* or /etc/ssh_*) all should be writable only by root and the host private key should not be readable by anyone else either. All the others files should be world readable.
For the user specific files, all should be owned by the user concerned and writable only by that user, with the private key (identity) and the authorized_keys files being readable only by that user and the others world readable.
If it doesn't work when you set it up, try the -d option on the server end to get a debug log from it which will tell what types of authenciation it is trying and why they fail. To use -d you need to run sshd from the command line as it doesn't go into the background and only goes round once (one connection attempt).
HTH, Steve.
alug, the Anglian Linux User Group list Send list replies to alug@stu.uea.ac.uk http://www.anglian.lug.org.uk/
http://rabbit.stu.uea.ac.uk/cgi-bin/listinfo/alug See the website for instructions on digest or unsub!
-
D -
David Freeman -
Mills -
Neill Newman -
Steve Fosdick