Next Question
RSS
Well, have you tried using "stat .ssh" or "stat .ssh/authorized_keys" on the remote to view the access, modification and creation time stamps as you login? And similarily "stat /etc/ssh", "stat /etc/sshd_config", "stat .ssh/id_rsa (or dsa)" to see what the timestamps look like and if they change pre and post login from the local?
Performing an "ls" command can give you the same info, but "stat" shows it all in one tidy area. Not sure if you're trying to keep your local and remote host file access times in sync or if you're just curious to know how your system changes, but those are first steps I'd do.
If you could expound on the desired outcome you're trying to achieve, I could give this more thought and craft a better answer.
Cheers,
Sr. Unix / Linux Sysadmin 10+ Years
Permalink | Report
2. The private key is your security and must be protected. The public key is open to the public.
3. SSH uses encryption point to point. The information passing on the line can not be decoded without the private key. A prime number hash so improbable that super computers would take generations to break.
4. SSH encode uses CPU cycles to encode and decode slowing down the through speed.
5. The maintenance of SSH requires a knowledge of Unix or Linux.
6. The SSH connection is transparent to the user. Files can be browsed and transferred transparently.
7. The SSH uses a series of event messages to communicate between server points. It works like telnet. Messages events are passed between points. A series of events must be passed before transmission is permitted.
Event Sequence of an SSH Connection:
The following series of events help protect the integrity of SSH communication between two hosts.
A cryptographic handshake is made so that the client can verify that it is communicating with the correct server.
The transport layer of the connection between client and remote host is encrypted using a symmetric cipher.
The client authenticates itself to the server.
the remote client can now interact safely with the remote host over the encrypted connection.
TCP:
TCP provides connections that need to be established before sending data. TCP connections have three phases:
A. connection establishment
B. data transfer
C. connection termination
Here are the various states of a connection end-point or Internet socket:
LISTEN
SYN-SENT
SYN-RECEIVED
ESTABLISHED
FIN-WAIT-1
FIN-WAIT-2
CLOSE-WAIT
CLOSING
LAST-ACK
TIME-WAIT
CLOSED
LISTEN
SYN-SENT
represents waiting for the remote TCP to send back a TCP packet with the SYN and ACK flags set. (usually set by TCP clients)
SYN-RECEIVED
represents waiting for the remote TCP to send back an acknowledgment after having sent back a connection acknowledgment to the remote TCP. (usually set by TCP servers)
ESTABLISHED
represents that the port is ready to receive/send data from/to the remote TCP. (set by TCP clients and servers)
TIME-WAIT
represents waiting for enough time to pass to be sure the remote TCP received the acknowledgment of its connection termination request. According to RFC 793 a connection can stay in TIME-WAIT for a maximum of four minutes.
ssh uses TCP protocol to communicate.
The shell is a Unix terminal screen. All the unix commands are available in the shell and remote commands are possible on remote machine.
In System programming the remote procedure calls allow a remote machine to be control through tcp/ip and transmission of commands. At a high level, the secure shell was built ontop of this technology. If your interesting in RCP system development, it will help you understand how the shell calls commands on the remote machine.
Source(s):
http://en.wikipedia.org/wiki/Secure_Shell
http://pigtail.net/LRP/printsrv/cygwin-ssh.html (Installation)
http://www.redhat.com/docs/manuals/linux/RHL-9-Manual/ref-guide/s1-ssh-conn... (Event)
http://www.velocityreviews.com/forums/t220671-tls-ssl-ssh.html
http://www.linuxjournal.com/article/2413
Permalink | Report
Answered Question
M$6
February 06, 2009 10:24 PM
Can I keep ssh files from being "NonPrejudice" when it comes to local AND remote files with multiple hosts ?
Very simple question here guys although the title may sound complicated.
Don't make it out to be more than it is.
I'm really just trying to figure out how ssh handshakes work as apposed to files stats on both hosts and local machine in a multi host environment. (If someone has multiple hosts and they are connecting via ssh)
What gets polled? Where keys are stored? etc.. etc..
[How can i keep ssh files from being "non prejudice" when it comes to local AND remote file stats ?]
Basically it's like this. I have numerous hosts and numerous ssh keys. As well as numerous ssh backend files on both my machine and the host's themselves.
I'd like to keep all file access/modification/creation times separate when connecting and using ssh on both the local machine and the hosts.
I'd like to also know if keys are kept in a single file ?
Or multiple files ? Or what ?(In a "multi host" environment)
Is it only user files ? eg: /userone/.ssh /usertwo/.ssh
Or even deeper eg: /usr/lib/ssh and /usr/bin/ssh and so on and so forth ..
One way I have thought to accomplish this is creating multiple linux users and connecting to each individual host from each separate user.
Will this work the way i would like it to ?
Since my data is to precious i wouldn't dare try it.
Here is a scenario of how i __would imagine__ it __MIGHT__ play out currently! ....
(HOST A.) (Host ABC (some original host i've had for quite a while))
- February 10th 12:01 45seconds I connect to HOST A. via ssh.
- February 10th 12:01 50seconds HOST A checks its locally stored ssh keys and then polls mine.
- February 10th 12:01 50seconds Doing so HOST A Changes the access time of the locally stored ssh files along with my local ssh files to ~>ACCESSTIME: February 10th 12:01:50
(this happens on both the server and my local machine)
.... At this point i can chose to either login with my key and password or do nothing in doing so the handshake would timeout ofcoarse
With either scenario I would chose would still leave a mark on either the host ssh keys and files, my local machines ssh keys or files, or both or one and not the other.
...Changing the access times modification times or even possibly create a new file altogether with a new creation time and new times for all 3, the earlier I'm not concerned with ofcoarse unless that file where overwritten somehow which would then change the creation time yet again.
Host B: (ABC Host) (A new host with full root access)
- February 10th 6:15 30seconds I connect to HOST B. via ssh.
- February 10th 6:15 35seconds HOST B checks its locally stored ssh keys and then polls mine.
- February 10th 6:15 35seconds Doing so HOST B Changes the access time of the locally stored ssh files along with my local ssh files to ~>ACCESSTIME: February 10th 6:15:35
(At this point you should see where i am going with this) :o)
So as you can see the chain of file times would be broken on all fronts (access/modification and possibly even creation times) if i where to reconnect to HOST A or even any new host in the future.
Since i am constantly switching between ssh handshakes from earch host I just can't write a script to do something like
"stat * >> logtimes.txt" because it would need up to the millisecond accuracy .
(This simply would NOT work , and would defeat the purpose)
The only way would be a proactive approach .
And using "noatime" as a boot parameter at bootup is simply not an option.
I am however exploring Multi boot environments as a option, however that will be very time consuming for such a delicate and tedious problem.
I am open to all suggestions except having to reboot the remote machines or using "noatime" locally.
Please keep in mind this needs to be accomplished both locally and remotely and also the more stat data i can keep and the further apart i can keep ssh host and local data from intermingling with each other the better.
PS:
By the way i don't want anyone to get the wrong idea, this is only with regards to the actual ssh files that control the handshake and any and all keys that might be associated with that handshake.
That includes RSA Public, Private, User , and server keys.
Files/folders themselves that are transferred to and from the server (unless by some odd chance they are the keys or backend files themselves) i am not concerned with as to the fundamentals of my question.
Someone had suggested modifications of sshd_config however that might work for ~ssh user per user files backend controller files might still be polled and files access and modification and even new creation times might still be vulnerable.
Also if you think im crazy to ask such a question, its my question and i am asking it for my own reasons whatever they might be I am still entitled to ask.
Please keep all tinfoil hat comments to yourselves.
Don't make it out to be more than it is.
I'm really just trying to figure out how ssh handshakes work as apposed to files stats on both hosts and local machine in a multi host environment. (If someone has multiple hosts and they are connecting via ssh)
What gets polled? Where keys are stored? etc.. etc..
[How can i keep ssh files from being "non prejudice" when it comes to local AND remote file stats ?]
Basically it's like this. I have numerous hosts and numerous ssh keys. As well as numerous ssh backend files on both my machine and the host's themselves.
I'd like to keep all file access/modification/creation times separate when connecting and using ssh on both the local machine and the hosts.
I'd like to also know if keys are kept in a single file ?
Or multiple files ? Or what ?(In a "multi host" environment)
Is it only user files ? eg: /userone/.ssh /usertwo/.ssh
Or even deeper eg: /usr/lib/ssh and /usr/bin/ssh and so on and so forth ..
One way I have thought to accomplish this is creating multiple linux users and connecting to each individual host from each separate user.
Will this work the way i would like it to ?
Since my data is to precious i wouldn't dare try it.
Here is a scenario of how i __would imagine__ it __MIGHT__ play out currently! ....
(HOST A.) (Host ABC (some original host i've had for quite a while))
- February 10th 12:01 45seconds I connect to HOST A. via ssh.
- February 10th 12:01 50seconds HOST A checks its locally stored ssh keys and then polls mine.
- February 10th 12:01 50seconds Doing so HOST A Changes the access time of the locally stored ssh files along with my local ssh files to ~>ACCESSTIME: February 10th 12:01:50
(this happens on both the server and my local machine)
.... At this point i can chose to either login with my key and password or do nothing in doing so the handshake would timeout ofcoarse
With either scenario I would chose would still leave a mark on either the host ssh keys and files, my local machines ssh keys or files, or both or one and not the other.
...Changing the access times modification times or even possibly create a new file altogether with a new creation time and new times for all 3, the earlier I'm not concerned with ofcoarse unless that file where overwritten somehow which would then change the creation time yet again.
Host B: (ABC Host) (A new host with full root access)
- February 10th 6:15 30seconds I connect to HOST B. via ssh.
- February 10th 6:15 35seconds HOST B checks its locally stored ssh keys and then polls mine.
- February 10th 6:15 35seconds Doing so HOST B Changes the access time of the locally stored ssh files along with my local ssh files to ~>ACCESSTIME: February 10th 6:15:35
(At this point you should see where i am going with this) :o)
So as you can see the chain of file times would be broken on all fronts (access/modification and possibly even creation times) if i where to reconnect to HOST A or even any new host in the future.
Since i am constantly switching between ssh handshakes from earch host I just can't write a script to do something like
"stat * >> logtimes.txt" because it would need up to the millisecond accuracy .
(This simply would NOT work , and would defeat the purpose)
The only way would be a proactive approach .
And using "noatime" as a boot parameter at bootup is simply not an option.
I am however exploring Multi boot environments as a option, however that will be very time consuming for such a delicate and tedious problem.
I am open to all suggestions except having to reboot the remote machines or using "noatime" locally.
Please keep in mind this needs to be accomplished both locally and remotely and also the more stat data i can keep and the further apart i can keep ssh host and local data from intermingling with each other the better.
PS:
By the way i don't want anyone to get the wrong idea, this is only with regards to the actual ssh files that control the handshake and any and all keys that might be associated with that handshake.
That includes RSA Public, Private, User , and server keys.
Files/folders themselves that are transferred to and from the server (unless by some odd chance they are the keys or backend files themselves) i am not concerned with as to the fundamentals of my question.
Someone had suggested modifications of sshd_config however that might work for ~ssh user per user files backend controller files might still be polled and files access and modification and even new creation times might still be vulnerable.
Also if you think im crazy to ask such a question, its my question and i am asking it for my own reasons whatever they might be I am still entitled to ask.
Please keep all tinfoil hat comments to yourselves.
Interesting Question?
Yes (0)
No (0)
- In Web Development |
- |
- Report |
-
Share
RSS
Best Answer Chosen by Asker
| February 08, 2009 05:04 AM |
Performing an "ls" command can give you the same info, but "stat" shows it all in one tidy area. Not sure if you're trying to keep your local and remote host file access times in sync or if you're just curious to know how your system changes, but those are first steps I'd do.
If you could expound on the desired outcome you're trying to achieve, I could give this more thought and craft a better answer.
Cheers,
Sr. Unix / Linux Sysadmin 10+ Years
Permalink | Report
Reply
Other Answers (1)
February 10, 2009 12:30 AM
1. SSH uses a private/public key authorization. 2. The private key is your security and must be protected. The public key is open to the public.
3. SSH uses encryption point to point. The information passing on the line can not be decoded without the private key. A prime number hash so improbable that super computers would take generations to break.
4. SSH encode uses CPU cycles to encode and decode slowing down the through speed.
5. The maintenance of SSH requires a knowledge of Unix or Linux.
6. The SSH connection is transparent to the user. Files can be browsed and transferred transparently.
7. The SSH uses a series of event messages to communicate between server points. It works like telnet. Messages events are passed between points. A series of events must be passed before transmission is permitted.
Event Sequence of an SSH Connection:
The following series of events help protect the integrity of SSH communication between two hosts.
A cryptographic handshake is made so that the client can verify that it is communicating with the correct server.
The transport layer of the connection between client and remote host is encrypted using a symmetric cipher.
The client authenticates itself to the server.
the remote client can now interact safely with the remote host over the encrypted connection.
TCP:
TCP provides connections that need to be established before sending data. TCP connections have three phases:
A. connection establishment
B. data transfer
C. connection termination
Here are the various states of a connection end-point or Internet socket:
LISTEN
SYN-SENT
SYN-RECEIVED
ESTABLISHED
FIN-WAIT-1
FIN-WAIT-2
CLOSE-WAIT
CLOSING
LAST-ACK
TIME-WAIT
CLOSED
LISTEN
SYN-SENT
represents waiting for the remote TCP to send back a TCP packet with the SYN and ACK flags set. (usually set by TCP clients)
SYN-RECEIVED
represents waiting for the remote TCP to send back an acknowledgment after having sent back a connection acknowledgment to the remote TCP. (usually set by TCP servers)
ESTABLISHED
represents that the port is ready to receive/send data from/to the remote TCP. (set by TCP clients and servers)
TIME-WAIT
represents waiting for enough time to pass to be sure the remote TCP received the acknowledgment of its connection termination request. According to RFC 793 a connection can stay in TIME-WAIT for a maximum of four minutes.
ssh uses TCP protocol to communicate.
The shell is a Unix terminal screen. All the unix commands are available in the shell and remote commands are possible on remote machine.
In System programming the remote procedure calls allow a remote machine to be control through tcp/ip and transmission of commands. At a high level, the secure shell was built ontop of this technology. If your interesting in RCP system development, it will help you understand how the shell calls commands on the remote machine.
Source(s):
http://en.wikipedia.org/wiki/Secure_Shell
http://pigtail.net/LRP/printsrv/cygwin-ssh.html (Installation)
http://www.redhat.com/docs/manuals/linux/RHL-9-Manual/ref-guide/s1-ssh-conn... (Event)
http://www.velocityreviews.com/forums/t220671-tls-ssl-ssh.html
http://www.linuxjournal.com/article/2413
Permalink | Report
Reply
February 10, 2009 04:16 PM
I beg your pardon davepamn , However this is a very concerning answer, almost entirely comprised of informational sources and no background or forground information. No personal experience is in the make-up of your answer and its not a very good answer.
Report
Answer this Question
Related Questions
Ask a Question
Buy Mahalo Dollars with Credit Card or PayPal
Top Members
Most Popular Tags
Categories
- Anonymous
-
Arts & Design
-
Beauty & Style
-
Books & Authors
-
Business
-
Cars & Transportation
-
Consumer Electronics
- Coupons Deals
-
Education
-
Entertainment
-
Environment
-
Fitness
-
Food & Drink
- From Email
- From Iphone
- From Twitter
-
Health
-
History
-
Hobbies
-
Home & Garden
-
How Tos
-
Humor
-
Jobs
-
Legal
-
Local
-
Love & Relationships
-
Mahalo Answers Community
-
Money
-
Music
-
News
-
NSFW
-
Parenting
-
Pets
-
Science & Mathematics
-
Services
-
Shopping
-
Social Science
-
Society & Culture
-
Sports
-
Technology & Internet
-
Travel
-
Video Games
Welcome New Members
- cassiebrown, November 30, 2009 02:50 AM
- shincenone, November 30, 2009 02:47 AM
- rebelharleygirl, November 30, 2009 02:45 AM
- mildredmonares, November 30, 2009 02:44 AM
- andrewcurrier, November 30, 2009 02:32 AM
Mahalo Dollars are the currency of Mahalo Answers.
Each Mahalo Dollar costs $1.
Once you earn more than 40 Mahalo Dollars, you can request to be paid via PayPal. Each Mahalo Dollar is currently worth $0.75 when paid out via PayPal. Learn More
Phreakegirl ...
Yes i have thought about using the stat command on both the client and host, and its nice to know that you understood that mess above.
My goal really is just to keep the time chains intact for each handshake, i don't want one server knowing the past connection time for another server i may have connected to earlier.
I want to keep all that information for each server stagnent for each handshake.
As far as the ls command goes At first thought i don't think that would have any desired affect.
I had also thought about making a script with a sleep command or something like that to >> to a log file.
Truely,
XDS
If you don't give me a viable corresponding functionary application, I will be forced to mark this as no best answer found.
All the best,
XDS